Ce que j’ai compris en écrivant 50 outils MCP : les appels de fonction relevaient d’une relation anormalement intime

Article qui, à partir d’une expérience menée pendant deux jours de week-end à migrer un outil de gestion d’actifs vers une CLI basée sur SQLite et un serveur MCP, résume à quel endroit la conception d’outils MCP se sépare de façon décisive du RPC.
L’auteur a écrit une trentaine de commandes CLI et une cinquantaine d’outils MCP, et raconte qu’au vu du volume, ce qui lui a pris le plus de temps n’était pas le code mais la description des fonctions.

• Lorsqu’une même fonction a été exposée à la fois en CLI et en MCP, les deux interfaces se sont comportées différemment alors que la signature, les arguments et les valeurs de retour étaient identiques. La seule chose qui changeait, c’était que l’appelant était un humain ou un LLM
• La signature explique ce qu’une fonction reçoit, mais n’explique presque pas quand elle doit être appelée. Un nom de fonction ressemble à une ligne de dictionnaire : le mot seul ne dit pas dans quelle phrase il doit être utilisé
• Pour un appelant LLM, des outils plus lourds, directement alignés sur l’intention, sont plus naturels que des outils finement découpés selon le principe de responsabilité unique (SRP)
• MCP, vu de sa forme, appartient à la lignée RPC (JSON-RPC, signatures, schémas), mais la différence décisive est que le sens de la confiance s’inverse. En RPC, l’appelant fait confiance à la cible appelée ; en MCP, c’est le créateur de l’outil qui doit faire confiance à l’appelant (le LLM)
• La signature est une déclaration, la description est une demande. L’une contraint, l’autre persuade. Cela signifie qu’un langage de persuasion commence à entrer dans la conception des outils
• Ce n’est pas tant un changement inédit qu’une forme de régression vers un état antérieur. Le design industriel, l’architecture et l’UX sont depuis longtemps dans cette situation ; c’est simplement que la programmation est restée jusqu’ici à une extrémité exceptionnellement intime du spectre

Ce que la signature ne dit pas

• Dans Firma, add_txn (transaction), add_balance (instantané d’actifs) et add_flow (revenus/dépenses) avaient tous des signatures claires, avec des types d’arguments strictement définis par des schémas zod, mais le LLM hésitait souvent sur l’outil à appeler à partir de l’énoncé de l’utilisateur
• Au départ, l’auteur a soupçonné un problème du modèle LLM, mais le vrai problème venait de la signature elle-même. Le nom add_txn ne contient pas l’indication “si l’utilisateur a parlé d’un achat ou d’une vente, utilise cet outil”
• Ce n’est qu’après avoir formulé la description sous la forme "Use this when... Do NOT use this for...", en explicitant le moment de l’appel et la frontière avec les autres outils, que les appels se sont stabilisés
• L’intention de la fonction s’est déplacée de la signature vers la description de la fonction. De la même manière que la forme du manche d’un marteau suggère son usage, la description d’une fonction MCP correspond en pratique à l’affordance de l’outil pour le LLM (Donald Norman)

SRP vs affordance, et le sens de la confiance

• Au début, l’auteur voulait découper finement selon le principe de responsabilité unique, avec get_holdings, get_prices, get_pnl, etc. Mais quand l’utilisateur demande « Que vaut mon portefeuille ? », le LLM doit combiner quatre ou cinq appels, ce qui ralentit la réponse et augmente les risques de décalage
• Au final, il a conçu show_portfolio comme un outil lourd qui renvoie en une fois les positions détenues, le prix moyen d’achat, le prix actuel, la valorisation et le profit/perte cumulé. get_brief va encore plus loin et renvoie aussi les indicateurs macro et des insights en une seule fois
• Le SRP est une vertu pour celui qui construit la fonction ; l’affordance est une vertu pour celui qui utilise l’outil. Si l’appelant est humain, l’assemblage fonctionne ; si c’est un LLM, des outils qui touchent directement l’intention sont préférables
• C’est dans les outils d’écriture que le sens de la confiance apparaît le plus clairement. En écrivant dans add_txn "Always confirm with the user before recording", le LLM demandait une confirmation à chaque fois et l’utilisateur répondait à chaque fois « OK » — l’avantage de l’interface en langage naturel disparaissait
• Finalement, la responsabilité a été redistribuée sous la forme « enregistre immédiatement, ne pose des questions qu’en cas d’ambiguïté, et en cas d’erreur on peut annuler ». Ce type d’instruction n’est pas une description formelle de l’outil, mais un principe opérationnel donné à l’appelant

Il se pourrait que l’appel de fonction ait toujours été un cas particulier

• Les humains ont toujours utilisé des outils qu’ils n’avaient pas fabriqués eux-mêmes. Les bols faits par le potier, les couteaux forgés par le forgeron, jusqu’aux programmes créés par les développeurs : c’est toujours le même schéma
• L’appel de fonction était en réalité une relation assez particulière, dans laquelle l’appelant et l’auteur partagent beaucoup de contexte, tandis que le système de types, l’IDE et la documentation renforcent en permanence cette intimité
• Si l’appelant n’est plus un humain, deux options existent : (1) injecter davantage de contexte au LLM pour en faire un appelant plus intime ; (2) réduire la distance du côté de l’outil. MCP se rapproche plutôt de la seconde approche
• Il est possible que nous soyons dans une période où la manière même de concevoir les interfaces est en train de changer discrètement. Le centre de gravité se déplace de la signature vers la description, de la contrainte vers la persuasion, de l’hypothèse d’intimité vers la reconnaissance de la distance