MCP

Ce qui franchit la frontière MCP

Un client tiers voit des schémas d’outils et des résumés de mission. Il ne voit jamais l’adresse du serveur, vos clés, ni votre salle de données, et tout ce qu’il déclenche tourne sur votre machine.

DISPONIBLEÉcrit et couvert par des tests, pas encore observé en exécution réelleDeskworth · publié · mis à jour · 5 sources · Deskworth OS 0.0.48

Livré dans la construction courante. Vous pouvez le faire sur votre machine aujourd’hui.

Brancher un client sur Deskworth ajoute une partie à la conversation, et la question utile n’est pas « est-ce sûr » mais « que voit cette partie ». Ci-dessous, maillon par maillon.

#Tout tourne sur votre machine

  • Le client lance le serveur comme sous-processus, sur votre machine. C’est cela, le transport stdio : aucun port, aucun écouteur réseau, aucune adresse à atteindre depuis l’extérieur 3.
  • Le serveur passe la demande à l’application en cours par une socket Unix locale, un fichier sur votre disque, pas un point d’accès réseau.
  • L’application fait tourner les mandats, pilote les CLIs d’éditeurs où vous vous êtes connecté, et écrit dans votre salle de données. Rien de tout cela ne change parce que la demande vient d’un client plutôt que de la fenêtre.
  • Le serveur n’écrit que des messages de protocole sur la sortie standard et garde ses journaux sur la sortie d’erreur, comme le transport l’exige. Une ligne égarée sur le mauvais flux casse une session ; un test le tient.

#Ce qui atteint le modèle, et ce qui ne l’atteint jamais

ChoseAtteint le modèle ?Pourquoi
Noms d’outils, descriptions et schémas d’entréeOuiVoilà comment un modèle sait ce qu’il peut appeler. Ils sont écrits pour être lus par un modèle.
Résumés de mission, tailles, empreintes, listes de sourcesOuiIls sont la réponse à un appel que le modèle a fait.
L’adresse du serveur MCP interneNonUn test exige qu’aucun schéma ne la porte. Un client n’a rien à faire sur le serveur des cartes.
Clés d’éditeurs et jetons de connecteursNonIls vivent dans le trousseau macOS et ne sont jamais composés dans une consigne.
Les octets d’un fichier produitNonUn artefact rend un résumé et une adresse de ressource. Le client lit le fichier s’il le veut.
Votre journal, vos dépôts, vos thèsesNonIls sont atteignables par les mandats qui tiennent la capacité, à l’intérieur de l’application, pas par la surface externe.

#Les rôles et les capacités décident toujours

Une demande arrivée par MCP ne contourne rien. La mission est aiguillée vers des mandats, et chaque mandat n’atteint que ce que ses capacités déclarées couvrent, la même table qui empêche l’application de s’ouvrir si un rôle cumule un jour la lecture de vos données et un accès vers l’extérieur. Un client peut demander ; il ne peut pas élargir.

La provenance se comporte pareil. Un outil qui signale une source l’écrit au journal avec son adresse, sa période, sa métrique et sa date de lecture, et tout secret embarqué dans cette adresse est caviardé en entrant.

#Un MCP local et un connecteur distant ne sont pas la même chose

  • VÉRIFIÉ CLIENTServeur local, lancé par votre clientProuvé le 2026-09-10 avec Claude Code 2.1.265. Le processus tourne sous votre identité, sur votre machine, et atteint l’application par une socket locale.
  • PRÉVUUn connecteur distant pointé sur votre machineImpossible par construction plutôt que non implémenté : la connexion d’un connecteur sur mesure part des serveurs de l’éditeur, pas de votre réseau, donc une adresse de bouclage n’est pas quelque chose qu’il puisse atteindre 5.
  • PRÉVUUn point d’accès Deskworth hébergéIl faudrait un point d’accès public implémentant le transport courant, un seul chemin POST, une validation d’origine à chaque requête 4, plus un parcours de connexion délégué. Rien de cela n’est écrit, et héberger un bureau renverserait la règle sur laquelle le produit est bâti.

#The path of a call

Five links, and every one of them is on your machine. Read it as a list: that is what it is, and a picture of it would say less.

  1. 01Your MCP clientOn your machineLaunches the Deskworth binary as a subprocess and speaks JSON-RPC on its standard input and output. No port, no listener, nothing reachable from outside.
  2. 02The stdio serverA subprocess, running as youNegotiates the protocol revision, answers discovery, and forwards a call. Protocol messages on standard output, logs on standard error.
  3. 03A local Unix socketA file on your diskCarries the request to the running application. Not a network endpoint, nothing off the machine can address it.
  4. 04The Deskworth applicationWhere the desk livesRoutes the request to mandates, each reaching only what its declared capabilities cover. The provider CLIs it drives are the ones you signed into.
  5. 05The answerBack the same waySummaries, sizes, digests and resource addresses. Never the bytes of a file, never a key, never the address of the internal tool server.

#Sources

  1. Deskworth OS, product state at 0.0.24, providers and MCPDeskworthinternal handover report · Deskworth OS 0.0.24 · commit produit fb53f44 · lu à d01b336 · publié 2026-09-10 · lu 2026-09-10Document interne, non publié
  2. The external MCP surface, mirrored on this siteDeskworthinternal registry · mirror of mcp::externe, tools, prompts, resource templates, spoken revisions · lu 2026-09-10Document interne, non publié
  3. Model Context Protocol, stdio transportModel Context Protocol projectofficial documentation · revision 2026-07-28 · publié 2026-07-28 · lu 2026-09-10https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio
  4. Model Context Protocol, Streamable HTTP transportModel Context Protocol projectofficial documentation · revision 2026-07-28 · publié 2026-07-28 · lu 2026-09-10https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
  5. Get started with custom connectors using remote MCPAnthropicofficial documentation · lu 2026-09-10https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp