Agentes de IA en producción: lo que aprendí con 22 MCP tools

Versión corta y en español de un caso de estudio más largo. El análisis completo, con todas las fuentes y métricas, está en inglés.

Este año construí, en unas doce semanas, una plataforma personal de valuación de acciones cuyo usuario principal no es una persona: es un agente de IA. Claude se conecta por Model Context Protocol (MCP), consulta datos de mercado en vivo y fundamentales de la SEC, corre modelos de valuación y escribe cada decisión en una base de datos que sobrevive a cualquier conversación.

Los tutoriales de MCP terminan justo donde empiezan las preguntas reales: cuántas tools son demasiadas, dónde debe vivir la memoria del agente, qué guardrails aguantan a un modelo que rodea las reglas que le estorban. Nada de eso estaba resuelto cuando lo construí — esto es lo que decidí, y lo que el ecosistema validó o contradijo después.

El sistema

• Un MCP server (Python, FastMCP) con 22 tools. Proxy delgado y sin estado: toda la lógica vive en el API.
• Un servicio FastAPI con las reglas de valuación, el caché, el motor de compliance y las integraciones (SEC EDGAR, el API de un broker, feeds de mercado).
• Postgres como caché y como memoria de largo plazo del agente: 30 tablas.
• Cuatro contenedores, Docker Compose, self-hosted; solo el endpoint MCP es público, detrás de un proxy de identidad.

Lo raro es dónde vive la inteligencia: en ningún lado del código. El sistema no hace una sola llamada a un LLM. El server entrega evidencia estructurada; el juicio ocurre en el agente que llama. El trabajo del server es hacer ese juicio auditable, no tener opiniones propias.

Un solo agente, por secuencia

Los sistemas multiagente son el demo default de 2026. Este sistema es de un solo agente — no por convicción, sino por secuencia: un agente es donde empiezas, y meses de producción nunca generaron la presión para dar el siguiente paso.

El criterio que encontré en el camino viene del propio posicionamiento de Google sobre A2A vs MCP: los protocolos agente-a-agente pagan su complejidad cuando la contraparte está del otro lado de una frontera organizacional, es opaca, y el trabajo es largo y asíncrono. Nada de eso aplica cuando eres dueño de todas las capacidades. Y un solo agente falla mejor: un solo contexto, un solo prompt que versionar, una sola trayectoria que auditar. Multiagente es un siguiente paso en el roadmap — el fan-out de research sobre muchos tickers — no un camino rechazado.

¿Cuántas tools son demasiadas?

Las 22 tools cubren más de 40 operaciones porque varias están multiplexadas: una sola tool manage_valuation recibe un parámetro action (save, get, decide, score, …). Anthropic recomienda exactamente esa consolidación, y hay un argumento extra que casi nadie menciona: un arreglo de tools estable mantiene caliente el prompt cache.

Pero el precedente más instructivo va en sentido contrario. El MCP server de GitHub consolidó agresivamente (66 tools consumían 80K tokens de contexto) y en 2026 tuvo que des-consolidar en parte, por un problema que no tiene nada que ver con el modelo: los permisos en los clientes MCP se otorgan por nombre de tool, no por argumento. Si mezclas lecturas y escrituras en una misma tool, quien quiera permitir las lecturas tiene que permitir también la escritura destructiva. La granularidad de tools se discute como problema del modelo — contexto, precisión de selección — pero también es un problema de autorización, y los dos jalan en direcciones opuestas.

Mi manage_valuation tiene exactamente ese defecto: get comparte nombre con retire. La corrección — partir la tool en la costura lectura/escritura — está arriba en mi roadmap.

Errores que el modelo puede leer

Cuando una tool call falla, el error puede ir a dos lugares: al protocolo (donde solo lo ve la infraestructura) o adentro del resultado (donde lo lee el modelo). Aquí cada error es una oración que el modelo lee tal cual, nombrando la regla que falló y qué la satisface:

save rejected by rule rfr_within_7_days: risk_free_rate_date is 2026-08-12,
which is more than 7 days old. Re-pull the current risk-free rate and rebuild
the WACC before saving.

Cuando lo construí parecía un hack. Después la spec de MCP pasó tres revisiones convergiendo en lo mismo, con la razón explícita: si el error no llega al contexto del modelo, el modelo no puede verlo ni autocorregirse.

Memoria persistente en agentes de IA: Postgres, sin base vectorial

Pregunta por memoria de agentes en 2026 y en dos párrafos te venden una base vectorial. La memoria de este sistema son filas tipadas en Postgres: el libro de valuaciones, la escalera de precios de entrada, un log de decisiones append-only, kill signals con sus calificaciones. Cada análisis se escribe de vuelta con una tool call, y el contrato obliga al agente a releer el estado antes de actuar en vez de confiar en su memoria.

Empezó como el camino de menor resistencia; resultó más defendible de lo que creí. Una fila tipada no se degrada: una columna fair_value no se vuelve vaga en su quinta compactación, que es el modo de falla que los sistemas de memoria en texto libre apenas están nombrando (“context collapse”). Para memoria de dominio con esquema natural, las filas con constraints ganan: provenance, historial auditable, y un CHECK que hace irrepresentable una operación sin registrar. Donde sí agregaría vectores es memoria episódica — “¿he visto un caso como este antes?” — como complemento, no reemplazo.

Guardrails que registran en vez de bloquear

El motor de compliance nació de tres malas operaciones reales que pasaron como compras normales. Tiene dos capas:

1. Reglas duras que bloquean. Dieciséis reglas rechazan una valuación internamente inválida (pesos que no suman 100, tasa libre de riesgo vieja, precios de escalera puestos a mano). Son invariantes de integridad; el modelo no puede discutirlas.
2. Juicios que se registran. Cuando una decisión viola la política — comprar arriba del fair value, operar en blackout de earnings — el motor calcula la violación a partir de hechos guardados y la registra en vez de bloquearla. La razón, de la documentación del propio módulo: un store que se niega solo sería rodeado, y entonces el override no dejaría rastro alguno.

Y el compliance nunca se acepta del que llama: el agente no se autocalifica. El server lo deriva del precio, el modelo guardado y el calendario, y guarda su propio veredicto junto a la decisión. Es la vieja división preventivo/detectivo de seguridad, aplicada a un agente — y las reglas de prompt, solas, no son una frontera de seguridad: lo que debe cumplirse se aplica del lado del server.

El agente se califica a sí mismo

Cada valuación guardada declara sus kill signals: condiciones falsables que refutarían la tesis, escritas antes de que puedan ocurrir. Después de cada reporte de earnings, el agente califica cada señal — se cumplió o no — y las calificaciones quedan guardadas junto a las predicciones originales, en historial append-only.

Una predicción registrada antes del desenlace no se puede maquillar después. Es preregistro aplicado a un agente, y atrapa el modo de falla que más importa en un sistema de apoyo a decisiones: el razonamiento confiado que simplemente estaba mal — el del agente, y el mío.

Resultados (~3 meses de era del agente)

Medido del archivo de fills, con el capital realmente desplegado como denominador y las posiciones previas rebasadas al inicio de la era:

Métrica	Portafolio de riesgo	SPY, misma ventana
Retorno sobre capital desplegado	+5.0% a +11.6% (según denominador)	+1.3%
Pérdidas realizadas de toda la era	menores que las comisiones pagadas	—
Pérdidas grandes	cero	—
Win rate	83% de 29 operaciones cerradas (muestra chica)	—

Las notas de honestidad importan tanto como la tabla: 86 días es poco, el mercado subió, y tres meses de no perder son disciplina, no alfa. Lo que aún falta del lado del sistema — tracing, costo por sesión, tasas de éxito por tool — está primero en el roadmap; prefiero publicar el hueco honesto que un número de vanidad.

Qué sigue

Observabilidad con OpenTelemetry; tests para la superficie de prompt (las 1,101 pruebas cubren el código debajo de las descripciones de las tools — y cero cubren las descripciones, que es lo único que el modelo lee); un eval harness de 20–50 tareas reales calificadas por resultado; partir las tools en la costura lectura/escritura; probabilidades en los kill signals.

La lista completa, con fuentes y el detalle de cada decisión, está en el caso de estudio en inglés.