Visión general

Un solo proceso

mcpd hace dos cosas con un solo proceso. Sostiene una ejecución duradera entre sus pasos: el cursor, los reintentos, los temporizadores y las esperas, mientras tu propio código, en cualquier lenguaje, hace el trabajo dentro de cada paso. Y recibe lo que hizo tu agente, lo guarda y te lo devuelve como ejecuciones que puedes leer. Es un solo binario con SQLite enlazado dentro. No hay base de datos que levantar, ni colector que ejecutar al lado, ni cuenta en ningún sitio.

El daemon escucha en el puerto 4317 y sirve cinco cosas desde ese único puerto:

• Ingesta OTLP en /v1/traces, /v1/logs y /v1/metrics, de modo que una instalación de OpenTelemetry que ya tengas no necesita código nuevo.
• Ingesta nativa en /v1/ingest, que transporta las partes del modelo para las que OTLP no tiene sitio, incluidas las puntuaciones y el feedback de personas.
• La API de lectura bajo /v1/api, que usan tanto la interfaz como los SDK. No hay ninguna API privada detrás de la que recibes.
• La superficie de ejecución bajo /v1/api/runs, /v1/api/events y /v1/api/steps: definiciones, ejecuciones, los eventos que responden a una espera y el protocolo que habla un worker. Consulta Workflows.
• La interfaz del operador en /, incrustada en el binario.

Un solo puerto es una decisión de despliegue, no un atajo. Un colector, una base de datos y una interfaz son tres cosas que ejecutar, tres cosas que actualizar y tres sitios entre los que se puede perder una traza.

Lo que a propósito no es

Buena parte del valor viene de lo que mcpd se niega a hacer. Cada negativa quita un motivo por el que tendrías que cambiar tu agente.

• No es un framework. mcpd nunca ejecuta tu modelo, ni lo elige, ni envuelve el cliente de tu proveedor. Sostiene una ejecución entre pasos y deja a tu código todo lo que ocurre dentro de un paso. Tu código llama a un modelo igual después de adoptar mcpd que antes.
• No está en la ruta de la solicitud. Nunca se coloca entre tu agente y un proveedor. Nada de lo que ven tus usuarios depende de que mcpd esté en marcha, porque nada de lo que ven pasa por él.
• No es un servicio. El daemon no llama a nada por defecto. No hay telemetría, ni comprobación de licencia, ni endpoint de un proveedor. El único tráfico saliente que hará nunca es el que tú configures: un --forward-endpoint, el webhook de un monitor o un modelo juez. No definas ninguno y tus prompts nunca salen de la máquina donde lo ejecutaste.
• No es una dependencia obligatoria. Si borras mcpd de tu infraestructura, lo único que se detiene es el registro.

Las seis señales

mcpd guarda seis tipos de cosa, y las guarda juntas. Los spans son lo que se ejecutó. Los logs son las líneas que emitió una ejecución. Las métricas son números a lo largo del tiempo. Las puntuaciones son el juicio de una máquina sobre una ejecución. El feedback es el de una persona. Una nota de aspecto es una frase que un modelo escribió sobre una ejecución terminada.

Tenerlas en un mismo almacén es justo la idea. Cada señal lleva el id de traza y el id de span a los que pertenece, así que la pregunta «qué dijo en realidad el modelo en la ejecución de la que se quejó este cliente, y cuánto costó» es una sola consulta y no cuatro herramientas y una marca de tiempo que cuadrar a ojo.

Las puntuaciones y el feedback se mantienen separados a propósito. El 0.8 de un evaluador y el pulgar hacia abajo de una persona miden cosas distintas, y promediarlos da un número que no significa nada.

Por qué un daemon y no un framework

La observabilidad de un framework es buena, y llega pegada a ese framework. Para ser visto, se espera que un agente esté construido con él, casi siempre en un solo lenguaje. Es un trato razonable para un proyecto nuevo e imposible para un agente que ya existe y ya funciona. Los workflows de un framework son el mismo trato: duraderos, siempre que cada paso esté escrito en el lenguaje del framework y se ejecute dentro de su proceso.

Un daemon invierte las dos cosas. El grafo de un workflow son datos que guarda el daemon; los cuerpos de sus pasos son código que guarda tu proceso, reclamado de lease en lease mediante un protocolo HTTP que cualquier lenguaje puede hablar. El daemon nunca ve un modelo, ni un prompt, ni una credencial. Consulta Workflows y Workers.

Un daemon invierte el trato. mcpd habla OTLP, que es un protocolo y no una dependencia, así que registra agentes escritos en cualquier lenguaje, con cualquier framework, incluidos los escritos antes de que mcpd existiera. Si tu agente ya exporta OpenTelemetry, apuntar OTEL_EXPORTER_OTLP_ENDPOINT a mcpd es toda la integración.

Los SDK existen porque OTLP no tiene vocabulario para un prompt, una completion, un recuento de tokens o una puntuación, y esos son los campos por los que viniste. Usar uno es una opción, no una condición. Los seis se comportan igual: registrar un span añade a una cola acotada y vuelve, el trabajo de red ocurre en un worker en segundo plano, y nada en la ruta de instrumentación lanza nunca una excepción. Una observabilidad capaz de tumbar el sistema que observa es peor que ninguna.

Un binario, dos despliegues

El contenedor que ejecutas en un portátil es el contenedor que corre como Deployment en el clúster de alguien. La retención, la ocultación, el muestreo y las claves de API son flags de ese mismo binario, no una build distinta ni un nivel de licencia. No hay ninguna función que exista solo en una versión que no puedes tener.

Los valores por defecto están puestos para el portátil, lo que significa que la ingesta y las lecturas están abiertas cuando no hay claves configuradas. mcpd avisa con claridad al arrancar cuando escucha en una dirección que no es de loopback en ese estado. Arranca igualmente, porque negarse rompería la vía de cinco minutos para la persona a la que va dirigido, pero callar sería irresponsable.

Adónde ir después

• Ejecutarlo ahora: Inicio rápido pone en pantalla una traza de tu propio agente, e Instalación cubre todas las vías de entrada.
• Aprender el vocabulario: Conceptos define traza, span, tipo y correlación, que el resto de la documentación da por sabidos.
• Sostener una ejecución entre pasos: Workflows, y luego Workers y Ejecuciones.
• Ya tienes OpenTelemetry: la ruta OTLP al completo, incluido lo que mcpd deduce de los atributos estándar.
• Ejecutarlo para otras personas: Docker y Kubernetes, y luego Ocultación y retención.

mcpd tiene licencia Apache-2.0. El protocolo de entrada, el formato de salida y la licencia que los envuelve son abiertos, así que irse cuesta tan poco como llegar.