MCP सर्वर के रूप में टेम्प ईमेल

जिस API को एजेंट कॉल कर सकता है और जिस API को एजेंट कॉल करना जानता है, उनमें असली फ़र्क है। एक REST एंडपॉइंट के लिए मॉडल को बेस URL, ऑथ हेडर का स्वरूप, JSON बॉडी और रिस्पॉन्स स्कीमा संदर्भ में रखने पड़ते हैं, और चारों को एक ही बार में सही करना पड़ता है। टूल डेफ़िनिशन ये सब प्रोटोकॉल से मुफ़्त में दे देती है।

यहाँ MCP के पक्ष में पूरा तर्क यही है। इनबॉक्स इतनी छोटी सतह है कि टूल की सूची ही डॉक्यूमेंटेशन है।

इसे जोड़ना

apumail /.well-known/mcp.json पर एक MCP डिस्क्रिप्टर देता है। जो क्लाइंट डिस्क्रिप्टर पढ़ता है, उसे ओरिजिन की ओर इशारा करना ही काफ़ी है:

https://api.apumail.com/.well-known/mcp.json

कोई इंस्टॉल स्टेप नहीं, कोई पैकेज डाउनलोड नहीं, पहले से कोई key बनाने की ज़रूरत नहीं — जिन इनबॉक्स टूल को ऑथ चाहिए, वे वही इनबॉक्स टोकन लेते हैं जो create_inbox लौटाता है।

9 टूल

ये तीन समूहों में बँटते हैं, और यह समूहीकरण ही मानसिक मॉडल है:

पता पाना

• create_inbox — रैंडम-स्लग वाला इनबॉक्स बनाता है, पता और उसका टोकन लौटाता है। कोई ऑथ नहीं। यही प्रवेश बिंदु है।
• get_inbox — इनबॉक्स मेटाडेटा और TTL स्थिति।

प्राप्त करना

• list_mails — इनबॉक्स में अभी मौजूद सब कुछ।
• read_mail — एक मैसेज, पूरी बॉडी, सैनिटाइज़ की हुई।
• wait_for_mail — सबसे महत्वपूर्ण। मेल आने तक रुका रहता है। यही एजेंट को हर पोल पर एक मॉडल राउंड-ट्रिप जलाने से बचाता है।
• extract_latest_otp — सबसे नए मैसेज का कोड, सर्वर-साइड पहले ही निकाला हुआ।

भेजना

• send_mail — उसी पते से जवाब देना। from को ज़बरदस्ती ऑथेंटिकेटेड इनबॉक्स पर सेट किया जाता है, ताकि लीक हुआ टोकन किसी का रूप न धर सके।

इसके अलावा पेड टियर पर wait_for_sms और extract_latest_sms_otp, जो ठीक वही करते हैं जो उनके ईमेल समकक्ष करते हैं — वही wait/extract स्वरूप, पतों की जगह फ़ोन नंबर।

टूल के रूप में फ़्लो कैसा दिखता है

साइनअप की जो प्रक्रिया OTP वाली पोस्ट में तीन curl कॉल थी, वह सिमटकर यह बन जाती है:

1. create_inbox → एजेंट को vivid-llama-4a2c@apumail.com मिलता है
2. एजेंट वह पता उस फ़ॉर्म में टाइप करता है जिस पर वह काम कर रहा है
3. wait_for_mail → रुका रहता है, कन्फ़र्मेशन आने पर लौटता है
4. extract_latest_otp → "482910"

इसमें apumail-विशिष्ट कोई तर्क नहीं है। मॉडल को यह जानने की ज़रूरत नहीं कि apumail है क्या — उसे बस यह जानना है कि wait_for_mail नाम का एक टूल है, जो प्रोटोकॉल उसे पहले ही बता चुका है।

कब MCP छोड़ें

सच कहें तो: अगर आप टेस्ट सूट लिख रहे हैं, तो REST API इस्तेमाल करें। MCP तब अपनी क़ीमत वसूलता है जब कॉल करने वाला एक मॉडल हो जो तय कर रहा हो कि आगे क्या करना है। जब कॉल करने वाला आपकी CI पाइपलाइन हो जो एक तय स्क्रिप्ट चला रही है, तो एंडपॉइंट ज़्यादा सरल हैं और बीच में कोई प्रोटोकॉल नहीं। दोनों एक ही बैकएंड पर जाते हैं, इसलिए इन्हें मिलाना ठीक है — फ़िक्स्चर में REST से प्रोविज़न करें, पता एजेंट को दें, और उसे MCP पर wait_for_mail करने दें।

डिस्क्रिप्टर ही डॉक्स है

अगर आप कुछ भी जोड़ने से पहले सतह को पढ़ना चाहते हैं, तो तीन URL हर सवाल का जवाब देते हैं:

• /.well-known/mcp.json — MCP डिस्क्रिप्टर
• /openapi.json — REST हिस्से के लिए OpenAPI 3.1
• /llms.txt — यही सब Markdown में, किसी मॉडल के ऊपर से नीचे तक पढ़ने के लिए लिखा गया