Pidgeon

npx add-mcp 'https://pidgeon.ai/api/mcp'

एक एजेंट सीधे Pidgeon इनबॉक्स संभाल सकता है: उसे पढ़ सकता है, उससे जवाब दे सकता है, उसमें पते बना सकता है। Pidgeon उसी API पर Model Context Protocol बोलता है जिसका वर्णन यह दस्तावेज़ करता है — एक प्रोटोकॉल अडैप्टर, और कुछ नहीं।

अंदर आने के दो तरीके हैं, और दोनों एक ही सर्वर हैं। होस्ट किए गए सर्वर को इंस्टॉल करने की ज़रूरत नहीं; पैकेज इसे आपकी मशीन पर चलाता है।

होस्ट किया गया सर्वर, जो एक URL है

claude mcp add --transport http pidgeon https://pidgeon.ai/api/mcp

पहली कॉल 401 का जवाब देती है, और क्लाइंट आपको साइन इन करने के लिए Pidgeon पर भेजता है। आप चुनते हैं कि वह क्या कर सकता है — पढ़ना, पढ़ना और भेजना, या पूरा ऐक्सेस — और वह कहाँ तक पहुँच सकता है: एक पता, या अगर खाते के मालिक आप हैं तो हर पता। यह चुनाव एक API key बन जाता है, और क्लाइंट उसके लिए एक टोकन रखता है। यह Developers → API keys → Connected apps के अंतर्गत दिखाई देता है, और वहाँ Disconnect करने से क्लाइंट की अगली कॉल पर उसका ऐक्सेस समाप्त हो जाता है।

Claude के custom connectors, ChatGPT, Grok, Cursor, Codex और VS Code वही URL लेते हैं और उसी तरह साइन इन करते हैं। हर अनुरोध का जवाब अलग से दिया जाता है: सर्वर कोई सेशन नहीं रखता, क्योंकि उसके पास रखने के लिए अपनी कोई स्थिति नहीं है।

ऐसे एजेंट के लिए जहाँ साइन इन करने वाला कोई व्यक्ति मौजूद न हो, इसके बजाय एक key भेजें:

claude mcp add --transport http pidgeon https://pidgeon.ai/api/mcp \
--header "Authorization: Bearer $PIDGEON_API_KEY"

x-api-key भी काम करता है। Cursor, Codex (जो JSON नहीं, TOML पढ़ता है) और VS Code के लिए चरण-दर-चरण निर्देश; Windsurf और Gemini CLI भी वही URL और header लेते हैं।

Grok में

Grok में, Connectors → Custom चुनें, https://pidgeon.ai/api/mcp पेस्ट करें और consent screen पर साइन इन करें; key की ज़रूरत नहीं है (चरण-दर-चरण निर्देश)। Meta का Muse Meta के साथ समीक्षा में है।

Cursor में

इसके cursor.directory लिस्टिंग से Pidgeon को Cursor में जोड़ें, जिसमें होस्ट किया गया सर्वर और skill शामिल हैं।

या सर्वर को हाथ से, ~/.cursor/mcp.json में जोड़ें (या एक प्रोजेक्ट के लिए .cursor/mcp.json में)। इसे सिर्फ़ URL चाहिए; पहली कॉल पर Cursor आपको साइन इन कराता है:

{
"mcpServers": {
  "pidgeon": {
    "url": "https://pidgeon.ai/api/mcp"
  }
}
}

ऐसे एजेंट के लिए जहाँ साइन इन करने वाला कोई व्यक्ति मौजूद न हो, URL के साथ "headers": { "Authorization": "Bearer ${env:PIDGEON_API_KEY}" } जोड़ें, और Cursor इसे आपके environment से भर देगा।

Codex, VS Code और Gemini CLI

Codex, VS Code और Gemini CLI के लिए, एक कमांड सर्वर को क्लाइंट की अपनी फ़ाइल में लिखता है:

npx -y @pidgeon-ai/mcp init --client codex    # ~/.codex/config.toml
npx -y @pidgeon-ai/mcp init --client vscode   # .vscode/mcp.json
npx -y @pidgeon-ai/mcp init --client gemini   # .gemini/settings.json

अगर कोई key सेट नहीं है, तो यह सिर्फ़ URL लिखता है और क्लाइंट आपको साइन इन कराता है। अगर PIDGEON_API_KEY सेट है, तो यह पहले key की जाँच करता है, फिर क्लाइंट से उसे उस variable से पढ़वाता है (Codex, Gemini CLI) या एक बार पूछने को कहता है (VS Code), ताकि key फ़ाइल में कभी न जाए। यह मौजूदा सामग्री में जोड़ता है, टिप्पणियों समेत; जिस फ़ाइल में बदलाव करता है उसकी एक प्रति <file>.bak में रखता है; दूसरी बार कुछ नहीं करता; और किसी अलग pidgeon प्रविष्टि को सिर्फ़ --force के साथ बदलता है। --scope user या --scope project दूसरी फ़ाइल चुनता है; --print कुछ नहीं लिखता।

या इंस्टॉल किया हुआ सर्वर, जो एक पैकेज है

PIDGEON_API_KEY=pgn_live_… npx -y @pidgeon-ai/mcp init

यह कुछ भी लिखने से पहले API के साथ key की जाँच करता है और बताता है कि वह किन पतों तक पहुँच सकती है — यह एकमात्र सवाल है जिसका जवाब JSON का कोई ब्लॉक नहीं दे सकता, और जिसका जवाब न मिलने पर अक्सर मॉडल चुपचाप ऐसी त्रुटि देता है जिसे आप कभी देख नहीं पाते। फिर यह मौजूदा डायरेक्टरी में .mcp.json लिखता है और जो लिखा है उसे दिखाता है। यह पहले से मौजूद प्रविष्टि को कभी नहीं बदलता: ऐसा --force करता है, और --print बिना कुछ लिखे कॉन्फ़िगरेशन दिखाता है। अगर आपका क्लाइंट अपनी कॉन्फ़िगरेशन किसी दूसरी जगह रखता है, तो आपको यही चाहिए।

key को फ़ाइल में लिखने के बजाय environment से संदर्भित किया जाता है, ताकि कॉन्फ़िगरेशन commit किया जा सके और credential फ़ाइल में न जाए:

{
"mcpServers": {
  "pidgeon": {
    "command": "npx",
    "args": ["-y", "@pidgeon-ai/mcp"],
    "env": { "PIDGEON_API_KEY": "${PIDGEON_API_KEY}" }
  }
}
}

Claude Desktop या कोई अन्य MCP क्लाइंट वही ब्लॉक लेता है। सर्वर को सीधे चलाने के लिए, जो ज़्यादातर यह देखने के काम आता है कि वह कैसे शुरू होता है:

PIDGEON_API_KEY=pgn_live_… npx -y @pidgeon-ai/mcp

PIDGEON_BASE_URL उसे production के बजाय किसी दूसरी जगह पर भेजता है, जो तभी काम का है जब आप खुद Pidgeon चला रहे हों।

ऐक्सेस नियंत्रण पूरी तरह key पर निर्भर है

इससे मॉडल को एक API key दी जाती है — जिसे आपने बनाया हो, या जिसे आपने साइन इन करके दिया हो। पैकेज में कुछ भी यह तय नहीं करता कि कहाँ तक पहुँचा जा सकता है: key की अपनी सीमा और उसे दिए गए पते ही सब कुछ तय करते हैं, सर्वर-साइड पर, ठीक वैसे ही जैसे किसी अन्य कॉलर के लिए। यहाँ नियमों का कोई दूसरा सेट नहीं है जिसमें गलती हो सके।

इसलिए एजेंट को उसकी ज़रूरत वाली सबसे सीमित key दें। read पर बनाई गई key कभी कुछ भेज नहीं सकती, चाहे उसे इनबॉक्स का कितना भी व्यापक ऐक्सेस दिया गया हो — key की पहुँच का क्या मतलब है और उसे कैसे सीमित करें, इसके लिए Authentication देखें। जो एजेंट सिर्फ़ छँटाई करता है, उसके पास सिर्फ़ पढ़ने वाली key होनी चाहिए; तब यह सवाल ही नहीं उठता कि वह कोई शर्मनाक चीज़ भेज सकता है या नहीं।

key की पहुँच उन पतों का स्नैपशॉट होती है जिन्हें उसे दिया गया था, इसलिए key बनने के बाद बनाया गया कोई पता उसमें शामिल नहीं होता।

यह क्या उपलब्ध कराता है

सभी 42 टूल, सर्वर की अपनी सूची से पढ़े गए हैं, ताकि यह पेज उससे पीछे न रह जाए:

Tool	काम	Endpoint
list_addresses	वे पते जिन तक यह credential पहुँच सकता है।	GET /identities
create_address	एजेंट के इस्तेमाल के लिए एक पता बनाएँ।	POST /identities
get_address	id से एक पता।	GET /identities/{id}
list_threads	एक पते की बातचीतें, सबसे नई पहले।	GET /threads
get_thread	id से एक बातचीत।	GET /threads/{id}
list_messages	एक बातचीत के संदेश, सबसे पुराने पहले — जवाब देने से पहले पढ़ने वाला पाठ।	GET /messages
search_messages	इस credential की पहुँच वाले हर पते में पूर्ण-पाठ खोज, प्रासंगिकता के क्रम में।	GET /messages/search
send_message	ऐसे पते से भेजें जिससे यह credential भेज सकता है।	POST /messages
get_message	id से एक संदेश, उसके मुख्य भाग, हमारे पास मौजूद headers और भेजने वाले domain के रिकॉर्ड से साबित हुई बातों के साथ — authentication.spf\, .dkim\, .dmarc\; जहाँ null का मतलब है कि जानकारी रिपोर्ट नहीं की गई, न कि जाँच विफल हुई।	GET /messages/{id}
await_message	किसी पते पर संदेश आने तक प्रतीक्षा करता है — जैसे साइन-अप फ़ॉर्म सबमिट करने के बाद — और उसे extracted.codes\ तथा extracted.links\ के साथ लौटाता है: सत्यापन कोड और पुष्टि लिंक सबसे संभावित पहले।	GET /messages/await
reply_to_message	प्राप्तकर्ता, विषय और थ्रेड का पता जवाब दिए जा रहे संदेश से चलता है, इसलिए आपको सिर्फ़ शब्द देने होते हैं, और कुछ नहीं।	POST /messages/{id}/reply
forward_message	एक संदेश को उसके मूल प्राप्तकर्ताओं के अलावा किसी और को, उसके अटैचमेंट सहित, उसे प्राप्त करने वाले पते से आगे भेजता है।	POST /messages/{id}/forward
create_draft	संदेश भेजे बिना लिखता है, ताकि कोई व्यक्ति उसे पढ़कर भेज सके — जब आपसे अनुमोदन के लिए जवाब तैयार करने को कहा जाए, तब इसका इस्तेमाल करें।	POST /drafts
get_draft_approval	रोके गए संदेश की स्थिति, उसके draft\_id\ के आधार पर: pending\ जब तक कोई व्यक्ति डैशबोर्ड में उसे मंज़ूर या अस्वीकार न करे; फिर approved\ (वह भेज दिया गया, और message\_id\ संदेश है), rejected\, या 24 घंटे तक किसी के निर्णय न लेने पर expired\।	GET /drafts/{id}/approval
list_drafts	एक पते के सभी ड्राफ़्ट, सबसे नए पहले, उनके प्राप्तकर्ताओं और मुख्य भाग सहित — ताकि आप बाद में किसी ड्राफ़्ट पर लौटकर उसे पूरा कर सकें।	GET /drafts
get_draft	id से एक ड्राफ़्ट: उसका प्रेषक, प्राप्तकर्ता, विषय, पाठ और अटैचमेंट।	GET /drafts/{id}
update_draft	दिए गए फ़ील्ड बदलता है और बाकी को जस का तस छोड़ता है; null\ विषय या पाठ को साफ़ करता है।	PATCH /drafts/{id}
delete_draft	एक ड्राफ़्ट हटाता है और अगर उसका भेजना शेड्यूल किया गया था तो उसे रद्द करता है।	DELETE /drafts/{id}
read_attachment	एक अटैचमेंट का पाठ — CSV, लॉग, JSON, कैलेंडर फ़ाइल, PDF, Word .docx\ या Excel .xlsx\।	GET /attachments/{id}/text
update_thread	बातचीत का मालिक कौन है और वह कहाँ तक पहुँची है।	PATCH /threads/{id}
update_message	किसी संदेश को स्टार करें, या उसे archive\, spam\ या trash\ में ले जाएँ।	PATCH /messages/{id}
list_send_rules	एक पते की अनुमति और अवरोध सूची, और उससे जुड़ी भेजने की नीति।	GET /identities/{id}/send-rules
list_receive_rules	वे नियम जो तय करते हैं कि एक पते तक क्या पहुँचे — प्रेषक या domain के आधार पर अस्वीकार, स्पैम, ट्रैश, संग्रह या इनबॉक्स — और उसका receive\_policy\।	GET /identities/{id}/receive-rules
list_folders	एक पते के हर फ़ोल्डर और उनकी गिनती।	GET /mailboxes
list_folder	एक पते का एक फ़ोल्डर, सबसे नए पहले, हर पंक्ति में एक बातचीत — जहाँ list\_threads\ बताता है कि कौन-सी बातचीतें मौजूद हैं, वहीं यह बताता है कि वे कहाँ रखी गई हैं और सूची में कैसी दिखती हैं।	GET /mailboxes/{folder}
list_changes	एक sync\_cursor\ के बाद से एक इनबॉक्स में हुए सभी बदलाव, नए संदेशों सहित, ताकि लंबे समय तक चलने वाले एजेंट को एक नया संदेश ढूँढ़ने के लिए पूरा फ़ोल्डर फिर से न पढ़ना पड़े।	GET /mailboxes/changes
list_events	इस credential की पहुँच वाले हर पते के सभी इवेंट — मेल प्राप्त, भेजा, डिलीवर, बाउंस या फ़ाइल किया गया।	GET /events
list_labels	लेबल workspace के नहीं, पते के होते हैं; इसलिए तीन पतों पर एक ही नाम के तीन लेबल और तीन id होते हैं।	GET /labels
create_label	एक पते पर एक लेबल।	POST /labels
apply_label	लेबल उसी पते का होना चाहिए जिस पते में बातचीत है — उस पते के लिए list\_labels\ आपको सही id देता है।	POST /threads/{id}/labels
remove_label	एक बातचीत से एक लेबल हटाता है।	DELETE /threads/{id}/labels
list_pods	pod आपके अपने ग्राहकों में से एक के लिए कंटेनर है: इसमें पते और domain होते हैं, और **इससे भेजा गया मेल इसकी अपनी भेजने की प्रतिष्ठा पर दर्ज होता है**, ताकि एक ग्राहक दूसरे की डिलीवरी को नुकसान न पहुँचा सके।	GET /pods
create_pod	आपके एक ग्राहक के लिए कंटेनर, जिसकी अपनी भेजने की प्रतिष्ठा होती है।	POST /pods
get_metrics	days\ की अवधि में भेजे गए, डिलीवर हुए, बाउंस हुए, अस्वीकार किए गए, शिकायत किए गए, प्राप्त हुए और स्पैम संदेश — इवेंट लॉग से गिने जाते हैं, इसलिए इनमें वे नतीजे भी शामिल हैं जिनकी जानकारी provider ने बाद में दी।	GET /metrics
get_calendar	एक पते का कैलेंडर, पते के id\ के आधार पर: उसका डिफ़ॉल्ट समय क्षेत्र और उसमें मौजूद इवेंट की संख्या।	GET /identities/{id}/calendar
update_calendar	बिना समय क्षेत्र के बनाए गए इवेंट को मिलने वाला समय क्षेत्र, जैसे Europe/Lisbon\ जैसा IANA नाम।	PATCH /identities/{id}/calendar
get_agenda	after\ और before\ (ISO 8601 date-times) के बीच पते के कैलेंडर में क्या है, शुरू होने के समय के क्रम में; आवर्ती इवेंट की हर तारीख़ अलग सूचीबद्ध होती है।	GET /identities/{id}/calendar/agenda
get_calendar_event	पते id\ के कैलेंडर में eventId\ से एक इवेंट: उसका समय, विवरण, स्थान, आवृत्ति और उपस्थित लोगों के जवाब।	GET /identities/{id}/calendar/events/{eventId}
create_calendar_event	पते id\ के कैलेंडर में एक इवेंट जोड़ता है।	POST /identities/{id}/calendar/events
update_calendar_event	कैलेंडर का एक इवेंट बदलता है: दिए गए फ़ील्ड बदलता है और बाकी को जस का तस छोड़ता है।	PATCH /identities/{id}/calendar/events/{eventId}
delete_calendar_event	पते id\ के कैलेंडर से एक इवेंट हटाता है।	DELETE /identities/{id}/calendar/events/{eventId}
respond_to_invitation	मेल के रूप में आए मीटिंग आमंत्रण का जवाब, संदेश के id\ के आधार पर: accepted\, declined\ या tentative\, और वैकल्पिक comment\ के साथ।	POST /messages/{id}/invitation/respond

हर टूल उसके बगल में दिए गए reference वाले endpoint से मेल खाता है और वही अनुरोध अस्वीकार करता है। जिस टूल की key को अनुमति नहीं है, वह उसी तरह विफल होता है जैसे API विफल होती है, और वही वाक्य देता है जो API देती।

जब तक आप कोई एक पता निर्दिष्ट न करें, खोज key की पहुँच वाले हर पते में होती है, और हर नतीजे में बताया जाता है कि वह किस पते पर मिला।

यह क्या नहीं है

यह एजेंट रनटाइम नहीं है और कोई निर्णय नहीं लेता। Pidgeon को इस बात से कोई फ़र्क नहीं पड़ता कि आप कौन-सा मॉडल चलाते हैं या उसे क्या निष्कर्ष निकालने की अनुमति है — बाकी उत्पाद के बारे में भी Threads and hand-off यही रुख अपनाता है। अगर एजेंट अटक जाए, तो बातचीत किसी व्यक्ति को सौंपना थ्रेड की स्थिति है, इस पैकेज की सुविधा नहीं।