MCP کو spec کے مقابل سمجھیں: 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 ہوتا ہے۔ ایک contract کے ساتھ، tool vendor ایک server لکھتا ہے، application vendor ایک client لکھتا ہے، اور total $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 کو compliment نہیں بلکہ literal سمجھیں۔ اس protocol سے پہلے، کسی editor میں language support کا مطلب ہر editor کے لیے ایک plugin تھا؛ بعد میں، language team نے ایک server ship کیا اور ہر editor کو support مل گیا۔ کامیابی کا پیمانہ elegance نہیں تھا؛ یہ تھا کہ integration count multiply ہونا بند ہو گیا۔ یہی بات یہاں بھی لاگو ہوتی ہے: value design میں نہیں، implementations کی تعداد میں ہے۔ ایک 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 نہیں ہونا چاہیے، یہ کسی اور in-flight request سے collide نہیں کرنا چاہیے، اور ہر result میں resultType field ہونا چاہیے۔²

stdio transport پر — وہی جو اوپر command نے استعمال کیا — framing rule ہے: ہر message کے لیے ایک لائن:

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 ٹوٹتا ہے، اور خاموشی سے ٹوٹتا ہے: ایک 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... پر stderr print کرتا ہے، اسی لیے 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 اسے بغیر hedging کہتی ہے:

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 ہیں؛ جس request میں ان میں سے کوئی missing ہو وہ 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 ہے۔ اب کوئی الگ negotiation step نہیں: client ہر request پر declare کرتا ہے کہ وہ کیا کر سکتا ہے، server result میں declare کرتا ہے کہ وہ کیا کر سکتا ہے، اور کوئی side ایسا feature use نہیں کر سکتی جس کا claim دوسری side نے نہ کیا ہو۔ جس server کو ایسی capability چاہیے جو client نے declare نہیں کی، اسے -32021 answer کرنا چاہیے اور missing capability کو data.requiredCapabilities میں نام دینا چاہیے۔ جو server requested version نہیں بولتا، اسے -32022 answer کرنا چاہیے اور وہ versions list کرنے چاہئیں جو وہ بولتا ہے۔²

جو clients answer پہلے ہی چاہیں وہ پوچھ سکتے ہیں: server/discover ایک mandatory RPC ہے جو supported versions، capabilities، identity اور instructions کا optional block ایک round trip میں واپس کرتا ہے۔⁵ اسے call کرنا optional ہے۔ implement کرنا نہیں۔

command چلی۔ current revision کے تحت اسے نہیں چلنا چاہیے تھا، اور وجہ paragraph کے بجائے measurement کی مستحق ہے، کیونکہ یہ ایک لائن میں پوری ecosystem کی حالت ہے۔

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 — بشمول -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 سے ایک دن پہلے۔

gossip کے بجائے consequence پڑھیں۔ MCP کے بارے میں لکھی گئی تقریباً ہر چیز ایک ایسے protocol کو describe کرتی ہے جس میں initialize handshake، session، ایک roots/list request جو server client کو بھیجتا ہے، اور HTTP+SSE transport ہے۔ چاروں ختم ہو چکے ہیں یا ختم ہو رہے ہیں۔ MCP کے بارے میں کچھ بھی پڑھتے وقت، اس page سمیت، سب سے پہلے revision number دیکھیں۔

اور وجہ کہ پہلی 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 واپس آتا ہے۔ ایک method جسے refuse ہونا چاہیے تھا served ہو گیا، اسی لیے 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 کرتے ہیں، یہ نہیں دیکھتا کہ آپ نے کیا پوچھا۔ یہ ایک tools/call دیکھتا ہے ان arguments کے ساتھ جو model نے منتخب کیے، اور کچھ نہیں — نہ previous turns، نہ آپ کا system prompt، نہ وہ results جو calendar server نے ایک لمحہ پہلے واپس کیے۔ اگر دو servers کو cooperate کرنا ہو، host جان بوجھ کر ایک value کو ایک سے دوسرے تک لے جاتا ہے، کیونکہ model نے اس سے کہا۔ اسی لیے isolation وہ security property ہے جس پر Chapter 30 rely کرتا ہے: compromised server کا blast radius چھوٹا اور defined ہوتا ہے، اور اسے بڑا کرنے کے لیے host کا cooperate کرنا ضروری ہے۔

پہلی command نے اس server سے tools مانگے اور تیرہ ملے۔ اسے باقی دو questions پوچھیں تو وہ ان کے بھی answer دیتا ہے: resources/list سات واپس کرتا ہے، prompts/list چار واپس کرتا ہے۔ ان میں سے کوئی ظاہر نہیں ہوا، کیونکہ کسی نے پوچھا ہی نہیں۔ یہی ہمیں MCP کی pedagogical spine تک لے آتا ہے، specification میں ایک table کے طور پر موجود جسے تقریباً کوئی quote نہیں کرتا:

یہ “capability expose کرنے کے تین طریقے” نہیں۔ یہ کون decide کرتا ہے کہ یہ ہوتا ہے کے تین answers ہیں۔ model tool call کرنے کا decide کرتا ہے۔ application resource attach کرنے کا decide کرتی ہے۔ شخص prompt چلانے کا decide کرتا ہے۔ یہ غلط سمجھیں تو feature پھر بھی کام کرتا ہے، مگر غلط وقت پر اور غلط وجہ سے۔

اسے محسوس کرنے کا سب سے صاف طریقہ 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 پر ہر line میں ایک message، 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 بنا دیتا ہے۔ نتیجہ ایک catalogue ہوتا ہے جہاں وہ read جسے application کو silently attach کرنا چاہیے تھا، model کی attention کے لیے ایسے write کے ساتھ compete کرتا ہے جسے approval چاہیے، اور جس ایک چیز کے لیے شخص button چاہتا تھا وہ schema میں دفن ہوتی ہے۔ اسے صحیح کرنے کی 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 شخص سے 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 میں introduce ہوا، اور اس نے وہ older design replace کیا جہاں servers JSON-RPC requests clients کو واپس بھیجتے تھے۔ transport specification اب rule سیدھا کہتی ہے: “servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses”.⁴ initiative کی ایک direction ہے، اور وہ host کی ہے۔

دو client-side features اس mechanism پر سوار ہیں، اور ان میں سے ایک کا نام آپ کو پھسلا دے گا۔

Elicitation server کا شخص سے کچھ مانگنا ہے: ایک form، جان بوجھ کر restricted JSON Schema کے ساتھ — flat objects، primitive properties، no nesting — تاکہ کوئی بھی client اسے layout engine کے بغیر render کر سکے۔ اس میں hard rule ہے: servers form mode کو “passwords, API keys, access tokens, or payment credentials” مانگنے کے لیے must not use کریں، اور ان کے لیے URL mode must use کریں، جو user کو ایک ایسے page پر بھیجتا ہے جسے client کبھی نہیں پڑھتا۔⁷

Sampling server کا host کے model سے generation مانگنا ہے، تاکہ server API key رکھے بغیر intelligent ہو سکے۔ اور یہاں vocabulary warning ہے، کیونکہ یہ لفظ اس course میں پہلے ہی کچھ اور mean کرتا ہے: یہ Chapter 17 والی sampling نہیں۔ یہاں temperature، top-p یا probability distribution کی shape کی بات نہیں۔ یہ nested model call ہے جو protocol کے ذریعے الٹی direction میں سفر کرتی ہے۔

اسے فوراً use نہ کرنے کی دوسری وجہ بھی ہے: اس revision کے مطابق، sampling deprecated ہے، roots اور logging کے ساتھ، SEP-2577 کے تحت، ایک صاف suggested migration کے ساتھ — “integrate directly with LLM provider APIs instead of Sampling”.⁸ idea technically fail نہیں ہوا؛ اس نے اپنی surface area justify نہیں کی، اور ایسا protocol جو چیزیں remove کر سکتا ہو اس سے زیادہ 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 کبھی نہیں دیکھا، نے وہ multi-round-trip call complete کر دیا جو process A نے start کیا تھا۔ requestState کا point یہی ہے: continuation message میں travel کرتی ہے، اس لیے کچھ بھی اس پر depend نہیں کرتا کہ process وہی ہے یا نہیں۔

Process C failure ہے۔ event created ہوا اور وہاں نہیں ہے — کیونکہ toy server EVENTS کو module-level array میں رکھتا ہے، اور module-level array connection state ہے۔ specification کا note mistake کو بالکل نام دیتا ہے:

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 واپس کرتا ہے، اور ہر بعد کی 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 نام ہے، permission نہیں۔

ہر tool جو server expose کرتا ہے، ایک schema ہے جو ہر request پر آپ کے prompt میں جاتا ہے، اور Chapter 24 نے measure کیا کہ یہ window کے ساتھ کیا کرتا ہے۔ MCP ایک second line item add کرتا ہے جسے 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 کے تقریباً آٹھ ہزار tokens ہر turn پر ہمیشہ کے لیے spoken for ہیں، چاہے model ان میں سے کوئی use کرے یا نہ کرے — یہی وہ mechanism ہے 150,000-to-2,000 reduction کے پیچھے جسے Chapter 24 نے quote کیا، اور یہی وجہ ہے کہ just-in-time tool discovery موجود ہے۔

دوسری security note ہے جو accounting costume پہنے ہوئے ہے۔ instructions natural-language text ہے، server author کی لکھی ہوئی، جو host کے prompt میں اترتی ہے، اور اس کے ساتھ 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 ہونے کا حق دینا ہے۔ Chapter 30 وہ ہے جو ہوتا ہے جب وہ اجنبی hostile ہو۔

اس section کی ہر چیز protocol revision 2026-07-28 کے لیے درست ہے، current one، 7 September 2026 کو read کی گئی۔ 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 سے زیادہ important ہے۔ اس 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 each deserve کرتے ہیں، کیونکہ confusion اصل میں وہیں رہتی ہے۔

MCP against A2A rivalry نہیں، اور دونوں specifications یہی کہتی ہیں۔ A2A documentation line کھینچتی ہے کہ دوسری end پر کیا ہے: 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 کے اندر کھینچی تھی، sub-agent سے پوچھنے اور اسے conversation hand کرنے کے درمیان؛ A2A اسے organisations کے درمیان کھینچتا ہے۔

MCP against ACP stale premise کے ساتھ comparison ہے، اسی لیے اسے answer کرنا worth ہے۔ Agent Communication Protocol agent-to-agent messaging کے لیے الگ open standard تھا۔ اس کی own documentation اب notice سے open ہوتی ہے: “ACP is now part of A2A under the Linux Foundation!”¹² September 2026 میں “MCP or ACP?” کا honest answer یہ ہے کہ question میں ranking pages کے suggest کرنے سے ایک option کم ہے۔

اور وہ comparison جو لوگ سب سے زیادہ مانگتے ہیں، mcp vs api، اس کا answer سب سے کم interesting ہے: MCP ایک API ہے۔ یہ power add نہیں کرتا، conventions add کرتا ہے — method names کا fixed set، discovery call، primitives پر control hierarchy، اور isolation model۔ آپ اپنی interface design کرنے کی freedom چھوڑتے ہیں اور بدلے میں ہر host پاتے ہیں جو protocol بولتا ہے، یہی trade ہر protocol نے ہمیشہ offer کی ہے۔

اب آپ specification کو translator کے بغیر پڑھ سکتے ہیں، resource کو tool سے اور tool کو prompt سے اس بنیاد پر الگ کر سکتے ہیں کہ charge کس کے پاس ہے، جب client library آپ سے lie کر رہی ہو تو request ہاتھ سے type کر سکتے ہیں، اور کوئی بھی MCP article پڑھتے وقت اسے date کر سکتے ہیں کہ وہ deprecated features میں سے کن کو ابھی بھی current کے طور پر teach کرتا ہے۔

جو آپ نے نہیں کیا وہ اسے ship کرنا ہے۔ Chapter 27 یہی server دو بار لکھتا ہے — TypeScript اور Python، ساتھ ساتھ، کیونکہ MCP اس course کا ایک genuinely bilingual territory ہے اور numbers دونوں directions میں یہی کہتے ہیں۔ یہ دونوں live transports properly cover کرتا ہے، inspector، packaging، اور protocol کا وہ آدھا حصہ جسے اس chapter نے deliberately چھوڑا: authorization۔ کیونکہ جس لمحے آپ کا server آپ کے اپنے laptop پر subprocess کے بجائے remote ہوتا ہے، کسی اجنبی کا client token present کرے گا، اور specification کا rule کہ آپ اس کے ساتھ کیا کر سکتے ہیں unusually strict ہے۔

جو next chapter کو answer کرنے والا سوال اٹھاتا ہے، اور وہ friendly نہیں: اگر token آپ کے server پر آئے اور وہ کسی اور کے audience کے لیے issued ہو، تو بالکل کیا چیز آپ کو اسے forward کرنے سے روکتی ہے؟

اس chapter میں ہر quotation، method name، error code اور rule Model Context Protocol specification، revision 2026-07-28، سے پڑھا گیا، 7 September 2026 کو۔ ہر trace Node 22 پر locally produced ہوا: toy calendar server 101 lines ہے، no 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 — اس chapter کی described revision سے ایک دن پہلے۔ یہ server/discover کو -32601 کے ساتھ answer کرتا ہے، 2026-07-28 مانگنے پر 2025-11-25 negotiate کرتا ہے، اور بغیر handshake کے tools/list serve کرتا ہے۔ اس کا catalogue 13 tools ہے 7,663 bytes میں؛ token counts o200k_base via tiktoken ہیں، ہر definition کے name، description اور inputSchema پر، جو provider آپ کے prompt میں render کرتا ہے نہ کہ JSON-RPC frame کا وزن۔

Anthropic, Code execution with MCP: building more efficient agents, 4 November 2025, 150,000-to-2,000 figure کا source ہے، Chapter 24 میں quote اور use کیا گیا اور یہاں صرف referenced ہے۔