MCP a specifikáció tükrében: mi is valójában egy szerver

A wire előtt jöjjön az aritmetika. Van $N$ AI-alkalmazásod és $M$ dolog, amelyet el kellene érniük — naptár, jegykezelő, raktári adatbázis, dizájneszköz. Közös szerződés nélkül valaki $N \times M$ integrációt ír, és mindegyik egy séma, egy endpoint, egy hitelesítési történet és egy karbantartási teher. Közös szerződéssel a tool szállítója ír egy szervert, az alkalmazás szállítója ír egy klienst, és az összeg $N + M$.

Ez nem új megfigyelés, és a specifikáció meg is mondja, kinek az ötlete volt:

Az MCP részben a Language Server Protocolból merít inspirációt, amely szabványosítja, hogyan lehet programozási nyelvek támogatását hozzáadni fejlesztőeszközök teljes ökoszisztémájához. Hasonló módon az MCP azt szabványosítja, hogyan lehet további kontextust és toolokat integrálni az AI-alkalmazások ökoszisztémájába.¹

Vedd ezt az összehasonlítást szó szerint, ne bókként. A protokoll előtt egy nyelv támogatása egy szerkesztőben szerkesztőnként egy plugint jelentett; utána a nyelvi csapat kiadott egyetlen szervert, és minden szerkesztő megkapta. A siker mércéje nem az elegancia volt, hanem az, hogy az integrációk száma nem szorzódott tovább. Ugyanez következik itt is: az érték a megvalósítások számában van, nem a dizájnban. Egy protokoll, amelyet két termék beszél, nem más, mint adatformat extra ceremóniával.

Az MCP-üzenetek JSON-RPC 2.0 üzenetek. Egy request egy objektum jsonrpc, id, method és opcionális params mezővel; egy response ugyanazt a id értéket viszi, és vagy result, vagy error mezőt tartalmaz; egy notification olyan request, amelynek nincs id mezője, és nem kap választ. A specifikáció erre három korlátot tesz rá: a id string vagy szám lehet, és nem lehet null, nem ütközhet más, még folyamatban lévő requesttel, és minden resultnak tartalmaznia kell egy resultType mezőt.²

A stdio transporton — azon, amelyet a fenti parancs használt — a keretezési szabály üzenetenként egy sor:

Az üzeneteket sortörések választják el, és NEM tartalmazhatnak beágyazott sortöréseket. […] A szerver NEM írhat a stdout kimenetére semmit, ami nem érvényes MCP-üzenet.³

Ez az utolsó kitétel a leggyakoribb módja annak, hogy egy házi szerver elromoljon, és csendben romlik el: egy kósza console.log, egy progress bar, egy függőség deprecation warningja, és a kliens sorparserje olyasmibe ütközik, ami nem JSON. A menekülőút ugyanabban a szakaszban van — a szerver írhat bármit a stderr kimenetére, és a kliensnek ezt nem kellene hibaként kezelnie. A fenti referencia-szerver minden indításkor Starting default (STDIO) server... értéket ír a stderr kimenetre, ezért működött a pipe.

A másik szabványos transport a Streamable HTTP: minden üzenet egy POST egyetlen endpointra, a válasz pedig vagy JSON-objektum, vagy a requesthez kötött Server-Sent Events stream — az a wire format, amelyet a 14. fejezet kézzel parse-olt. A szemantika mindkettőn azonos, mert a transport binding: a keretezést és kézbesítést definiálja, nem a jelentést.⁴

A fenti parancs tools/list értéket küldött, és semmi mást. A jelenlegi revízió szerint ez a request hibás, és egy szabálykövető szervernek vissza kell utasítania.

2026-07-28 óta az MCP állapotmentes protokoll, és a specifikáció ezt kertelés nélkül mondja ki:

A Model Context Protocol (MCP) állapotmentes protokoll: minden információ, amely egy request feldolgozásához szükséges, magában a requestben található. A szerver minden requestet önállóan dolgoz fel; nem szabad állapotot kikövetkeztetni korábbi requestekből, még akkor sem, ha ugyanazon a kapcsolaton vagy streamen érkeztek.²

Ezért minden request viszi a saját protokollverzióját és a saját kliensképességeit egy fenntartott _meta objektumban a params belsejében. Ezek közül két mező minden egyes requesten kötelező; ha bármelyik hiányzik, a request hibás, és a szervernek -32602 választ kell adnia:²

Kiírva egy helyes tools/list így néz ki — és ebben a fejezetben most látod utoljára teljes egészében a metaadatot, mert innentől minden requesten rajta van:

{"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"}}}}

A capability objektum maga a negotiation. Már nincs külön negotiation lépés: a kliens minden requesten deklarálja, mire képes, a szerver a resultban deklarálja, mire képes, és egyik oldal sem használhat olyan feature-t, amelyet a másik nem állított magáról. Ha egy szervernek olyan capability kell, amelyet a kliens nem deklarált, -32021 választ kell adnia, és a hiányzó capability nevét meg kell adnia a data.requiredCapabilities mezőben. Ha egy szerver nem beszéli a kért verziót, -32022 választ kell adnia, és fel kell sorolnia az általa beszélt verziókat.²

Azok a kliensek, amelyek előre akarják tudni a választ, megkérdezhetik: a server/discover kötelező RPC, amely egy körben adja vissza a támogatott verziókat, capabilityket, identitást és egy opcionális instructions blokkot.⁵ Meghívni opcionális. Implementálni nem az.

A parancs működött. A jelenlegi revízió szerint nem kellett volna, és az okát inkább mérni érdemes, mint bekezdésben leírni, mert egyetlen sorban mutatja az egész ökoszisztéma állapotát.

Probe-old a referencia-szervert úgy, ahogy a specifikáció szerint egy modern kliensnek kell:

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"}}

Ez a kompatibilitási szabály harmadik ága: a DiscoverResult modernt jelent, egy felismert modern hiba azt jelenti, hogy modern, de rossz verzió, és bármi más — beleértve a -32601 értéket — legacyt jelent, vissza kell esni a initialize handshake-re.³ Tehát tedd ezt, a jelenlegi revíziót kérve:

→ {"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":"…"}}

A kliens 2026-07-28 értéket kért, a szerver pedig 2025-11-25 értékkel válaszolt. 2026. szeptember 7-én a hivatalos referencia-szerver — az @modelcontextprotocol/server-everything nevű npm package, 2026.8.31 verzió, publikálva 2026. augusztus 31-én — nem implementálja a jelenlegi revíziót. Dátumok alapján az a TypeScript SDK sem, amelyre épül: a 1.30.0 release 2026. július 27-én jelent meg, egy nappal a revízió előtt.

A következményt olvasd, ne a pletykát. Szinte minden, amit MCP-ről írtak, olyan protokollt ír le, amelyben van initialize handshake, session, a szerver által a kliensnek küldött roots/list request, és HTTP+SSE transport. Mind a négy eltűnt vagy eltűnőben van. Amikor bármit olvasol MCP-ről, beleértve ezt az oldalt is, az első dolog, amit keress, a revíziószám.

És hogy a legelső parancs miért működött, azt a specifikáció veszélyként, nem feature-ként írja le:

egyes legacy szerverek nem ellenőrzik, hogy a request a initialize után érkezik-e, és egy korszak szerint kétértelmű metódust, például a tools/call metódust, legacy szemantika szerint dolgoznának fel. A probing determinisztikus hibát eredményez helyette.³

Mérve: ha tools/list kerül elküldésre annak a szervernek handshake nélkül, visszaadja a teljes katalógust. Egy metódus, amelyet vissza kellett volna utasítani, kiszolgálásra került — pontosan ezért mondja a specifikáció, hogy először server/discover értékkel kell probe-olni akkor is, ha csak modern verziókat támogatsz.

Az MCP-nek három szereplője van, és az első kettő közötti különbséget szokták az emberek összemosni:

Server. Egy folyamat vagy szolgáltatás, amely erőforrásokat, toolokat és promptokat tesz elérhetővé. Lehet lokális vagy távoli, önállóan működik, és az egész feladata egy fókuszált terület.⁶

Ez a „pontosan egy szerver” szabály nem adminisztráció. Ettől válik implementálhatóvá az alábbi tervezési elv, és ha csak egy mondatot viszel magaddal a specifikációból, ez legyen az:

A szervereknek nem szabad tudniuk elolvasni a teljes beszélgetést, és nem szabad „belátniuk” más szerverekbe. A szerverek csak a szükséges kontextuális információt kapják meg. A teljes beszélgetési előzmény a hostnál marad. Minden szerver megőrzi az izolációt. A szerverek közötti interakciókat a host irányítja.⁶

Ez felborítja azt a mentális modellt, amellyel a legtöbben érkeznek. Egy időjárás-szerver, amelyet az asszisztensedhez csatlakoztatsz, nem látja, mit kérdeztél. Egy tools/call hívást lát azokkal az argumentumokkal, amelyeket a model választott, és semmi mást — nem a korábbi köröket, nem a system promptodat, nem azokat az eredményeket, amelyeket a naptárszerver egy pillanattal korábban visszaadott. Ha két szervernek együtt kell működnie, a host visz át egy értéket az egyiktől a másikhoz, szándékosan, mert a model ezt kérte. Ezért az izoláció az a biztonsági tulajdonság, amelyre a 30. fejezet támaszkodik: egy kompromittált szervernek kicsi, definiált blast radiusa van, és a megnöveléséhez a host együttműködése kell.

Az első parancs toolokat kért attól a szervertől, és tizenhármat kapott. Kérdezd meg a másik két módon is, és arra is válaszol: a resources/list hetet ad vissza, a prompts/list négyet. Egyik sem jelent meg, mert semmi nem kérte őket. Ez vezet el az MCP pedagógiai gerincéhez, amely a specifikációban egy olyan táblázatként ül, amelyet szinte senki nem idéz:

Nem „három mód egy capability kitetetésére”. Három válasz arra, hogy ki dönti el, hogy ez megtörténik. A model dönt úgy, hogy toolt hív. Az alkalmazás dönt úgy, hogy erőforrást csatol. Az ember dönt úgy, hogy promptot futtat. Ha ezt rosszul érted, a feature továbbra is működik, csak rossz pillanatban és rossz okból.

A legjobban egy naptáron lehet megérezni. Itt egy szerver, amely ugyanazt a naptárat háromszor teszi elérhetővé, egyszer mindegyik primitívként, száz sor egyszerű Node-ban, függőségek nélkül:

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" });
}

Futtasd, és kérdezd meg mindhárom módon. Valódi output, wire-on soronként egy üzenet, itt az oldal kedvéért tördelve, a request _meta és a szerver identity blokkja kihagyva:

→ 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}

Három metódus, három alak, egy naptár. Most jön a lényeg:

Szinte mindenki mindhármat toolként készíti el. Az eredmény egy olyan katalógus, ahol egy olvasás, amelyet az alkalmazásnak csendben kellett volna csatolnia, a model attention-jéért versenyez egy olyan írással, amely jóváhagyást igényel, és ahol az az egy dolog, amelyhez az ember gombot szeretett volna, el van temetve egy sémában. Semmibe sem kerül jól dönteni, és ez még az első sor megírása előtt eldől.

A naptár-toolnak egy kötelező argumentuma van, title, és egy opcionális, startsAt. Kérd meg, hogy hozzon létre eseményt dátum nélkül, és érdekes dolog jön vissza:

→ 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=="}

A szerver nem küldött requestet. Válaszolt arra, amelyet kapott, resultType: "input_required" mezővel és annak leírásával, mire van még szüksége. A kliens begyűjti a választ az embertől, majd újraküldi az eredeti hívást — új id értékkel, inputResponses mezőt víve és visszhangozva az átlátszatlan requestState értéket:

→ 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}

Ez a Multi Round-Trip Requests, amelyet a jelenlegi revízió vezetett be, és amely leváltotta a régebbi dizájnt, ahol a szerverek JSON-RPC requesteket küldtek vissza a klienseknek. A transport specifikáció most laposan kimondja a szabályt: „a szerverek nem kezdeményeznek JSON-RPC requesteket, és a kliensek nem küldenek JSON-RPC response-okat”.⁴ Egyetlen iránya van a kezdeményezésnek, és az a hosté.

Két kliensoldali feature ül ezen a mechanizmuson, és az egyiknek olyan neve van, amely meg fog botlasztani.

Elicitation az, amikor a szerver az embertől kér valamit: egy form szándékosan korlátozott JSON Schema-val — lapos objektumok, primitív propertyk, nincs nesting —, hogy bármely kliens renderelni tudja layout engine nélkül. Kemény szabályt visz: a szerverek nem használhatják a form módot „jelszavak, API-kulcsok, access tokenek vagy fizetési credentialök” bekérésére, és ezekhez URL módot kell használniuk, amely a felhasználót olyan oldalra küldi, amelyet a kliens soha nem olvas.⁷

Sampling az, amikor a szerver a host modeljétől kér generationt, hogy egy szerver intelligens lehessen API-kulcs birtoklása nélkül. És itt jön a szókészleti figyelmeztetés, mert ez a szó ebben a kurzusban már valami mást jelent: ez nem a 17. fejezet samplingje. Itt semmi nem szól temperature-ről, top-p-ről vagy egy valószínűségi eloszlás alakjáról. Ez egy protokollon visszafelé utazó beágyazott modelhívás.

Van egy második ok is, hogy ne nyúlj érte: ettől a revíziótól kezdve a sampling deprecated, a roots és logging mellett, SEP-2577 alatt, egy nyers migrációs javaslattal — „integrálj közvetlenül az LLM provider API-jaival Sampling helyett”.⁸ Az ötlet nem technikailag bukott meg; nem tudta igazolni a saját felületét, és egy protokoll, amely képes dolgokat eltávolítani, egészségesebb annál, amelyik nem.

Az állapotmentesség wire-format részletnek hangzik, amíg ki nem próbálod. Vedd a fenti háromüzenetes cserét, és futtasd mindegyik üzenetet külön folyamatban — friss node calendar.mjs, nincs közös memória, semmi nem megy át:

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)

A B folyamat, amely soha nem látta a kérdést, befejezett egy multi-round-trip hívást, amelyet az A folyamat indított. Ez a requestState lényege: a continuation az üzenetben utazik, így semmi nem függ attól, hogy ugyanaz-e a folyamat.

A C folyamat a hiba. Az esemény létrejött, és nincs ott — mert a toy szerver a EVENTS értéket modul-szintű tömbben tartja, a modul-szintű tömb pedig kapcsolati állapot. A specifikáció megjegyzése pontosan megnevezi a hibát:

egy nyitott kapcsolat, például egy STDIO folyamat, nem beszélgetés vagy session: a kliensek egymástól független requesteket keverhetnek ugyanazon a transporton, és a szerver nem kezelheti a kapcsolat- vagy folyamatidentitást a beszélgetés vagy session folytonosságának helyettesítőjeként.²

Az előírt javítás nem session. Hanem explicit handle: egy létrehozó tool átlátszatlan azonosítót ad vissza, és minden későbbi hívás egyszerű argumentumként veszi át. A protokollnak erről egyáltalán nincs fogalma — „a wire nézőpontjából a handle egy közönséges string egy tool resultban és egy közönséges argumentum a későbbi toolhívásokban”.⁹ Ez a modelre bízza, hogy vigye magával, és a szerverre bízza, hogy minden egyes hívásnál ellenőrizze: ez a hívó használhatja-e, mert a handle név, nem jogosultság.

Minden tool, amelyet egy szerver kitesz, egy séma, amely minden requestnél bekerül a promptodba, és a 24. fejezet megmérte, mit tesz ez egy window-val. Az MCP hozzáad egy második költségsort, amelyet könnyű nem észrevenni, ezért mindkettőt érdemes megszámolni a fenti referencia-szerveren.

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

Két megfigyelés. Az első aritmetika: csatlakoztass öt ekkora szervert, és nagyjából nyolcezer token a window-ból minden körben le van kötve, örökre, akár használja a model bármelyiket, akár nem — ez a mechanizmus a 150.000-ről 2.000-re csökkentés mögött, amelyet a 24. fejezet idézett, és ezért létezik just-in-time tool discovery.

A második egy biztonsági megjegyzés könyvelési jelmezben. A instructions természetes nyelvű szöveg, amelyet a szerver szerzője írt, és amely a host promptjába kerül, és a mellette lévő toolleírások ugyanilyenek. A specifikáció a saját biztonsági elveiben mondja meg, mit kell ezzel tenni: a tool annotációit és leírásait „nem megbízhatónak kell tekinteni, hacsak nem megbízható szervertől származnak”, és a hostoknak „explicit felhasználói beleegyezést kell szerezniük bármely tool meghívása előtt”.¹ Egy MCP szerver csatlakoztatása nem dependency hozzáadása. Azt jelenti, hogy egy idegennek adsz 1.619 tokent a system promptodból és jogot arra, hogy meghívják. A 30. fejezet arról szól, mi történik, amikor ez az idegen ellenséges.

Ebben a szakaszban minden a 2026-07-28 protokollrevízióra igaz, amely a jelenlegi, 2026. szeptember 7-én olvasva. A revíziók dátumozása YYYY-MM-DD, és a dátum azt jelöli, mikor történt utoljára visszafelé inkompatibilis változás.¹⁰ A normatív dokumentum egy TypeScript-fájl, schema/2026-07-28/schema.ts; a mellette lévő JSON Schema ebből generálódik, ezért a specifikációt itt TypeScriptben olvassuk, és ezért fordításból tanítja az MCP-t bármi más.

A táblázat alatti governance-változás fontosabb bármelyik sornál. Ez a revízió bevezetett egy feature lifecycle és deprecation policy rendszert: a feature-ök Active, Deprecated vagy Removed állapotúak; a deprecated feature dokumentálja a migrációs útját, és legalább tizenkét hónapig a specifikációban marad, mielőtt eltávolíthatóvá válik; és van egy registry, amely felsorolja az összes jelenleg Deprecated állapotú dolgot.⁸ E politika előtt a „deprecated” egy AI-protokollban azt jelentette, amit a legutóbbi blogposzt mondott. Most dátumot jelent.

Ez az egész blokk szókészlete egy helyen.

Ezek közül kettő megér egy-egy mondatot, mert ott lakik a tényleges zavar.

MCP kontra A2A nem rivalizálás, és mindkét specifikáció ezt mondja. Az A2A dokumentációja az alapján húzza meg a vonalat, mi van a másik végén: az MCP „azt definiálja, hogyan lép interakcióba egy AI agent egyedi toolokkal és erőforrásokkal, például adatbázissal vagy API-val, és hogyan használja őket”, ahol egy tool „konkrét, gyakran állapotmentes függvényeket” hajt végre; az A2A agenteket céloz, „autonómabb rendszereket”, amelyek „gondolkodnak, terveznek, több toolt használnak, hosszabb interakciókon át állapotot tartanak fenn, és összetett, gyakran többkörös párbeszédekben vesznek részt”. A saját összefoglalója az a mondat, amelyet érdemes megjegyezni: „Az A2A arról szól, hogy agentek partnerségben dolgoznak feladatokon, míg az MCP inkább arról, hogy agentek capabilityket használnak.”¹¹ A kettő egymásba ágyazódik — egy alkalmazás A2A-val ér el más agenteket, és minden agent MCP-vel éri el a saját tooljait. A 25. fejezet ezt a vonalat egy folyamaton belül húzta meg, aközött, hogy megkérdezel egy sub-agentet vagy átadod neki a beszélgetést; az A2A szervezetek között húzza meg.

MCP kontra ACP egy elavult premisszájú összehasonlítás, pontosan ezért érdemes megválaszolni. Az Agent Communication Protocol külön nyílt szabvány volt agentek közötti üzenetküldésre. A saját dokumentációja ma ezzel a közleménnyel nyit: „Az ACP mostantól az A2A része a Linux Foundation alatt!”¹² A becsületes válasz arra, hogy „MCP vagy ACP?” 2026 szeptemberében az, hogy a kérdésnek eggyel kevesebb opciója van, mint amit a rá rangsoroló oldalak sugallnak.

És az összehasonlítás, amelyet a legtöbben kérnek, mcp vs api, a legkevésbé érdekes választ kapja: az MCP egy API. Amit hozzáad, nem erő, hanem konvenciók — fix metódusnevek, discovery call, irányítási hierarchia a primitívek felett, és izolációs modell. Feladod a szabadságot, hogy saját interfészt tervezz, és megkapod az összes hostot, amely beszéli a protokollt; ez az alku, amelyet minden protokoll valaha felajánlott.

Most már fordító nélkül el tudod olvasni a specifikációt, meg tudod különböztetni az erőforrást, a toolt és a promptot az alapján, ki irányítja, kézzel is be tudsz gépelni egy requestet, amikor egy klienskönyvtár hazudik neked, és bármely olvasott MCP-cikket dátumozni tudsz abból, melyik deprecated feature-t tanítja még aktuálisként.

Amit még nem tettél meg: nem szállítottál egyet. A 27. fejezet ugyanazt a szervert kétszer írja meg — TypeScriptben és Pythonban, egymás mellett, mert az MCP az egyetlen valóban kétnyelvű terület ebben a kurzusban, és a számok mindkét irányban ezt mondják. Rendesen lefedi a két élő transportot, az inspectort, a packaginget, és a protokollnak azt a felét, amelyet ez a fejezet szándékosan félretett: authorization. Mert abban a pillanatban, hogy a szervered távoli, nem pedig egy alfolyamat a saját laptopodon, egy idegen kliense tokennel fog érkezni, és a specifikáció szokatlanul szigorúan szabályozza, mit tehetsz vele.

Ez felveti a következő fejezet nem túl barátságos kérdését: ha egy token megérkezik a szerveredre, és valaki más audience-ének adták ki, pontosan mi akadályoz meg abban, hogy továbbküldd?

Ebben a fejezetben minden idézetet, metódusnevet, hibakódot és szabályt a Model Context Protocol specifikáció 2026-07-28 revíziójából olvastam, 2026. szeptember 7-én. Minden trace lokálisan készült Node 22-n: a toy naptárszerver 101 sor függőség nélkül, a referencia-szerver pedig az alább megnevezett publikált npm package. A fejezet írásához nem hívtam fizetős API-t — itt semmihez nem kell model, és részben éppen ez a lényeg.

A mérések: @modelcontextprotocol/server-everything@2026.8.31, publikálva 2026. augusztus 31-én, @modelcontextprotocol/sdk@1.30.0 alapján, publikálva 2026. július 27-én — egy nappal az ebben a fejezetben leírt revízió előtt. A server/discover kérdésre -32601 választ ad, 2025-11-25 értékre negotiál, amikor 2026-07-28 értéket kérnek tőle, és tools/list értéket szolgál ki handshake nélkül. A katalógusa 13 tool 7.663 byte-ban; a token számok o200k_base a tiktoken segítségével, minden definíció name, description és inputSchema mezőjén, ami az, amit egy provider a promptodba renderel, nem az, amennyit a JSON-RPC frame nyom.

Anthropic, Code execution with MCP: building more efficient agents, 2025. november 4., a forrása a 150.000-ről 2.000-re számnak, amelyet a 24. fejezet idézett és használt, itt pedig csak hivatkozunk rá.