Tu agente de IA se traba en una herramienta ‘summarize’. Dos segundos evaporados. ¿Culpa del código? ¿De la API? ¿O —invisible— del LLM al que el servidor delegó?
Para los devs que arman flujos agenticos, esa era la rutina con servidores MCP. Sin visibilidad en las llamadas de sampling, todo era adivinanzas sobre rendimiento. ¿Ahora? Las trazas iluminan esos fantasmas, los dashboards métricos destapan la verdad y optimizar deja de ser magia negra.
Por qué el sampling de MCP rompía tus trazas
Las especificaciones de MCP permiten que los servidores —sin claves API para herramientas— deleguen trabajo de LLM de vuelta a los clientes. ¿Listo, verdad? Tu orquestador invoca ‘summarize’; el servidor necesita GPT-4o para digerir el texto; hace sampling al LLM del cliente. La respuesta regresa. Delegación impecable.
¿Pero las trazas? Silencio total. El middleware captura bien las llamadas a herramientas. ¿El sampling? Una invocación de método enterrada en las entrañas del handler. Ni un span. Una herramienta de 2,1 segundos donde 1,8 se queman en generación —invisible. Terminarías ajustando los 300 ms equivocados.
“La llamada a la herramienta dispara una invocación a LLM que queda invisible en la traza. El middleware del artículo #7 rastrea tools/call summarize —pero ¿la llamada de sampling adentro? Un fantasma. Sin span, sin duración, sin nombre de modelo.”
Ese era el cajón de sastre que reventaron la vez pasada. ¿Esto? La secuela que lo deja listo para demos.
Mira, ya vimos esta película. Los microservicios tempranos se ahogaban en RPCs sin trazar — ¿te acuerdas del auge de Zipkin? El sampling de MCP es el RPC de la IA agentica. Ignóralo y tus herramientas se convierten en misterios distribuidos. Arréglalo ya y vas por delante del enjambre multiagente que viene.
Cómo envolvieron esas llamadas fantasma
Cuatro ajustes. Sencillo como un chasquido.
Primero, toadEyeMiddleware para lo básico —spans en cada herramienta.
Luego, el wrapper traceSampling alrededor de ctx.mcpReq.requestSampling(). Pasa modelo, tokens. ¡Pum!: SpanKind.CLIENT llamado “chat gpt-4o”. Captura duración (¡1834 ms!), gen_ai.request.model, hasta mcp.server.name.
Perfección anidada:
tools/call summarize 2.1s └── chat gpt-4o (sampling) 1.8s
¿Lógica real? 300 ms. Optimiza eso, no los espectros.
El código es una import de una línea. En el handler: envuelve tu sampling. Cinco minutos para probar —servidor arriba, agente cliente pingueando, trazas fluyendo a tu backend OTel.
¿Pero métricas? Ahí se pone preciso como Bloomberg. Queries de Prometheus integradas. Nada de contadores vagos.
El dashboard que responde ‘¿qué se está rompiendo?’
Tabla glanceable arriba:
Tool Call Rate | Avg Duration | Error Rate | Resource Reads 12.4 req/s | 45.2 ms | 2.3% | 3.1 req/s
¿Rojo en errores? Profundiza.
Series temporales de tasas por herramienta. ¿El agente cambia de calculate a search? Las líneas lo muestran. Duraciones P50/P95 por herramienta — ¿P95 de search saltando a 2 s? Pager duty en camino.
Errores apilados: RateLimitError en search (8.7%), Validation en calculate (0%). Recursos por URI —fuentes de datos calientes gritando.
Abajo: tabla fusionada por herramienta.
| Herramienta | Tasa | Prom (ms) | P95 (ms) | Errores |
|---|---|---|---|---|
| calculate | 8.2 | 12.3 | 24.1 | 0% |
| get-weather | 3.1 | 145.2 | 312.8 | 3.2% |
| search | 1.1 | 890.4 | 2134 | 8.7% |
Esto no es relleno. Es la vista para la junta directiva: costos ligados a duraciones, errores a fugas de ingresos. ¿Escalas agentes? Les vas a agradecer estas cuatro métricas.
¿Es este el momento Zipkin para agentes de IA?
Mi ventaja: nadie lo dice, pero la observabilidad de MCP va años luz atrás de LangChain —esos ecosistemas trazan todo, hype o no. La spec más pura de MCP brilla, pero las herramientas ocultaban joyas como el sampling.
¿Predicción? Con agentes encadenando servidores (multi-MCP a la vista), este trazado s
