Vue d’ensemble

Un seul processus

mcpd fait deux choses avec un seul processus. Il conserve une exécution durable entre ses étapes : le curseur, les nouvelles tentatives, les timers et les attentes, pendant que votre code, dans n’importe quel langage, fait le travail à l’intérieur de chaque étape. Et il reçoit ce que votre agent a fait, le stocke, et vous le rend sous forme d’exécutions que vous pouvez lire. C’est un seul binaire, avec SQLite lié dedans. Il n’y a pas de base de données à monter, pas de collecteur à faire tourner à côté, et pas de compte nulle part.

Le daemon écoute sur le port 4317 et sert cinq choses depuis ce seul port :

• L’ingestion OTLP sur /v1/traces, /v1/logs et /v1/metrics, si bien qu’une installation OpenTelemetry existante n’a besoin d’aucun code nouveau.
• L’ingestion native sur /v1/ingest, qui porte les parties du modèle auxquelles OTLP ne fait pas de place, dont les scores et le feedback humain.
• L’API de lecture sous /v1/api, dont se servent aussi bien l’interface que les SDK. Il n’y a pas d’API privée derrière celle que vous obtenez.
• La surface d’exécution sous /v1/api/runs, /v1/api/events et /v1/api/steps : les définitions, les exécutions, les événements qui répondent à une attente, et le protocole que parle un worker. Voir Workflows.
• L’interface d’exploitation sur /, embarquée dans le binaire.

Un seul port est une décision de déploiement, pas un raccourci. Un collecteur, une base de données et une interface font trois choses à faire tourner, trois choses à mettre à jour, et trois endroits entre lesquels une trace peut se perdre.

Ce qu’il n’est pas, délibérément

L’essentiel de la valeur ici vient de ce que mcpd refuse de faire. Chaque refus retire une raison qui vous obligerait à changer votre agent.

• Pas un framework. mcpd n’exécute jamais votre modèle, ne le choisit pas et n’enveloppe pas le client de votre fournisseur. Il conserve une exécution entre les étapes et laisse à votre code tout ce qui se passe dans une étape. Votre code appelle un modèle de la même façon après avoir adopté mcpd qu’avant.
• Pas dans le chemin de la requête. Il ne se place jamais entre votre agent et un fournisseur. Rien de ce que voient vos utilisateurs ne dépend du fonctionnement de mcpd, parce que rien de ce qu’ils voient ne passe par lui.
• Pas un service. Le daemon n’appelle rien par défaut. Il n’y a pas de télémétrie, pas de contrôle de licence et pas d’endpoint d’éditeur. Le seul trafic sortant qu’il fera jamais est celui que vous configurez : un --forward-endpoint, le webhook d’un moniteur, ou un modèle juge. N’en réglez aucun et vos prompts ne quittent jamais la machine où vous l’avez lancé.
• Pas une dépendance obligatoire. Si vous supprimez mcpd de votre infrastructure, la seule chose qui s’arrête est l’enregistrement.

Les six signaux

mcpd stocke six sortes de choses, et les stocke ensemble. Les spans sont ce qui s’est exécuté. Les logs sont les lignes qu’une exécution a émises. Les métriques sont des nombres dans le temps. Les scores sont le jugement d’une machine sur une exécution. Le feedback est celui d’une personne. Une note d’aspect est une phrase qu’un modèle a écrite sur une exécution terminée.

Les garder dans un seul stockage est tout l’intérêt. Chaque signal porte l’identifiant de trace et l’identifiant de span auxquels il appartient : la question de savoir ce que le modèle a vraiment dit dans l’exécution dont ce client s’est plaint, et ce que cela a coûté, tient en une requête plutôt qu’en quatre outils et un horodatage à apparier à l’œil.

Les scores et le feedback sont tenus à part exprès. Le 0.8 d’un scorer et le pouce baissé d’une personne mesurent des choses différentes, et en faire la moyenne produit un nombre qui ne veut rien dire.

Pourquoi un daemon et pas un framework

L’observabilité d’un framework est bonne, et elle arrive attachée à ce framework. Pour être vu, un agent est censé avoir été bâti avec lui, en général dans un seul langage. C’est un marché honnête pour un projet neuf et un marché impossible pour un agent qui existe déjà et fonctionne déjà. Les workflows d’un framework sont le même marché : durables, tant que chaque étape est écrite dans le langage du framework et tourne dans son processus.

Un daemon renverse les deux. Le graphe d’un workflow est une donnée que le daemon détient ; les corps de ses étapes sont du code que votre processus détient, réclamés un bail à la fois par un protocole HTTP que n’importe quel langage sait parler. Le daemon ne voit jamais de modèle, de prompt ni de secret. Voir Workflows et Workers.

Un daemon renverse le marché. mcpd parle OTLP, qui est un protocole et non une dépendance : il enregistre donc des agents écrits dans n’importe quel langage, avec n’importe quel framework, y compris ceux écrits avant que mcpd existe. Si votre agent exporte déjà de l’OpenTelemetry, pointer OTEL_EXPORTER_OTLP_ENDPOINT vers mcpd est toute l’intégration.

Les SDK existent parce qu’OTLP n’a pas de vocabulaire pour un prompt, une complétion, un nombre de tokens ou un score, et ce sont précisément les champs pour lesquels vous êtes venu. En prendre un est un choix, pas une condition. Tous les six se comportent à l’identique : enregistrer un span ajoute à une file bornée et rend la main, le travail réseau se fait sur un worker d’arrière-plan, et rien sur le chemin d’instrumentation ne lève jamais d’exception. Une observabilité qui peut faire tomber le système qu’elle observe est pire que pas d’observabilité du tout.

Un seul binaire, deux déploiements

Le conteneur que vous lancez sur un portable est le conteneur qui tourne comme Deployment sur le cluster de quelqu’un. La conservation, le masquage, l’échantillonnage et les clés d’API sont des indicateurs de ce même binaire, pas une autre compilation et pas un palier de licence. Aucune fonction n’existe seulement dans une version que vous ne pouvez pas avoir.

Les valeurs par défaut sont réglées pour le portable, ce qui veut dire que l’ingestion et les lectures sont ouvertes tant qu’aucune clé n’est configurée. mcpd avertit haut et fort au démarrage quand il écoute dans cet état sur une adresse autre que la boucle locale. Il démarre quand même, parce que refuser casserait le chemin de cinq minutes pour la personne à qui il s’adresse, mais le silence serait irresponsable.

Où aller ensuite

• Le faire tourner tout de suite : Prise en main met à l’écran une trace de votre propre agent, ou Installation couvre toutes les voies d’entrée.
• Apprendre le vocabulaire : Concepts définit trace, span, type et corrélation, que le reste de la documentation suppose acquis.
• Conserver une exécution entre les étapes : Workflows, puis Workers et Exécutions.
• Vous avez déjà OpenTelemetry : le chemin OTLP en entier, y compris ce que mcpd déduit des attributs standard.
• Le faire tourner pour d’autres personnes : Docker et Kubernetes, puis Masquage et conservation.

mcpd est sous licence Apache-2.0. Le protocole d’entrée, le format de sortie et la licence autour sont tous ouverts : partir coûte aussi peu qu’arriver.