Duplicate MCP tool calls के लिए execution identity ज़रूरी है

Reconnect transport की समस्या है। दूसरी action execution की समस्या है। जब teams दोनों को एक ही चीज़ मानकर ऐसे हर request को retry करने देती हैं जिसका visible response नहीं मिला, तो नुकसान होता है।

MCP में यह अंतर आसानी से छिप जाता है, क्योंकि tool call कई boundaries पार कर सकती है: agent process, MCP transport, action gateway और HTTP API या SSH target। Target के काम स्वीकार करने के बाद, लेकिन agent को result मिलने से पहले connection गायब हो सकता है। अगर आपका system call फिर भेजता है, तो target को दो valid requests दिखाई देती हैं। उसके पास यह समझने की कोई वजह नहीं है कि दूसरी request गलती से आई थी।

इसका हल बड़ा retry budget नहीं है। हर requested action को execution identity दें, उसका lifecycle दर्ज करें और retry का निर्णय उसी record से लें। Request fingerprint बताता है कि caller क्या करना चाहता था। Activity record बताता है कि system ने उसे शुरू किया या पूरा किया था या नहीं। दोनों की ज़रूरत है।

Reconnect दूसरी execution की अनुमति नहीं देता

Broken stream के बाद reconnect करने वाले client के पास इतना evidence होता है कि communication विफल हुई। उसके पास यह evidence नहीं होता कि मूल tool call विफल हुई।

यह अंतर तब तक साफ़ लगता है, जब तक कोई MCP client के नीचे generic retry middleware नहीं जोड़ता। Middleware timeout, connection reset या missing response देखता है। उसे यह समझ नहीं होता कि POST read था, write था, remote command था या irreversible operation। वह bytes फिर भेज देता है, क्योंकि HTTP retry code अक्सर ऐसा ही करता है।

GET /repos/acme/api/branches जैसी read के लिए यह सहने योग्य हो सकता है। लेकिन POST /payments, DELETE /projects/atlas या production host बदलने वाली SSH command के लिए इससे दूसरा side effect पैदा हो सकता है। बाद में model को केवल एक result लौटाकर tool layer इसकी भरपाई नहीं कर सकती।

MCP Streamable HTTP transport specification stream टूटने पर Last-Event-ID के ज़रिए server से client तक event delivery resume करने की अनुमति देती है। यह stream पर messages recover करने का तरीका है। इससे दूसरी JSON-RPC tools/call request वही execution नहीं बन जाती। TypeScript SDK documentation भी resumption tokens को request path से अलग रखती है और fetch के आसपास client middleware की अनुमति देती है। इसी वजह से teams को अपना retry rule code में स्पष्ट लिखना चाहिए, न कि यह मान लेना चाहिए कि transport उन्हें बचा लेगा।

यह rule अपनाएँ:

Protocol इसका समर्थन करे तो response stream resume करें। Side-effect वाली action फिर तभी भेजें, जब action layer उसे उसी execution के रूप में पहचान सके।

मुश्किल मामले साफ़ failures नहीं होते। मुश्किल वे मामले हैं जिनमें server काम शुरू कर देता है, response गायब हो जाता है और client नहीं जानता कि उसे wait करना है, resume करना है, status पूछना है या retry करना है। आपका design इस uncertainty को दिखाई देने वाला बनाए।

JSON-RPC IDs messages की पहचान करते हैं, durable actions की नहीं

JSON-RPC request ID request और response को जोड़ने में उपयोगी है। लेकिन reconnect, process restart या अलग agent run के दौरान किसी action को deduplicate करने के लिए यह पर्याप्त नहीं है।

इन दो calls पर विचार करें:

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"deploy_release","arguments":{"service":"catalog","version":"2026.07.22"}}}

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"deploy_release","arguments":{"service":"catalog","version":"2026.07.22"}}}

ये dropped connection के बाद दो बार भेजी गई एक ही request हो सकती हैं। ये दो अलग client processes से भी आ सकती हैं, जो दोनों numbering 1 या 41 से शुरू करते हों। एक ही process में implementation bug से IDs दोबारा इस्तेमाल हो सकती हैं। जब तक value को authenticated caller और किसी खास protocol session से न जोड़ा जाए, यह लगभग कुछ नहीं बताती।

अब अलग IDs वाली दो calls देखें:

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"deploy_release","arguments":{"service":"catalog","version":"2026.07.22"}}}

{"jsonrpc":"2.0","id":42,"method":"tools/call","params":{"name":"deploy_release","arguments":{"service":"catalog","version":"2026.07.22"}}}

ये ऐसी transport retry हो सकती हैं जिसमें client ने नया ID दिया हो। या agent ने uncertain result मिलने के बाद जानबूझकर दूसरा deployment माँगा हो। Message IDs evidence हैं, निर्णय नहीं।

उलटी गलती भी न करें और matching tool call को हमेशा के लिए deduplicate न करें। एक ही release को दो बार deploy करना harmless या जानबूझकर किया गया काम हो सकता है। वही external ticket दो बार बनाना गलत हो सकता है। Credential को दो बार rotate करने से service lock out हो सकती है। Execution identity कितने समय तक meaningful रहती है, यह action class तय करती है।

एक व्यावहारिक model तीन identifiers को अलग रखता है:

• Protocol correlation ID: JSON-RPC ID और जहाँ लागू हो, MCP session या stream context।
• Execution ID: एक tool action करने के लिए स्वीकार किए गए एक प्रयास का server-created identifier।
• Intent fingerprint: requested effect का stable digest, जिससे protocol correlation बदलने पर पिछली execution खोजी जा सके।

इनको अलग करने के बाद logs ऐसे सवाल का जवाब देने का दिखावा नहीं करते जिसका जवाब वे दे ही नहीं सकते।

उपयोगी fingerprint effect का वर्णन करता है

Request fingerprint delivery बदलने पर वही रहना चाहिए और requested effect बदलने पर बदलना चाहिए। Raw JSON bytes का hash बनाकर उसे fingerprint न कहें। Property order, whitespace, optional defaults, request IDs और harmless formatting changes से raw JSON बदल सकता है।

पहले canonical action record बनाएँ। HTTP action के लिए इसका रूप कुछ ऐसा हो सकता है:

{
  "actor": "signed-process:com.example.agent",
  "tool": "deploy_release",
  "channel": "http",
  "target": "deploy-api.internal.example/releases",
  "credential_ref": "deploy-service",
  "method": "POST",
  "arguments": {
    "service": "catalog",
    "version": "2026.07.22",
    "region": "us-east-1"
  },
  "intent_scope": "run:5f8097"
}

Field order को canonicalize करें, semantic meaning न रखने वाले fields हटाएँ और digest निकालने से पहले ज्ञात equivalents को normalize करें। अगर region का default us-east-1 है, तो या तो उसे हमेशा record में लिखें या हमेशा छोड़ दें, जब target खुद वह default भरता हो। दोनों तरीकों को मिलाने से false misses बनेंगे।

actor field महत्वपूर्ण है। समान arguments भेजने वाले दो अलग authorized agent processes अलग intended actions हो सकते हैं। credential_ref भी महत्वपूर्ण है। एक service identity के ज़रिए किया गया request उसी path और body के दूसरे service identity से किए गए request के बराबर नहीं माना जा सकता। SSH के लिए host identity, account, command, behavior को प्रभावित करने वाली working directory और जहाँ सुरक्षित रूप से संभव हो, normalized command representation शामिल करें।

Secrets को canonical record से बाहर रखें। Bearer tokens, private keys या raw authorization headers को fingerprint input में कभी न रखें। अगर किसी argument में secret है, तो उसे protected internal reference से बदलें या HMAC जैसी keyed construction से fingerprint बनाएँ। कम entropy वाले secret का plain unsalted hash आपके audit store को guesses जाँचने का साधन बना देता है।

«बस request का hash बना दो» वाली सलाह लोकप्रिय है, क्योंकि वह छोटी है। Action control के लिए यह गलत है। Hash केवल यह साबित करता है कि कुछ bytes किसी function को दिए गए थे। वह यह नहीं बताता कि वे bytes उसी actor, उसी target effect या उसी retry window को दर्शाते हैं या नहीं।

Activity record में states चाहिए, केवल एक log line नहीं

उपयोगी activity record बताता है कि action कहाँ रुकी। अगर उसमें केवल success और failure दर्ज हों, तो reconnect के समय वही सवाल अनुत्तरित रह जाएगा जब साफ़ जवाब की सबसे ज़्यादा ज़रूरत होती है।

हर execution ID के लिए कम-से-कम ये transitions दर्ज करें:

1. Accepted: gateway ने request validate की और execution ID दिया।
2. Authorized: ज़रूरी approval या session authorization ने action की अनुमति दी।
3. Dispatched: gateway ने action HTTP client या SSH helper को सौंप दी।
4. Observed outcome: target response, exit status या स्पष्ट delivery failure प्राप्त हुआ।
5. Result delivered: agent को tool result मिला, अगर transport यह बात स्थापित कर सकता है।

चौथी और पाँचवीं state अलग रहनी चाहिए। Target HTTP 201 लौटा सकता है, लेकिन MCP client तक connection response पहुँचने से पहले टूट सकती है। Result delivery विफल होने के कारण execution को failed mark करना गलत होगा। उसे completed mark करने से recovery code के पास उपयोगी जानकारी रहती है: वह दूसरी request भेजे बिना known result लौटा या फिर से बना सकता है।

Incident के दौरान मैं ऐसा record देखना चाहूँगा:

{
  "execution_id": "act_01J4K8J7DX7V",
  "fingerprint": "hmac-sha256:4a1e...d90c",
  "tool": "deploy_release",
  "actor": "signed-process:com.example.agent",
  "target": "deploy-api.internal.example/releases",
  "state": "completed_result_not_delivered",
  "accepted_at": "2026-07-22T14:03:18Z",
  "dispatched_at": "2026-07-22T14:03:19Z",
  "completed_at": "2026-07-22T14:03:25Z",
  "target_status": 201,
  "result_reference": "result_01J4K8JFM2"
}

Record में हर operator को पूरा target response दिखाना ज़रूरी नहीं है। उसमें gateway को recovery decision लेने के लिए पर्याप्त protected detail और इंसान को घटना समझने के लिए पर्याप्त readable detail होनी चाहिए।

Sallyport का Activity journal individual calls दर्ज करता है, जबकि उसका Sessions journal agent runs दर्ज करता है। इस investigation में यह separation उपयोगी है: run बताता है कि कौन-सा agent process मौजूद था, और call record बताता है कि कोई खास बाहरी action dispatch boundary पार कर पाई या नहीं। इसकी audit chain को sp audit verify से offline verify भी किया जा सकता है, जो incident के बाद record को चुपचाप बदले जाने की संभावना जाँचने में मदद करता है।

Unknown outcomes को अलग result मानें

अधिकांश duplicate actions ऐसे system से शुरू होती हैं जिसमें केवल दो outcomes होते हैं: success और failure। Networked actions के लिए तीसरा outcome चाहिए: unknown।

Unknown का मतलब यह नहीं है कि system ने कुछ नहीं किया। इसका मतलब है कि system यह साबित नहीं कर सकता कि target ने action स्वीकार की या नहीं। Process से कोई byte निकलने से पहले आया timeout अक्सर retry करने के लिए सुरक्षित होता है। HTTP request body operating system को सौंपे जाने के बाद आया timeout अलग घटना है। SSH connection remote shell द्वारा command शुरू करने के बाद टूटे, तो स्थिति और गंभीर है, क्योंकि local process बंद होने के बाद भी remote command चलती रह सकती है।

Recovery तय करने से पहले हर tool action को classify करें:

API का HTTP verb इस table का उत्तर नहीं देता। PUT को अक्सर idempotent कहा जाता है, लेकिन खराब design वाला endpoint हर request पर notification भेज सकता है, build शुरू कर सकता है या audit event जोड़ सकता है। API idempotency key को मानती हो तो POST सुरक्षित रूप से दोहराई जा सकती है। Target का वास्तविक contract देखें।

लंबे समय तक चलने वाली remote commands के लिए काम शुरू करने से पहले durable marker जोड़ें। Migration command execution ID वाला record बना सकती है, काम शुरू होने पर उसे update कर सकती है और validation के बाद ही complete mark कर सकती है। Reconnect पर दोबारा dispatch करने से पहले इस marker को query करें। Marker के बिना «शायद चला ही नहीं» recovery strategy नहीं है।

Retries को सीमित intent scope में match करें

केवल fingerprint से legitimate work भी एक-दूसरे से match हो सकता है। उसे उस अवधि और context तक सीमित करें जिसमें retry होना स्वाभाविक है।

सबसे सरल scope एक agent run है। अगर वही signed process पहली result के unresolved रहते हुए वही action दोबारा भेजता है, तो दूसरी request को संभावित retry मानें। कोई दूसरा process घंटों बाद वही request भेजे, तो उसे fresh intent मानें, जब तक action खुद durable idempotency key न देती हो।

एक अच्छा matching rule ऐसा दिख सकता है:

if prior.fingerprint == incoming.fingerprint
  and prior.actor == incoming.actor
  and prior.intent_scope == incoming.intent_scope
  and prior.state in {accepted, authorized, dispatched, completed_result_not_delivered}:
    recover_or_attach_to(prior.execution_id)
else:
    create_new_execution()

recover_or_attach_to को blindly success नहीं लौटाना चाहिए। उसका व्यवहार पिछली state पर निर्भर है।

अगर पिछली execution accepted है लेकिन dispatched नहीं हुई, तो gateway उसी execution को आगे बढ़ा सकता है। अगर वह dispatched है और outcome unknown है, तो gateway को target के status endpoint, idempotency facility या durable marker से जाँच करनी चाहिए। अगर execution पूरी हो गई लेकिन result delivery विफल रही, तो stored result reference लौटानी चाहिए। अगर authorization ने उसे reject किया था, तो उसी ambiguous retry से नया approval path बनाने के बजाय वही rejection लौटानी चाहिए।

Scope action के अनुरूप होना चाहिए। Timeout वाले API request के लिए पाँच मिनट उचित हो सकते हैं। एक घंटे चलने वाले software deployment के लिए यह पर्याप्त नहीं है। Credential rotation के लिए तब तक durable fingerprint चाहिए हो सकता है, जब तक आप verify न कर लें कि कौन-सा credential active है। केवल इसलिए एक global TTL न रखें कि उसे configure करना आसान है। Action-specific retention और recovery rules बनाएँ।

Approval evidence है, idempotency mechanism नहीं

Human approval यह साबित कर सकती है कि process को action करने की अनुमति थी। वह यह साबित नहीं कर सकती कि पिछला प्रयास पहले ही हो चुका है।

यह उन systems के लिए महत्वपूर्ण है जो हर sensitive call पर prompt दिखाते हैं। मान लें agent production credential rotate करने को कहता है। कोई व्यक्ति approve करता है। Gateway request dispatch करता है, फिर client disconnect हो जाता है। Agent reconnect करता है और वही tool call बनाता है। उस व्यक्ति से फिर approval माँगना भ्रामक विकल्प पैदा करता है। Operator को परिचित request दिखती है और वह approve कर सकता है, लेकिन असली सवाल यह है कि पहली rotation पूरी हुई थी या नहीं।

Per-call approval की अपनी जगह है। यह action के समय authorization नियंत्रित करता है। इसे duplicate handling से अलग रखें:

• Authorization तय करता है कि current caller execution शुरू कर सकता है या नहीं।
• Fingerprinting तय करता है कि incoming request किसी existing execution से जुड़ती है या नहीं।
• Activity records तय करते हैं कि existing execution resume या recover की जा सकती है, या review ज़रूरी है।

जब retry किसी pending execution से match हो, तो नई approval ऐसे न दिखाएँ जैसे कुछ हुआ ही न हो। उसकी जगह मूल activity record दिखाएँ। Reviewer को target, पहली dispatch का समय, ज्ञात outcome और gateway ने action दोबारा क्यों नहीं भेजी, यह सब दिखाई देना चाहिए।

Sallyport एक fixed decision ladder अपनाता है: locked vault actions को deny करता है, नए agent process को default रूप से per-session authorization मिलता है और चुने गए credentials के लिए हर उपयोग पर approval आवश्यक हो सकती है। ये controls बताते हैं कि कौन action कर सकता है। Execution record को फिर भी यह बताना होगा कि action boundary पहले पार हुई थी या नहीं।

HTTP idempotency keys समस्या का केवल एक हिस्सा हल करती हैं

अगर upstream API idempotency keys स्वीकार करती है, तो उनका इस्तेमाल करें। Execution की पूरी अवधि के लिए एक stable value भेजें, target का response persist करें और उसी execution को recover करते समय ही वह value दोबारा इस्तेमाल करें।

उदाहरण के लिए gateway dispatch से पहले execution ID बना सकता है और उसे API के अपेक्षित header से जोड़ सकता है:

POST /v1/releases HTTP/1.1
Host: deploy-api.internal.example
Idempotency-Key: act_01J4K8J7DX7V
Content-Type: application/json

{"service":"catalog","version":"2026.07.22","region":"us-east-1"}

API को यह स्पष्ट करना चाहिए कि header दोबारा आने पर वह क्या करेगी। सबसे अच्छा व्यवहार यह है कि वही semantic request होने पर original result लौटाया जाए और कोई अलग request उसी value को reuse करे तो उसे reject किया जाए। अगर API उसी key के साथ बदले हुए body को चुपचाप स्वीकार करती है, तो आपका gateway replay से सुरक्षित निष्कर्ष नहीं निकाल सकता।

Fingerprint को external idempotency key न बनाएँ, अगर fingerprint जानबूझकर की गई actions के बीच भी बना रह सकता है। Execution ID एक accepted attempt के लिए unique होती है। Fingerprint संभावित रूप से संबंधित attempt खोजती है। दोनों की भूमिकाएँ अलग हैं।

HTTP idempotency अपने-आप SSH के लिए कुछ नहीं करती। आपको remote protocol चाहिए। एक सुरक्षित pattern है कि generated execution ID script को दें, जो host या shared store पर durable status record लिखे और उसी operation को दोबारा शुरू करने से मना करे। अगर command में बदलाव करना या external marker देखना संभव नहीं है, तो उसे irreversible category में रखें और uncertain disconnect के बाद review अनिवार्य करें।

Final count नहीं, sequence की जाँच करें

Matching arguments वाली दो activity rows duplicate साबित नहीं करतीं। Events के sequence से शुरुआत करें और पहली call को उसकी dispatch boundary तक follow करें।

एक वास्तविक investigation को इन सवालों के जवाब क्रम से देने चाहिए:

1. Calls एक agent process ने भेजीं या दो अलग processes ने?
2. क्या पहली call को authorization मिली और वह dispatch में पहुँची?
3. क्या gateway को target से response या exit status मिला?
4. क्या target completion के बाद result delivery विफल हुई?
5. क्या दूसरी call ने original execution ID या idempotency key दोबारा इस्तेमाल की, या नया attempt बनाया?

यह क्रम एक आम गलत निष्कर्ष से बचाता है: «Logs में दो calls हैं, इसलिए agent ने दो बार action की।» हो सकता है gateway ने एक completed execution और उससे attach हुई एक client retry दर्ज की हो। या दो अलग authorized processes मिले, जिनके planning contexts अलग थे और दोनों ने action भेजी। दोनों स्थितियों के fixes अलग होंगे।

Activity store को append-only या किसी अन्य तरीके से tamper-evident रखें। Duplicate investigations अक्सर महँगी घटना के बाद होती हैं, जब कोई व्यक्ति system से बेहतर कहानी बनाना चाहता है। Hash-chained record मूल decision को सही नहीं बनाता, लेकिन बाद की reconstruction में छेड़छाड़ कठिन कर देता है।

Ambiguity agent से भी न छिपाएँ। ऐसा result लौटाएँ जिसमें लिखा हो कि पिछली execution verification की प्रतीक्षा में है या result delivery बाधित होने के बावजूद पूरी हो गई है। Fabricated failure देखने वाला model फिर कोशिश करेगा। स्पष्ट uncertain state देखने वाला model status पूछ सकता है, review माँग सकता है या सुरक्षित रास्ता चुन सकता है।

Replay behavior को हर tool contract का हिस्सा बनाएँ

हर side-effect वाली tool को एक सवाल का स्पष्ट उत्तर देना चाहिए: dispatch के बाद caller response खो दे तो क्या होगा?

यह उत्तर tool definition के पास लिखें। बताएँ कि action read-only है, idempotency identity के साथ दोहराई जा सकती है, status query से recover की जा सकती है या unknown outcome के बाद blocked है। Fingerprint में क्या शामिल होगा और unfinished execution कितने समय तक attachable रहेगी, यह भी लिखें। अगर कोई इसे लिख नहीं सकता, तो tool autonomous use के लिए तैयार नहीं है।

Engineering work आम तौर पर duplicate deployment, duplicate account, duplicate payment या दूसरी credential rotation के बाद होने वाली सफ़ाई से बहुत कम होता है। Target call से पहले execution ID जोड़ें। Dispatch से पहले और बाद में state transitions persist करें। Result reference सुरक्षित रखें। फिर reconnect code को दोबारा बाहरी system से संपर्क करने से पहले उस record को देखना सिखाएँ।

यही standard होना चाहिए: टूटा हुआ transport बातचीत रोक सकता है, लेकिन उसे uncertainty को चुपचाप दूसरी action में बदलने की अनुमति नहीं होनी चाहिए।