Spec के हिसाब से MCP: Server असल में क्या होता है

Wire से पहले arithmetic। आपके पास $N$ AI applications हैं और $M$ चीज़ें हैं जिन तक उन्हें पहुँचने में सक्षम होना चाहिए — calendar, ticket tracker, warehouse database, design tool। Shared contract के बिना, कोई $N \times M$ integrations लिखता है, और हर एक schema plus endpoint plus authentication story plus maintenance burden होता है। Shared contract के साथ, tool vendor server लिखता है, application vendor client लिखता है, और कुल $N + M$ हो जाता है।

यह कोई नई observation नहीं है, और specification बताती है कि idea किसका था:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

इस comparison को तारीफ़ की तरह नहीं, literal तरह से लें। उस protocol से पहले, किसी editor में language support का मतलब था हर editor के लिए अलग plugin; बाद में, language team ने एक server ship किया और हर editor को support मिल गया। सफलता का माप elegance नहीं था, बल्कि यह था कि integration count multiply होना बंद हो गया। यहाँ भी वही बात है: value implementations की संख्या में है, design में नहीं। जिस protocol को दो products ही बोलते हैं, वह extra ceremony वाला data format है।

MCP messages JSON-RPC 2.0 हैं। Request एक object है जिसमें jsonrpc, एक id, एक method और optional params होते हैं; response वही id और या तो result या error रखता है; notification एक request है जिसमें id नहीं होता और कोई reply नहीं मिलता। Specification ऊपर से तीन constraints जोड़ती है: id string या number होना चाहिए और null नहीं होना चाहिए, वह किसी ऐसी दूसरी request से collide नहीं होना चाहिए जो अभी in flight है, और हर result में resultType field होना चाहिए।²

stdio transport पर — वही जो ऊपर वाली command ने use किया — framing rule है: हर message के लिए एक line:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

यह आख़िरी clause homemade server के टूटने का सबसे common तरीका है, और वह silently टूटता है: कोई stray console.log, progress bar, dependency की deprecation warning, और client का line parser ऐसी चीज़ पर पहुँच जाता है जो JSON नहीं है। Escape hatch उसी section में है — server stderr पर जो चाहे लिख सकता है, और client को उसे error नहीं मानना चाहिए। ऊपर वाला reference server हर launch पर Starting default (STDIO) server... print करता है, stderr पर, इसलिए pipe फिर भी काम कर गया।

दूसरा standard transport Streamable HTTP है: हर message एक single endpoint पर POST होता है, और reply या तो JSON object होता है या request-scoped Server-Sent Events stream — वही wire format जिसे Chapter 14 ने हाथ से parse किया था। Semantics दोनों पर identical हैं, क्योंकि transport एक binding है: वह framing और delivery define करता है, meaning नहीं।⁴

ऊपर वाली command ने tools/list भेजा और कुछ नहीं। Current revision के तहत वह request malformed है, और conformant server को उसे reject करना चाहिए।

2026-07-28 से MCP stateless protocol है, और specification इसे बिना लाग-लपेट कहती है:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

इसलिए हर request अपना protocol version और अपनी client capabilities साथ लेकर चलती है, params के अंदर reserved _meta object में। उन fields में से दो हर single request पर required हैं; किसी भी एक के missing होने पर request malformed है और server को -32602 answer करना चाहिए:²

पूरी तरह लिखा हुआ, सही tools/list यह है — और यह आख़िरी बार है जब यह chapter metadata को पूरा दिखाता है, क्योंकि यहाँ से यह हर request पर है:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

Capability object ही negotiation है। अब कोई separate negotiation step नहीं है: client हर request पर declare करता है कि वह क्या कर सकता है, server result में declare करता है कि वह क्या कर सकता है, और कोई भी side ऐसी feature use नहीं कर सकती जिसे दूसरे ने claim न किया हो। अगर server को ऐसी capability चाहिए जो client ने declare नहीं की, तो उसे -32021 answer करना चाहिए और missing capability को data.requiredCapabilities में name करना चाहिए। अगर server requested version नहीं बोलता, तो उसे -32022 answer करना चाहिए और जो versions वह बोलता है उन्हें list करना चाहिए।²

जो clients जवाब पहले से चाहते हैं, वे पूछ सकते हैं: server/discover एक mandatory RPC है जो एक round trip में supported versions, capabilities, identity और instructions का optional block return करता है।⁵ इसे call करना optional है। Implement करना optional नहीं है।

Command काम कर गई। Current revision के तहत ऐसा नहीं होना चाहिए था, और ऐसा क्यों हुआ यह paragraph से ज़्यादा measurement के लायक है, क्योंकि यह पूरी ecosystem की state को एक line में दिखाता है।

Reference server को वैसे probe करें जैसे specification modern client को probe करने के लिए कहती है:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

यह compatibility rule की तीसरी branch है: DiscoverResult का मतलब modern, recognised modern error का मतलब modern-but-wrong-version, और anything else — including -32601 — का मतलब legacy, initialize handshake पर fall back करें।³ तो current revision माँगते हुए वही करें:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

Client ने 2026-07-28 माँगा और server ने 2025-11-25 answer किया। 7 September 2026 को official reference server — npm package @modelcontextprotocol/server-everything, version 2026.8.31, published 31 August 2026 — current revision implement नहीं करता। Dates के हिसाब से, जिस TypeScript SDK पर यह बना है वह भी नहीं: release 1.30.0 27 July 2026 को गया, revision से एक दिन पहले।

Consequence पढ़ें, gossip नहीं। MCP के बारे में लिखी लगभग हर चीज़ ऐसे protocol का वर्णन करती है जिसमें initialize handshake, session, roots/list request जो server client को भेजता है, और HTTP+SSE transport है। ये चारों gone या going हैं। जब भी आप MCP के बारे में कुछ पढ़ें, इस page सहित, सबसे पहले revision number खोजें।

और जो very first command काम कर गई, उसका कारण specification में feature नहीं hazard के रूप में लिखा है:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Measured: उस server को बिना किसी handshake के tools/list भेजना full catalogue return करता है। जिस method को refuse होना चाहिए था, उसे serve किया गया, और यही वजह है कि specification कहती है कि पहले server/discover से probe करें, तब भी जब आप केवल modern versions support करते हों।

MCP में तीन parties हैं, और पहले दो के बीच का distinction वही है जिसे लोग collapse कर देते हैं:

Server. एक process या service जो resources, tools और prompts expose करती है। यह local या remote हो सकती है, independently operate करती है, और इसका पूरा काम एक focused area होता है।⁶

वह “exactly one server” rule bookkeeping नहीं है। यही नीचे वाला design principle implementable बनाता है, और specification से अगर सिर्फ़ एक sentence लेना हो तो यही लें:

Servers should not be able to read the whole conversation, nor “see into” other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

यह उस mental model को उलट देता है जिसके साथ ज़्यादातर लोग आते हैं। जिस weather server को आप अपने assistant से connect करते हैं, वह यह नहीं देखता कि आपने क्या पूछा। वह model द्वारा चुने गए arguments के साथ एक tools/call देखता है, और कुछ नहीं — न previous turns, न आपका system prompt, न calendar server के results जो एक पल पहले लौटे। अगर दो servers को cooperate करना है, तो host जानबूझकर एक value को एक से दूसरे तक ले जाता है, क्योंकि model ने ऐसा कहा। इसीलिए isolation वह security property है जिस पर Chapter 30 टिकता है: compromised server का blast radius छोटा और defined होता है, और उसे बड़ा करने के लिए host को cooperate करना पड़ता है।

पहली command ने उस server से tools माँगे और तेरह मिले। उससे बाकी दो सवाल पूछें तो वह उनका भी जवाब देता है: resources/list सात return करता है, prompts/list चार return करता है। उनमें से कोई दिखाई नहीं दिया, क्योंकि किसी ने पूछा ही नहीं। यही हमें MCP की pedagogical spine तक लाता है, जो specification में एक ऐसी table के रूप में बैठी है जिसे लगभग कोई quote नहीं करता:

यह “capability expose करने के तीन तरीके” नहीं हैं। ये कौन decide करता है कि यह होगा के तीन जवाब हैं। Model decide करता है कि tool call करना है। Application decide करती है कि resource attach करना है। व्यक्ति decide करता है कि prompt run करना है। इसे गलत समझें और feature फिर भी काम करेगी, लेकिन गलत moment पर और गलत reason से।

इसे feel करने का सबसे साफ़ तरीका calendar है। यहाँ एक server है जो उसी calendar को तीन बार expose करता है, हर primitive के रूप में एक बार, plain Node की सौ lines में और बिना dependencies:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

इसे run करें और तीनों तरीकों से पूछें। Real output, wire पर one message per line, page के लिए यहाँ wrapped, request _meta और server का identity block elided:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

तीन methods, तीन shapes, एक calendar। अब point:

लगभग हर कोई इन तीनों को tools बना देता है। Result एक ऐसा catalogue होता है जहाँ application द्वारा silently attach की जाने वाली read, model के attention के लिए ऐसी write से compete करती है जिसे approval चाहिए, और जहाँ वह एक चीज़ जिसके लिए व्यक्ति button चाहता था, schema में buried होती है। इसे सही करने की कोई cost नहीं है, और यह आपके एक line लिखने से पहले decide हो जाता है।

Calendar tool में एक required argument है, title, और optional startsAt। उसे बिना date के event create करने को कहें, और एक दिलचस्प चीज़ वापस आती है:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

Server ने request नहीं भेजी। उसने जो request मिली थी उसका answer दिया, resultType: "input_required" और इस description के साथ कि उसे अभी क्या चाहिए। Client person से answer collect करता है, और फिर original call दोबारा भेजता है — नए id के साथ, inputResponses carry करते हुए और opaque requestState echo करते हुए:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

यह Multi Round-Trip Requests है, current revision में introduced, और इसने पुराने design को replace किया जिसमें servers clients को JSON-RPC requests वापस भेजते थे। Transport specification अब rule flatly कहती है: “servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses”.⁴ Initiative की एक direction है, और वह host की है।

दो client-side features इसी mechanism पर ride करती हैं, और उनमें से एक का नाम आपको confuse करेगा।

Elicitation server द्वारा person से कुछ माँगना है: deliberately restricted JSON Schema वाला form — flat objects, primitive properties, no nesting — ताकि कोई भी client उसे बिना layout engine render कर सके। इसमें hard rule है: servers form mode का use “passwords, API keys, access tokens, or payment credentials” माँगने के लिए नहीं कर सकते, और उनके लिए URL mode use करना चाहिए, जो user को उस page पर भेजता है जिसे client कभी नहीं पढ़ता।⁷

Sampling server द्वारा host के model से generation माँगना है, ताकि server API key रखे बिना intelligent हो सके। और यहाँ vocabulary warning है, क्योंकि यह word इस course में पहले से कुछ और meaning रखता है: यह Chapter 17 वाला sampling नहीं है। यहाँ temperature, top-p या probability distribution की shape के बारे में कुछ नहीं है। यह protocol के through backwards travel करने वाली nested model call है।

इसे reach न करने की दूसरी वजह है: इस revision तक, sampling deprecated है, roots और logging के साथ, SEP-2577 के तहत, और migration suggestion blunt है — “integrate directly with LLM provider APIs instead of Sampling”.⁸ Idea technically fail नहीं हुआ; वह अपने surface area को justify नहीं कर पाया, और जो protocol चीज़ें remove कर सकता है वह उस protocol से healthy है जो नहीं कर सकता।

Statelessness wire-format detail जैसी लगती है जब तक आप इसे test नहीं करते। ऊपर वाला three-message exchange लें और हर message को separate process में run करें — fresh node calendar.mjs, no shared memory, कुछ भी carry over नहीं:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

Process B, जिसने question कभी देखा ही नहीं, ने process A द्वारा शुरू की गई multi-round-trip call complete कर दी। requestState का point यही है: continuation message में travel करता है, इसलिए कुछ भी process के वही होने पर depend नहीं करता।

Process C failure है। Event created हुआ और वहाँ नहीं है — क्योंकि toy server EVENTS को module-level array में रखता है, और module-level array connection state है। Specification का note mistake को precise नाम देता है:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

Prescribed fix session नहीं है। यह explicit handle है: creation tool opaque identifier return करता है, और हर later call उसे ordinary argument की तरह लेती है। Protocol में इसका concept है ही नहीं — “from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls”.⁹ इससे model उसे carry करने का जिम्मेदार बनता है, और server हर single call पर validate करने का जिम्मेदार कि यह caller उसे use करने की अनुमति रखता है, क्योंकि handle एक name है, permission नहीं।

Server जो भी tool expose करता है वह schema है जो हर request पर आपके prompt में जाता है, और Chapter 24 ने measure किया था कि window पर उसका क्या असर होता है। MCP एक second line item जोड़ता है जिसे miss करना आसान है, इसलिए ऊपर वाले reference server पर दोनों count करने लायक हैं।

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

दो observations। पहली arithmetic है: इस size के पाँच servers connect करें और आपकी window के roughly आठ हज़ार tokens हर turn पर, हमेशा के लिए, spoken for हैं, चाहे model उनमें से किसी का use करे या नहीं — यही mechanism Chapter 24 द्वारा quote किए गए 150,000-to-2,000 reduction के पीछे है, और यही वजह है कि just-in-time tool discovery मौजूद है।

दूसरी security note है जो accounting costume पहने हुए है। instructions natural-language text है, server author द्वारा लिखा हुआ, जो host के prompt में land करता है, और उसके बगल के tool descriptions भी वही हैं। Specification अपने security principles में बताती है कि इसके बारे में क्या करना है: tool annotations और descriptions को “should be considered untrusted, unless obtained from a trusted server” माना जाना चाहिए, और hosts को “must obtain explicit user consent before invoking any tool”.¹ MCP server connect करना dependency add करना नहीं है। यह किसी अजनबी को आपके system prompt के 1,619 tokens और call किए जाने का right देना है। Chapter 30 बताता है कि जब वह अजनबी hostile हो तो क्या होता है।

इस section की हर बात protocol revision 2026-07-28, current one, के लिए सही है, जिसे 7 September 2026 को पढ़ा गया। Revisions YYYY-MM-DD dated होती हैं और date वह आख़िरी समय है जब backwards-incompatible change किया गया था।¹⁰ Normative document एक TypeScript file है, schema/2026-07-28/schema.ts; उसके साथ की JSON Schema उसी से generated है, इसलिए यहाँ specification TypeScript में पढ़ी गई है और MCP को किसी और चीज़ से teach करना translation teach करना है।

उस table के नीचे governance change किसी भी single row से ज़्यादा matter करता है। इस revision ने feature lifecycle and deprecation policy adopt की: features Active, Deprecated या Removed होती हैं, deprecated feature अपना migration path document करती है और removal के लिए eligible होने से पहले कम से कम twelve months तक specification में रहती है, और एक registry है जो currently Deprecated state में मौजूद हर चीज़ list करती है।⁸ उस policy से पहले, AI protocol में “deprecated” का मतलब वही था जो आख़िरी blog post ने कहा। अब इसका मतलब date है।

पूरे block की vocabulary एक जगह।

इनमें से दो को एक-एक sentence चाहिए, क्योंकि confusion असल में वहीं रहती है।

MCP against A2A rivalry नहीं है, और दोनों specifications ऐसा कहती हैं। A2A documentation दूसरी तरफ़ क्या है इसके आधार पर line draw करता है: MCP “defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API”, जहाँ tool “specific, often stateless, functions” perform करता है; A2A agents को address करता है, “more autonomous systems” जो “reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues”। इसका अपना summary याद रखने वाला sentence है: “A2A is about agents partnering on tasks, while MCP is more about agents using capabilities.”¹¹ दोनों nest होते हैं — application दूसरे agents तक पहुँचने के लिए A2A use करती है, और हर agent अपने tools तक पहुँचने के लिए MCP use करता है। Chapter 25 ने यही line एक process के अंदर draw की थी, sub-agent से पूछने और उसे conversation hand करने के बीच; A2A इसे organisations के बीच draw करता है।

MCP against ACP stale premise वाला comparison है, और ठीक इसी वजह से इसका जवाब देना worth है। Agent Communication Protocol agent-to-agent messaging के लिए separate open standard था। इसकी अपनी documentation अब इस notice से खुलती है: “ACP is now part of A2A under the Linux Foundation!”¹² September 2026 में “MCP or ACP?” का honest answer है कि question में उन pages की तुलना में एक option कम है जो इसके लिए rank कर रहे हैं।

और जिस comparison के लिए लोग सबसे ज़्यादा पूछते हैं, mcp vs api, उसका answer सबसे कम interesting है: MCP एक API है। यह जो add करता है वह power नहीं, conventions हैं — method names का fixed set, discovery call, primitives पर control hierarchy, और isolation model। आप अपना interface design करने की freedom छोड़ते हैं और बदले में हर host पाते हैं जो protocol बोलता है, जो हर protocol द्वारा offered trade रहा है।

अब आप specification को translator के बिना पढ़ सकते हैं, resource को tool और prompt से इस आधार पर अलग कर सकते हैं कि control किसके पास है, जब client library आपसे झूठ बोल रही हो तो request हाथ से type कर सकते हैं, और कोई भी MCP article पढ़ते समय यह date कर सकते हैं कि वह कौन-सी deprecated features को अभी भी current की तरह teach कर रहा है।

जो आपने नहीं किया है वह है इसे ship करना। Chapter 27 वही server दो बार लिखता है — TypeScript और Python, side by side, क्योंकि MCP इस course का एक genuinely bilingual territory है और numbers दोनों directions में यही कहते हैं। यह दोनों live transports को properly cover करता है, inspector, packaging, और protocol का वह आधा हिस्सा जिसे इस chapter ने जानबूझकर छोड़ा: authorization। क्योंकि जैसे ही आपका server आपके अपने laptop पर subprocess होने के बजाय remote होता है, किसी अजनबी का client token present करेगा, और specification का rule कि आप उसके साथ क्या कर सकते हैं unusually strict है।

जिससे वह सवाल उठता है जिसका जवाब next chapter को देना है, और वह friendly नहीं है: अगर कोई token आपके server पर आता है और वह किसी और audience के लिए issued था, तो आपको उसे forward करने से exactly क्या रोकता है?

इस chapter में हर quotation, method name, error code और rule Model Context Protocol specification, revision 2026-07-28, से पढ़ा गया, 7 September 2026 को। हर trace locally Node 22 पर produced हुआ: toy calendar server 101 lines का है, बिना dependencies, और reference server नीचे named published npm package है। इस chapter को लिखने में कोई paid API call नहीं की गई — यहाँ किसी model की ज़रूरत नहीं है, और यही point है।

Measurements: @modelcontextprotocol/server-everything@2026.8.31, published 31 August 2026, built on @modelcontextprotocol/sdk@1.30.0, published 27 July 2026 — उस revision से एक दिन पहले जिसे यह chapter describe करता है। यह server/discover का answer -32601 से देता है, 2026-07-28 माँगने पर 2025-11-25 negotiate करता है, और बिना handshake tools/list serve करता है। इसका catalogue 13 tools in 7,663 bytes है; token counts tiktoken के via o200k_base हैं, हर definition के name, description और inputSchema पर, जो provider आपके prompt में render करता है और JSON-RPC frame का weight नहीं है।

Anthropic, Code execution with MCP: building more efficient agents, 4 November 2025, 150,000-to-2,000 figure का source है, जिसे Chapter 24 में quote और use किया गया और यहाँ केवल referenced है।