MCPを仕様に照らして解説：サーバーとは本当は何か

wireの前に、まず算術です。あなたには$N$個のAI applicationがあり、それらが到達できるべきものが$M$個あります。calendar、ticket tracker、warehouse database、design toolです。共通のcontractがなければ、誰かが$N \times M$個のintegrationを書き、その1つ1つがschema、endpoint、authenticationの話、maintenance burdenを抱えます。共通のcontractがあれば、tool vendorがserverを書き、application vendorがclientを書き、合計は$N + M$になります。

これは新しい観察ではありません。仕様は、それが誰の発想だったかを述べています。

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.¹

この比較は賛辞としてではなく、文字どおりに受け取ってください。そのprotocol以前、editorでlanguageをsupportするにはeditorごとにpluginが必要でした。その後は、language teamが1つのserverを出荷すれば、すべてのeditorがそれを得られるようになりました。成功の尺度は優雅さではなく、integration数が増殖しなくなったことでした。ここでも同じです。価値はdesignではなく、implementationの数にあります。 2つのproductしか話さないprotocolは、余分な儀式をまとったdata formatです。

MCP messageはJSON-RPC 2.0です。requestはjsonrpc、id、method、任意のparamsを持つobjectです。responseは同じidと、resultまたはerrorのどちらかを持ちます。notificationはidのないrequestで、replyはありません。仕様はその上に3つの制約を追加します。idはstringまたはnumberでなければならず、nullであってはなりません。まだ処理中の別requestと衝突してはならず、すべてのresultはresultType fieldを持たなければなりません。²

stdio transport、つまり上のcommandが使ったtransportでは、framing ruleはmessageごとに1行です。

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.³

この最後の節は、自作serverが壊れる最も一般的な理由であり、しかも静かに壊れます。余計なconsole.log、progress bar、dependencyからのdeprecation warningが1つあるだけで、clientのline parserはJSONではないものにぶつかります。escape hatchは同じsectionにあります。serverはstderrへ好きなものを書いてよく、clientはそれをerrorとして扱うべきではありません。上のreference serverは起動のたびにstderr上へStarting default (STDIO) server...を出力するので、pipeはそれでも動きました。

もう1つのstandard transportはStreamable HTTPです。各messageは単一endpointへのPOSTで、replyはJSON object、またはrequestにscopeされたServer-Sent Eventsのstreamです。これはChapter 14で手作業でparseしたwire formatです。semanticsはどちらでも同一です。なぜならtransportはbindingだからです。framingとdeliveryを定義するものであって、meaningを定義するものではありません。⁴

上のcommandはtools/listだけを送り、それ以外は何も送りませんでした。current revisionでは、このrequestはmalformedであり、準拠serverは拒否しなければなりません。

2026-07-28以降、MCPはstateless protocolであり、仕様は曖昧さなくそう述べています。

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として持ちます。これらのfieldのうち2つは、すべてのrequestで必須です。どちらかが欠けたrequestはmalformedであり、serverは-32602を返さなければなりません。²

正しいtools/listを書き下すとこうなります。この章で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します。そして、どちらの側も相手がclaimしていないfeatureを使ってはなりません。clientがdeclareしていないcapabilityをserverが必要とする場合、serverは-32021を返し、欠けているcapabilityをdata.requiredCapabilitiesで名指ししなければなりません。serverがrequested versionを話せない場合、-32022を返し、自分が話せるversionをlistしなければなりません。²

先に答えを知りたいclientは、それを尋ねられます。server/discoverはmandatory RPCであり、supported versions、capabilities、identity、そして任意のinstructions blockを1 round tripで返します。⁵ 呼び出しはoptionalです。実装はoptionalではありません。

commandは動きました。current revisionでは動くべきではありませんでした。なぜ動いたのかは、段落で済ませるより測定する価値があります。ecosystem全体の状態が1行に表れているからです。

modern clientに対して仕様が指示するとおりに、reference serverを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の3番目のbranchです。DiscoverResultならmodern、recognised modern errorならmodernだがversion違い、そして-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と答えました。2026年9月7日時点で、official reference server、npm package @modelcontextprotocol/server-everything、version 2026.8.31、2026年8月31日公開は、current revisionを実装していません。日付を見る限り、それが依存するTypeScript SDKも同じです。release 1.30.0は2026年7月27日、revisionの前日に出ています。

ゴシップではなく、結果を読み取ってください。MCPについて書かれているほとんどのものは、initialize handshake、session、serverがclientへ送るroots/list request、HTTP+SSE transportを持つprotocolを説明しています。この4つはすべて、すでに消えたか、消えつつあります。MCPについて何かを読むとき、このpageを含めて、最初に探すべきものはrevision numberです。

そして最初のcommandが動いた理由は、仕様では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.³

測定結果：handshakeなしでそのserverへtools/listを送ると、catalogue全体が返ります。本来拒否されるべきmethodがserveされました。だからこそ仕様は、modern versionだけをsupportする場合であっても、まずserver/discoverでprobeせよと言っているのです。

MCPには3つのpartyがあり、最初の2つの区別こそ、人々が潰してしまいがちなものです。

Server. resources、tools、promptsを公開するprocessまたはserviceです。localでもremoteでもよく、独立して動作し、その仕事は1つのfocused areaに限られます。⁶

この「exactly one server」ruleはbookkeepingではありません。下のdesign principleを実装可能にするものです。そして、仕様から一文だけ持ち帰るなら、この文です。

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をひっくり返します。assistantに接続したweather serverは、あなたが何を尋ねたかを見ません。それが見るのは、modelが選んだargumentsを伴うtools/callだけです。それ以外は何も見ません。前のturnも、system promptも、calendar serverがつい先ほど返したresultも見ません。2つのserverが協調する必要がある場合、hostが意図的に一方から他方へ値を運びます。modelがそれを求めたからです。だからこそisolationはChapter 30が依拠するsecurity propertyです。compromised serverのblast radiusは小さく定義されており、それを広げるにはhostの協力が必要です。

最初のcommandはそのserverにtoolsを求め、13個を得ました。残り2つの質問も投げれば、そのserverは答えます。resources/listは7個を返し、prompts/listは4個を返します。何も尋ねなかったので、それらは現れませんでした。ここでMCPの教育的な背骨に到達します。仕様内にありながら、ほとんど誰も引用しないtableです。

「capabilityを公開する3つの方法」ではありません。これが起きると誰が決めるのかへの3つの答えです。modelはtoolをcallすると決めます。applicationはresourceをattachすると決めます。人はpromptを実行すると決めます。ここを間違えてもfeatureは動きます。ただし、間違った瞬間に、間違った理由で動きます。

それを最もはっきり感じる方法はcalendarです。同じcalendarを3回、各primitiveとして1回ずつ公開するserverを示します。dependencyなし、plain Nodeで100行です。

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

実行して、3通りすべてで尋ねます。実際のoutputで、wire上では1行1messageですが、このpage用にwrapしています。requestの_metaとserverのidentity blockは省略しています。

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

3つのmethod、3つのshape、1つのcalendar。ここが要点です。

ほとんど全員が、これら3つをすべてtoolsにしてしまいます。その結果、本来applicationが静かにattachすべきreadが、approvalを必要とするwriteとmodelのattentionを奪い合うcatalogueになります。そして人がbuttonとして欲しかったものがschemaの中に埋もれます。正しくするのにcostはかかりません。そしてそれは、1行書く前に決まります。

calendar toolには必須argumentのtitleと、任意のstartsAtがあります。dateなしでevent作成を頼むと、興味深いものが返ってきます。

→ 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に、resultType: "input_required"と、まだ何が必要かのdescriptionを付けて答えたのです。clientは人からanswerを集め、それから元のcallを再送します。新しいidで、inputResponsesを運び、opaqueなrequestStateをそのまま返します。

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

これはcurrent revisionで導入されたMulti Round-Trip Requestsで、serverがclientへJSON-RPC requestsを送り返す古いdesignを置き換えました。transport specificationは今、そのruleを平然と述べています。「servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses」。⁴ initiativeの方向は1つであり、それはhostに属します。

2つのclient-side featureがそのmechanismに乗っています。そしてそのうち1つは、あなたをつまずかせる名前を持っています。

Elicitationは、serverが人に何かを求めることです。意図的に制限されたJSON Schema、つまりflat objects、primitive properties、no nestingのformで、layout engineなしでもどんなclientでもrenderできます。hard ruleがあります。serverはform modeを使って「passwords, API keys, access tokens, or payment credentials」を求めてはならず、それらにはURL modeを使わなければなりません。URL modeはuserを、clientが決して読まないpageへ送ります。⁷

Samplingは、serverがhostのmodelにgenerationを求めることです。これにより、serverはAPI keyを保持せずにintelligentになれます。そして語彙上の警告です。この単語はこのcourseではすでに別の意味を持っています。これはChapter 17のsamplingではありません。 ここではtemperature、top-p、probability distributionのshapeについては何も扱っていません。protocolを逆向きに進むnested model callです。

手を伸ばすべきではない理由がもう1つあります。このrevision時点で、samplingはdeprecatedです。rootsとloggingも同様に、SEP-2577の下でdeprecatedになっており、移行案は率直です。「Samplingの代わりにLLM provider APIsと直接統合する」。⁸ 発想がtechnicalに失敗したわけではありません。surface areaを正当化できなかったのです。そして、ものを削除できるprotocolは、削除できないprotocolより健全です。

Statelessnessは、testするまではwire-formatの細部に聞こえます。上の3 message exchangeを取り、各messageを別processで実行します。freshなnode calendar.mjs、shared memoryなし、何も引き継ぎません。

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を完了しました。これがrequestStateの要点です。continuationはmessage内を移動するので、同じprocessであることに何も依存しません。

Process Cはfailureです。eventは作成されたのに、そこにはありません。toy serverがEVENTSをmodule-level arrayに保持しており、module-level arrayはconnection stateだからです。仕様のnoteは、その誤りを正確に名指ししています。

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.²

規定された修正はsessionではありません。explicit handleです。creation toolはopaque identifierを返し、以後すべてのcallがそれを普通のargumentとして受け取ります。protocolはそれをまったく概念として持ちません。「wireから見れば、handleはtool result内のordinary stringであり、subsequent tool callsへのordinary argument」です。⁹ これにより、それを運ぶ責任はmodelに置かれ、serverには、すべてのcallでこのcallerがそれを使ってよいかをvalidateする責任が置かれます。handleはnameであってpermissionではないからです。

serverが公開する各toolは、すべてのrequestであなたのpromptへ入るschemaです。そしてChapter 24は、それがwindowに何をするかを測定しました。MCPは見落としやすい2つ目のline itemを追加するので、上のreference serverで両方を数える価値があります。

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

観察は2つです。1つ目は算術です。このsizeのserverを5つ接続すると、あなたのwindowの約8,000 tokensが、modelがそれらを使うかどうかに関係なく、毎turn、永久に確保されます。これがChapter 24で引用した150,000から2,000への削減の背後にあるmechanismであり、just-in-time tool discoveryが存在する理由です。

2つ目は、accounting costumeを着たsecurity noteです。instructionsはserver authorが書いたnatural-language textであり、hostのpromptに入ります。その横にあるtool descriptionsも同じです。仕様はsecurity principlesの中で、それにどう対処すべきかを述べています。tool annotationsとdescriptionsは「trusted serverから得たのでない限りuntrustedと見なすべき」であり、hostは「any toolをinvokeする前にexplicit user consentを得なければならない」。¹ MCP serverを接続することはdependencyを追加することではありません。見知らぬ相手に、あなたのsystem promptの1,619 tokensと、callされる権利を与えることです。Chapter 30は、その見知らぬ相手がhostileだった場合に起きることです。

このsectionのすべては、protocol revision 2026-07-28、つまり2026年9月7日に読んだcurrent revisionについて真です。revisionはYYYY-MM-DDでdate付けされ、そのdateはbackwards-incompatible changeが最後に行われた時点です。¹⁰ normative documentはTypeScript fileのschema/2026-07-28/schema.tsです。隣にあるJSON Schemaはそこから生成されます。だからこの仕様はTypeScriptとして読まれますし、それ以外のものからMCPを教えることはtranslationを教えることになります。

このtableの下にあるgovernance changeは、どの1行よりも重要です。このrevisionはfeature lifecycle and deprecation policyを採用しました。featuresはActive、Deprecated、Removedのいずれかで、deprecated featureはmigration pathをdocumentし、removalの対象になり得るまで少なくとも12か月は仕様に残ります。そして現在Deprecated stateにあるすべてをlistするregistryがあります。⁸ そのpolicy以前、AI protocolにおける「deprecated」は、最後のblog postが言ったことを意味していました。今はdateを意味します。

このblock全体の語彙を1か所にまとめます。

このうち2つは、それぞれ一文が必要です。実際の混乱はそこにあるからです。

MCP against A2Aはrivalryではありません。両方の仕様がそう述べています。A2A documentationは、向こう側に何があるかで線を引きます。MCPは「AI agentがdatabaseやAPIのようなindividual tools and resourcesとどうinteractし、utilizeするか」を定義し、toolは「specific, often stateless, functions」を実行します。一方、A2Aはagents、「more autonomous systems」を対象にします。それらは「reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues」します。覚えるべき要約は仕様自身の文です。「A2A is about agents partnering on tasks, while MCP is more about agents using capabilities。」¹¹ 2つは入れ子になります。applicationはA2Aを使って他のagentsに到達し、各agentはMCPを使って自分のtoolsに到達します。Chapter 25は、sub-agentに尋ねることとconversationを渡すことの間に、その線を1つのprocess内で引きました。A2Aはそれを組織間で引きます。

MCP against ACPは、古い前提に対する比較です。だからこそ答える価値があります。Agent Communication Protocolは、agent-to-agent messagingのための別個のopen standardでした。そのdocumentationは現在、「ACP is now part of A2A under the Linux Foundation!」というnoticeで始まります。¹² 2026年9月に「MCP or ACP?」と聞かれたときの正直な答えは、検索上位のpageが示すより選択肢が1つ少ない、というものです。

そして最もよく求められる比較、mcp vs apiには、いちばん面白みのない答えしかありません。MCP is an API. それが加えるのはpowerではなく、conventionsです。固定されたmethod nameの集合、discovery call、primitives上のcontrol hierarchy、isolation modelです。自分のinterfaceをdesignする自由を手放し、そのprotocolを話すすべてのhostを得ます。これは、すべてのprotocolがこれまで提示してきたtradeです。

これで、translatorなしに仕様を読めるようになりました。resource、tool、promptを誰が主導権を持つかで見分けられます。client libraryが嘘をついているときにrequestを手で入力できます。そして、読んでいるMCP記事が、deprecated featuresのどれをまだcurrentとして教えているかで日付を付けられます。

まだやっていないのは、1つshipすることです。Chapter 27では同じserverを2回書きます。TypeScriptとPythonを横並びで書きます。MCPはこのcourseで唯一、本当にbilingualな領域であり、数も両方向でそう示しているからです。2つのlive transports、inspector、packaging、そしてこの章が意図的に残したprotocolの半分、つまりauthorizationをきちんと扱います。なぜなら、あなたのserverが自分のlaptop上のsubprocessではなくremoteになった瞬間、見知らぬclientがtokenを提示し、そのtokenで何をしてよいかについての仕様のruleは異例に厳しいからです。

そこで次章が答えなければならない問いが立ち上がります。しかもそれはfriendlyな問いではありません。あなたのserverにtokenが到着し、それが誰か別のaudience向けに発行されたものだった場合、あなたがそれをforwardするのを正確に何が止めるのでしょうか？

この章のすべてのquotation、method name、error code、ruleは、Model Context Protocol specification、revision 2026-07-28を、2026年9月7日に読んだものです。すべてのtraceはNode 22上でlocalに生成しました。toy calendar serverはdependencyなしの101行で、reference serverは下に名を挙げるpublished npm packageです。この章を書くためにpaid APIは呼んでいません。ここにはmodelを必要とするものは何もありません。それ自体が要点です。

測定：@modelcontextprotocol/server-everything@2026.8.31、2026年8月31日公開。@modelcontextprotocol/sdk@1.30.0上に構築され、これは2026年7月27日公開、つまりこの章が説明するrevisionの1日前です。server/discoverに-32601で答え、2026-07-28を要求されると2025-11-25をnegotiateし、handshakeなしでtools/listをserveします。そのcatalogueは13 tools、7,663 bytesです。token countsは、各definitionのname、description、inputSchemaについて、tiktoken経由のo200k_baseです。これはproviderがあなたのpromptへrenderするものであり、JSON-RPC frameの重さではありません。

Anthropic, Code execution with MCP: building more efficient agents, 2025年11月4日が、150,000-to-2,000という数字の出典です。Chapter 24で引用・使用しており、ここでは参照するだけです。