MCP expliqué à partir de la spec : ce qu’est vraiment un serveur

Avant le câble, l’arithmétique. Vous avez $N$ applications d’AI et $M$ choses qu’elles devraient pouvoir atteindre : un calendrier, un outil de tickets, une base de données d’entrepôt, un outil de design. Sans contrat commun, quelqu’un écrit $N \times M$ intégrations, et chacune d’elles est un schéma plus un endpoint plus une histoire d’authentification plus une charge de maintenance. Avec un contrat, le fournisseur de l’outil écrit un serveur, le fournisseur de l’application écrit un client, et le total est $N + M$.

Ce n’est pas une observation nouvelle, et la spécification dit de qui vient l’idée :

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

Prenez cette comparaison au pied de la lettre, plutôt que comme un compliment. Avant ce protocole, prendre en charge un langage dans un éditeur voulait dire un plugin par éditeur ; après, une équipe langage livrait un serveur et chaque éditeur en bénéficiait. La mesure du succès n’était pas l’élégance, mais le fait que le nombre d’intégrations cesse de se multiplier. Il en va de même ici : la valeur est dans le nombre d’implémentations, pas dans le design. Un protocole que deux produits parlent est un format de données avec de la cérémonie en plus.

Les messages MCP sont du JSON-RPC 2.0. Une requête est un objet avec jsonrpc, un id, une method et des params optionnels ; une réponse transporte le même id et soit result, soit error ; une notification est une requête sans id et ne reçoit aucune réponse. La spécification ajoute trois contraintes par-dessus : le id doit être une chaîne ou un nombre et ne doit pas être null, il ne doit pas entrer en collision avec une autre requête encore en vol, et chaque résultat doit transporter un champ resultType.²

Sur le transport stdio — celui que la commande ci-dessus a utilisé — la règle de cadrage est une ligne par 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.³

Cette dernière clause est la manière la plus courante dont un serveur maison casse, et il casse silencieusement : un console.log perdu, une barre de progression, un avertissement de dépréciation venu d’une dépendance, et le parseur ligne par ligne du client tombe sur quelque chose qui n’est pas du JSON. L’échappatoire est dans la même section : le serveur peut écrire ce qu’il veut dans stderr, et le client ne devrait pas traiter cela comme une erreur. Le serveur de référence ci-dessus imprime Starting default (STDIO) server... à chaque lancement, sur stderr, ce qui explique pourquoi le pipe a quand même fonctionné.

L’autre transport standard est Streamable HTTP : chaque message est un POST vers un endpoint unique, et la réponse est soit un objet JSON, soit un flux de Server-Sent Events limité à la requête — le format de fil que le chapitre 14 a parsé à la main. La sémantique est identique sur les deux, parce qu’un transport est un binding : il définit le cadrage et la livraison, pas le sens.⁴

La commande ci-dessus a envoyé tools/list et rien d’autre. Dans la révision actuelle, cette requête est malformée, et un serveur conforme doit la rejeter.

Depuis le 2026-07-28, MCP est un protocole sans état, et la spécification l’énonce sans réserve :

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

Chaque requête transporte donc sa propre version de protocole et ses propres capacités client, dans un objet réservé _meta à l’intérieur de params. Deux de ces champs sont requis sur chaque requête ; une requête à laquelle manque l’un ou l’autre est malformée et le serveur doit répondre -32602 :²

Écrit en entier, un tools/list correct ressemble à ceci — et c’est la dernière fois que ce chapitre montre les métadonnées en entier, parce qu’elles sont sur chaque requête à partir d’ici :

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

L’objet de capacités est la négociation. Il n’y a plus d’étape de négociation séparée : le client déclare ce qu’il peut faire sur chaque requête, le serveur déclare ce qu’il peut faire dans le résultat, et aucune des deux parties ne peut utiliser une fonctionnalité que l’autre n’a pas revendiquée. Un serveur qui a besoin d’une capacité que le client n’a pas déclarée doit répondre -32021 et nommer la capacité manquante dans data.requiredCapabilities. Un serveur qui ne parle pas la version demandée doit répondre -32022 et lister les versions qu’il parle.²

Les clients qui veulent la réponse d’emblée peuvent la demander : server/discover est un RPC obligatoire qui renvoie les versions prises en charge, les capacités, l’identité et un bloc optionnel de instructions en un aller-retour.⁵ L’appeler est optionnel. L’implémenter ne l’est pas.

La commande a fonctionné. Dans la révision actuelle, elle n’aurait pas dû, et la raison mérite une mesure plutôt qu’un paragraphe, parce qu’elle résume l’état de tout l’écosystème en une ligne.

Sondez le serveur de référence comme la spécification dit à un client moderne de le faire :

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

C’est la troisième branche de la règle de compatibilité : un DiscoverResult veut dire moderne, une erreur moderne reconnue veut dire moderne-mais-mauvaise-version, et tout le reste — y compris -32601 — veut dire legacy, revenez au handshake initialize.³ Faites-le donc, en demandant la révision actuelle :

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

Le client a demandé 2026-07-28 et le serveur a répondu 2025-11-25. Le 7 septembre 2026, le serveur de référence officiel — package npm @modelcontextprotocol/server-everything, version 2026.8.31, publié le 31 août 2026 — n’implémente pas la révision actuelle. Pas plus, à ces dates, que le SDK TypeScript sur lequel il est construit : la release 1.30.0 est sortie le 27 juillet 2026, la veille de la révision.

Lisez la conséquence plutôt que le ragot. Presque tout ce qui est écrit sur MCP décrit un protocole avec un handshake initialize, une session, une requête roots/list que le serveur envoie au client, et un transport HTTP+SSE. Les quatre ont disparu ou sont en train de disparaître. Quand vous lisez quoi que ce soit sur MCP, y compris cette page, la première chose à chercher est un numéro de révision.

Et la raison pour laquelle la toute première commande a fonctionné est décrite dans la spécification comme un danger, pas comme une fonctionnalité :

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

Mesure : envoyer tools/list à ce serveur sans aucun handshake renvoie tout le catalogue. Une méthode qui aurait dû être refusée a été servie, ce qui est exactement la raison pour laquelle la spécification dit de sonder avec server/discover d’abord, même si vous ne prenez en charge que les versions modernes.

MCP a trois parties, et la distinction entre les deux premières est celle que les gens fusionnent :

Server. Un processus ou un service qui expose des ressources, des outils et des prompts. Il peut être local ou distant, il fonctionne indépendamment, et tout son rôle est un domaine ciblé.⁶

Cette règle « exactement un serveur » n’est pas de la comptabilité. C’est ce qui rend le principe de design ci-dessous implémentable, et voici la phrase à retenir de la spécification si vous n’en gardez qu’une :

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

Cela renverse le modèle mental avec lequel la plupart des gens arrivent. Un serveur météo que vous connectez à votre assistant ne voit pas ce que vous avez demandé. Il voit un tools/call avec les arguments que le modèle a choisis, et rien d’autre : pas les tours précédents, pas votre system prompt, pas les résultats que le serveur calendrier a renvoyés un instant plus tôt. Si deux serveurs doivent coopérer, le host transporte délibérément une valeur de l’un vers l’autre, parce que le modèle l’a demandé. C’est pourquoi l’isolation est la propriété de sécurité sur laquelle s’appuie le chapitre 30 : un serveur compromis a un rayon d’explosion petit et défini, et l’agrandir exige que le host coopère.

La première commande a demandé des outils à ce serveur et en a reçu treize. Posez-lui les deux autres questions et il y répond aussi : resources/list en renvoie sept, prompts/list en renvoie quatre. Aucun n’est apparu, parce que rien ne l’a demandé. Ce qui nous amène à l’ossature pédagogique de MCP, présente dans la spécification sous forme de tableau que presque personne ne cite :

Pas « trois façons d’exposer une capacité ». Trois réponses à qui décide que cela se produit. Le modèle décide d’appeler un outil. L’application décide d’attacher une ressource. La personne décide d’exécuter un prompt. Si vous vous trompez, la fonctionnalité fonctionne quand même, mais elle fonctionne au mauvais moment et pour la mauvaise raison.

La façon la plus claire de le sentir est un calendrier. Voici un serveur qui expose le même calendrier trois fois, une fois comme chaque primitive, en cent lignes de Node pur sans dépendances :

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

Lancez-le et interrogez-le des trois façons. Sortie réelle, un message par ligne sur le fil, repliée ici pour la page, avec le _meta de la requête et le bloc d’identité du serveur omis :

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

Trois méthodes, trois formes, un calendrier. Maintenant, le point :

Presque tout le monde transforme ces trois choses en outils. Le résultat est un catalogue où une lecture que l’application aurait dû attacher silencieusement concurrence l’attention du modèle avec une écriture qui nécessite une approbation, et où la seule chose pour laquelle une personne voulait un bouton est enterrée dans un schéma. Bien le faire ne coûte rien, et cela se décide avant d’écrire une ligne.

L’outil calendrier a un argument requis, title, et un argument optionnel, startsAt. Demandez-lui de créer un événement sans date, et quelque chose d’intéressant revient :

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

Le serveur n’a pas envoyé de requête. Il a répondu à celle qu’on lui a donnée, avec resultType: "input_required" et une description de ce dont il a encore besoin. Le client recueille la réponse auprès de la personne, puis renvoie l’appel original — avec un nouveau id, transportant inputResponses et renvoyant tel quel le requestState opaque :

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

C’est Multi Round-Trip Requests, introduit dans la révision actuelle, et cela a remplacé l’ancien design où les serveurs envoyaient des requêtes JSON-RPC aux clients. La spécification de transport énonce désormais la règle sans détour : « servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses ».⁴ Il n’y a qu’une direction d’initiative, et elle appartient au host.

Deux fonctionnalités côté client reposent sur ce mécanisme, et l’une d’elles porte un nom qui va vous piéger.

Elicitation est le serveur qui demande quelque chose à la personne : un formulaire avec un JSON Schema délibérément restreint — objets plats, propriétés primitives, pas d’imbrication — afin que n’importe quel client puisse le rendre sans moteur de mise en page. Elle porte une règle stricte : les serveurs ne doivent pas utiliser le mode formulaire pour demander des « passwords, API keys, access tokens, or payment credentials », et doivent utiliser le mode URL pour cela, qui envoie l’utilisateur vers une page que le client ne lit jamais.⁷

Sampling est le serveur qui demande une génération au modèle du host, afin qu’un serveur puisse être intelligent sans détenir d’API key. Et voici l’avertissement de vocabulaire, parce que ce mot signifie déjà autre chose dans ce cours : ce n’est pas le sampling du chapitre 17. Rien ici ne concerne la température, top-p ou la forme d’une distribution de probabilité. C’est un appel de modèle imbriqué qui remonte à travers un protocole.

Il y a une deuxième raison de ne pas s’y précipiter : dans cette révision, sampling est deprecated, aux côtés de roots et logging, dans SEP-2577, avec une migration suggérée sans détour : « integrate directly with LLM provider APIs instead of Sampling ».⁸ L’idée n’a pas échoué techniquement ; elle n’a pas justifié sa surface, et un protocole capable de retirer des choses est plus sain qu’un protocole qui ne le peut pas.

L’absence d’état ressemble à un détail de format de fil jusqu’à ce que vous la testiez. Prenez l’échange en trois messages ci-dessus et exécutez chaque message dans un processus séparé : un node calendar.mjs frais, aucune mémoire partagée, rien de transporté :

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)

Le processus B, qui n’a jamais vu la question, a terminé un appel multi-round-trip commencé par le processus A. C’est tout l’intérêt de requestState : la continuation voyage dans le message, donc rien ne dépend du fait que le processus soit le même.

Le processus C est l’échec. L’événement a été créé et il n’est pas là, parce que le serveur jouet garde EVENTS dans un tableau au niveau du module, et un tableau au niveau du module est de l’état de connexion. La note de la spécification nomme précisément l’erreur :

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

La correction prescrite n’est pas une session. C’est un handle explicite : un outil de création renvoie un identifiant opaque, et chaque appel ultérieur le prend comme argument ordinaire. Le protocole n’en a aucun concept : « from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls ».⁹ Ce qui met le modèle aux commandes pour le transporter, et le serveur aux commandes pour vérifier que cet appelant a le droit de l’utiliser à chaque appel, parce qu’un handle est un nom et non une permission.

Chaque outil qu’un serveur expose est un schéma qui entre dans votre prompt à chaque requête, et le chapitre 24 a mesuré ce que cela fait à une fenêtre. MCP ajoute un deuxième poste de coût facile à manquer, donc il vaut la peine de compter les deux sur le serveur de référence ci-dessus.

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

Deux observations. La première est arithmétique : connectez cinq serveurs de cette taille et environ huit mille tokens de votre fenêtre sont réservés à chaque tour, pour toujours, que le modèle les utilise ou non — c’est le mécanisme derrière la réduction de 150 000 à 2 000 citée au chapitre 24, et la raison d’être de la découverte d’outils just-in-time.

La deuxième est une note de sécurité déguisée en comptabilité. instructions est du texte en langage naturel, écrit par l’auteur du serveur, qui atterrit dans le prompt du host, et les descriptions d’outils à côté de lui sont identiques. La spécification dit quoi faire à ce sujet dans ses propres principes de sécurité : les annotations et descriptions d’outils « should be considered untrusted, unless obtained from a trusted server », et les hosts « must obtain explicit user consent before invoking any tool ».¹ Connecter un serveur MCP n’est pas ajouter une dépendance. C’est accorder à un inconnu 1 619 tokens de votre system prompt et le droit d’être appelé. Le chapitre 30 raconte ce qui arrive quand cet inconnu est hostile.

Tout dans cette section est vrai pour la révision de protocole 2026-07-28, la révision actuelle, lue le 7 septembre 2026. Les révisions sont datées YYYY-MM-DD et la date est la dernière fois qu’un changement rétro-incompatible a été effectué.¹⁰ Le document normatif est un fichier TypeScript, schema/2026-07-28/schema.ts ; le JSON Schema à côté est généré depuis lui, ce qui explique pourquoi la spécification est lue ici en TypeScript et pourquoi enseigner MCP depuis autre chose revient à enseigner une traduction.

Le changement de gouvernance sous ce tableau compte plus que n’importe quelle ligne. Cette révision a adopté une politique de cycle de vie et de dépréciation des fonctionnalités : les fonctionnalités sont Active, Deprecated ou Removed, une fonctionnalité deprecated documente son chemin de migration et reste dans la spécification au moins douze mois avant de devenir éligible à la suppression, et un registre liste tout ce qui est actuellement en état Deprecated.⁸ Avant cette politique, « deprecated » dans un protocole d’AI voulait dire ce que disait le dernier billet de blog. Maintenant, cela veut dire une date.

Voici le vocabulaire de tout ce bloc en un seul endroit.

Deux d’entre eux méritent une phrase chacun, parce que c’est là que vit réellement la confusion.

MCP face à A2A n’est pas une rivalité, et les deux spécifications le disent. La documentation A2A trace la ligne selon ce qui se trouve à l’autre bout : MCP « defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API », où un outil exécute des « specific, often stateless, functions » ; A2A s’adresse aux agents, des « more autonomous systems » qui « reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues ». Son propre résumé est la phrase à retenir : « A2A is about agents partnering on tasks, while MCP is more about agents using capabilities. »¹¹ Les deux s’emboîtent : une application utilise A2A pour atteindre d’autres agents, et chaque agent utilise MCP pour atteindre ses propres outils. Le chapitre 25 traçait cette ligne dans un seul processus, entre demander à un sub-agent et lui remettre la conversation ; A2A la trace entre organisations.

MCP face à ACP est une comparaison avec une prémisse périmée, et c’est exactement pourquoi elle mérite une réponse. L’Agent Communication Protocol était un standard ouvert séparé pour la messagerie agent-à-agent. Sa propre documentation s’ouvre désormais sur l’avis : « ACP is now part of A2A under the Linux Foundation! »¹² La réponse honnête à « MCP ou ACP ? » en septembre 2026 est que la question a une option de moins que ne le suggèrent les pages qui se classent dessus.

Et la comparaison que les gens demandent le plus, mcp vs api, a la réponse la moins intéressante : MCP est une API. Ce qu’il ajoute n’est pas de la puissance, mais des conventions : un ensemble fixe de noms de méthodes, un appel de découverte, une hiérarchie de contrôle sur les primitives, et un modèle d’isolation. Vous renoncez à la liberté de concevoir votre propre interface et vous gagnez tous les hosts qui parlent le protocole, ce qui est le compromis que tout protocole a toujours proposé.

Vous pouvez désormais lire la spécification sans traducteur, distinguer une ressource d’un outil et d’un prompt selon qui en a le contrôle, taper une requête à la main quand une bibliothèque client vous ment, et dater n’importe quel article MCP que vous lisez selon les fonctionnalités deprecated qu’il enseigne encore comme actuelles.

Ce que vous n’avez pas fait, c’est en livrer un. Le chapitre 27 écrit le même serveur deux fois — TypeScript et Python, côte à côte, parce que MCP est le seul territoire vraiment bilingue de ce cours et que les chiffres le disent dans les deux sens. Il couvre correctement les deux transports live, l’inspector, le packaging et la moitié du protocole que ce chapitre a volontairement laissée de côté : l’autorisation. Parce qu’au moment où votre serveur est distant plutôt qu’un sous-processus sur votre propre laptop, le client d’un inconnu présentera un token, et la règle de la spécification sur ce que vous pouvez en faire est exceptionnellement stricte.

Ce qui soulève la question à laquelle le prochain chapitre doit répondre, et elle n’est pas sympathique : si un token arrive à votre serveur et qu’il a été émis pour l’audience de quelqu’un d’autre, qu’est-ce qui vous empêche exactement de le transmettre ?

Chaque citation, nom de méthode, code d’erreur et règle de ce chapitre a été lu dans la spécification Model Context Protocol, révision 2026-07-28, le 7 septembre 2026. Chaque trace a été produite localement sur Node 22 : le serveur calendrier jouet fait 101 lignes sans dépendances, et le serveur de référence est le package npm publié nommé ci-dessous. Aucune API payante n’a été appelée pour écrire ce chapitre — rien ici n’a besoin d’un modèle, ce qui est précisément le point.

Les mesures : @modelcontextprotocol/server-everything@2026.8.31, publié le 31 août 2026, construit sur @modelcontextprotocol/sdk@1.30.0, publié le 27 juillet 2026 — un jour avant la révision que ce chapitre décrit. Il répond à server/discover par -32601, négocie 2025-11-25 quand on lui demande 2026-07-28, et sert tools/list sans aucun handshake. Son catalogue contient 13 outils en 7 663 octets ; les comptes de tokens sont o200k_base via tiktoken, sur les name, description et inputSchema de chaque définition, ce qu’un fournisseur rend dans votre prompt et non ce que pèse la trame JSON-RPC.

Anthropic, Code execution with MCP: building more efficient agents, 4 novembre 2025, est la source du chiffre 150 000-vers-2 000, cité et utilisé au chapitre 24 et seulement référencé ici.