Por Francisco Proboste, Líder de Data & IA en Clay.

El MCP de Clay es la capa que permite a Claude y ChatGPT operar las finanzas y la contabilidad de una empresa sobre la API V2 de Clay. Hoy suma 95 herramientas, cerca de un tercio de la base lo usa cada semana y la tasa de error está bajo 1%. Lo mantenemos con tres ambientes (DEV, Staging y PROD), tres capas de validación antes de cada release y telemetría en producción que convierte cada error en un caso nuevo de prueba.

Cómo operamos el MCP de Clay con Claude y ChatGPT | Clay

Desde marzo de este 2026, en Clay disponibilizamos un MCP público para que nuestros usuarios puedan llevar sus finanzas y contabilidad mediante un cliente de IA como Claude o ChatGPT. Ya teníamos experimentos y servicios internos, pero esta vez nos dispusimos a dar herramientas de sobra al público, para que pudieran partir "jugando" en una cancha nueva y bien amplia. Fue un riesgo, porque validar un MCP es distinto a validar software tradicional, y priorizamos lanzar rápido.

Seis meses después, nuestro MCP cuenta con 95 herramientas, gracias en gran parte al feedback de nuestros clientes. Cerca de un tercio de nuestra base lo usa recurrentemente cada semana, con tasas de error bajo 1%, mayormente por dificultad del cliente de IA para interpretar cómo usar la herramienta. Hoy pueden hacer más cosas vía MCP que las que permite nuestra app web. Muchos han creado agentes de IA que corren solos en las noches, sin supervisión directa, ejecutando flujos completos de automatización contable contra el MCP. Es decir, pasó a ser mucho más que una herramienta para usar Claude o ChatGPT como copiloto.

Ver a nuestros clientes operar así nos tiene muy contentos, y también nos subió la vara. Con clientes llevando su contabilidad sobre el MCP, la mantención dejó de ser un tema de roadmap y pasó a ser una operación crítica. En este artículo quiero compartir cómo la gestionamos día a día: cómo mantenemos las tasas de error bajas mientras agregamos herramientas nuevas cada semana, y cómo evitamos que la IA se confunda entre tools a medida que el MCP crece. En resumen, cómo operamos una herramienta que se volvió masiva y evoluciona rápido, sin tolerar fallas ni quemar al equipo de ingeniería.

Con esto, Clay es el primer software de gestión financiera y contable de Chile en integrarse con Claude y ChatGPT vía MCP, y este texto es el detrás de escena de cómo lo mantenemos funcionando bien.

Paridad con nuestra API

Nuestro MCP (Model Context Protocol) fue pensado como una herramienta de interoperabilidad que multiplicara el valor de código que ya funcionaba mediante la app. Para eso centralizamos la lógica de negocio en una nueva versión de nuestro API (API V2), moviendo código e integrando otros microservicios ahí. El MCP es simplemente una capa para que los agentes de IA interactúen de forma segura con esa lógica de negocio. Esta centralización minimizó los costos de mantención y explica gran parte del éxito del escalamiento de la herramienta.

Además, separa el foco del código determinístico que va en la API del código probabilístico que depende del MCP. La responsabilidad del MCP pasa a estar en que la IA entienda bien cómo ocupar la herramienta, más que en que la función cumpla bien su contrato. Eso implica que las descripciones y skills asociadas estén bien redactadas y no confundan a los LLMs que las consumen.

Tres ambientes

Además de lo anterior, definimos tres ambientes para las validaciones automáticas y semi-automáticas: DEV, Staging y PROD. Aunque API V2 solo tiene DEV y PROD, el MCP necesita un tercero. En Staging apuntamos a API V2 en producción y validamos ahí las tools nuevas, nos interesa ver cómo se comporta la IA con ellas en condiciones reales antes de publicarlas. Le damos más énfasis a validar el MCP que la API porque publicar cambios en API V2 tiene riesgo casi cero de regresión si se respetan las firmas de los endpoints, mientras que cambiar el MCP es más delicado por la naturaleza probabilística de la IA que lo ocupa.

Lo que no esperábamos es que agregar una tool, en teoría independiente de las otras, generara regresiones en herramientas que ya funcionaban: le "quita el foco" a la IA de lo que realmente tiene que hacer. Una especie de canibalización entre tools, con contextos compitiendo entre sí. Por eso un ambiente donde probar sistemáticamente el conjunto completo en cientos de casos de interacción es tan importante.

Harness de validación offline

Prácticamente todas las semanas agregamos nuevas tools al MCP, y eso exige bastante trabajo de validación antes de cada release. Para eso usamos los ambientes DEV y Staging, donde corremos tres capas de tests que responden preguntas distintas: si la tool refleja bien el endpoint, si la IA arma bien la llamada, y si la IA entiende cuándo usarla.

Drift Test vs API V2. Revisamos si ante un cambio nuestro o de la API existe algún desalineamiento de las tools. Estas últimas son una interfaz adicional utilizable por la IA, es importante que representen bien las posibilidades que da la firma de los endpoints.

Correctness Test. Acá ya no validamos la forma de la tool sino si el cliente de IA es capaz de llenarla bien. Ejecutamos llamadas reales y verificamos el payload que construyó el modelo: que los campos requeridos estén, que las fechas sean válidas, que un asiento llegue con débitos iguales a créditos.

Donde más se concentra la fragilidad es en un solo booleano, is_received: casi un tercio de los casos lo defienden. La trampa típica es la dirección del flujo. Si le pago a un proveedor, la intuición dice "salida", pero el documento lo recibí yo, así que is_received va en true. El modelo se va con la plata en vez de irse con el documento, y hay que enseñarle la diferencia caso a caso. Esta suite no la diseñamos de antemano, cada caso es la cicatriz de algo que ya nos falló una vez.

Tests de simulación. Estos son los más entretenidos. Es una forma de generar un set de validación como se haría en el Machine Learning tradicional: para cada tool generamos un conjunto de interacciones de input que esperamos deberían gatillar su uso, y para cada una establecemos un comportamiento esperado. Un agente maestro corre y evalúa estas simulaciones lanzando agentes que emulan a un usuario operando un cliente de IA como Claude o ChatGPT (Claude Web es el más usado por nuestros clientes). La diferencia con los tests anteriores es que el criterio de aprobación también está escrito en lenguaje natural y lo juzga otro agente. Y los inputs no son limpios: son usuarios hablando como hablan de verdad, con typos, jerga interna, inglés mezclado, o dos preguntas distintas en el mismo mensaje.

Lo más útil de este set son los contraejemplos. Cuando agregamos una tool no escribimos solo los casos donde debería dispararse, sino los casos donde no debería, robados del territorio de las tools vecinas. Por ejemplo: "cámbiale la cuenta a este asiento" debe ir a reclasificar, pero "cámbiale la cuenta y además el monto está malo" debe ir a editar, porque reclasificar cambia la cuenta y nada más, y dejaría el asiento descuadrado. Un modelo que dispara reclasificar en el segundo caso está sobre-generalizando por la palabra "cuenta". Estos contraejemplos son nuestra principal defensa contra la canibalización entre tools.

Este método nos resulta particularmente efectivo para detectar si los clientes de IA entienden el espíritu de cada tool y pueden usarlas eficazmente, tanto que llegó a ser una parte significativa de nuestro gasto de tokens hasta que bajamos el costo configurando prompt caching.

Las tres capas las corremos contra los tres ambientes y comparamos resultados entre ellos. Así detectamos, por ejemplo, una regresión en DEV que rompía el is_received de una tool de escritura, antes de que llegara a producción.

Este conjunto de validaciones offline, previas a cada release, nos permite un ritmo de incorporación de funcionalidades muy rápido, con inversiones que no superan las 4-6 horas-hombre por release, incluyendo las actualizaciones de comunicación a clientes internos y documentación.

Observabilidad y mantención online

Nuestro MCP también se mantiene en función de la observabilidad de su uso en producción. Para la app web usamos LogRocket, pero para el MCP decidimos usar PostHog, que tiene un SDK en Go fácil de integrar en el backend. Cada request llega en segundos al servidor colector de PostHog, que después integra esa información en nuestro Data Warehouse.

Lo que medimos es más acotado que en la app: qué tool se usó, en qué momento, desde qué cliente de IA y con qué código de respuesta. No tenemos el prompt del usuario ni el razonamiento del modelo, así que no vemos la tool que la IA descartó ni por qué, pero sí vemos reintentos y patrones de uso, y desde ahí bajamos a los logs del servidor cuando necesitamos más detalle.

Esto importa especialmente por los agentes autónomos. Un usuario con problemas para usar el MCP desde Claude o ChatGPT como copiloto puede escribir a soporte, y de hecho ahí hemos tenido excelente feedback que intentamos incorporar cuanto antes. Un agente corriendo de noche no hace nada de eso, simplemente reintenta o se queda callado. La telemetría es la única forma de enterarse, y por eso varios casos de nuestro harness exigen que el modelo explique el error que recibió en vez de reintentar a ciegas.

Como nuestro Data Warehouse centraliza información clave de casi todos los aspectos del negocio, esta data se enriquece con contexto completo. Las métricas de adopción nos muestran quiénes son power users, quiénes recién parten y quiénes no están aprovechando el MCP. También nos permite levantar errores rápido: se monitorean, pasan a triage y se resuelven con builder agents que mergean a development, o se escalan a API V2.

Y acá se cierra el círculo. Los errores que detectamos en producción no solo terminan en un fix, también se convierten en casos nuevos de simulación para el harness de validación. Producción es una fuente clave de información para mejorar lo que tenemos e imaginar nuevas posibilidades.

En resumen

El lanzamiento, mantención y escalamiento de nuestro MCP es un trabajo altamente automatizado, diseñado para que el equipo responsable sea muy efectivo. Con los puntos de control humano claros, el esfuerzo para tener esta maquinaria andando y creciendo es bastante bajo.

Dicho eso, no tenemos resuelto qué pasa cuando sean 200 tools. El esquema de contraejemplos funciona bien mientras uno pueda tener en la cabeza qué tools compiten entre sí. Si están construyendo algo parecido, ¿qué experiencia han tenido? ¿Cómo ven el futuro?

Si usas Clay y todavía no conectas el MCP, puedes partir hoy con Claude o con ChatGPT.

Preguntas frecuentes

¿Qué es el MCP de Clay?
Es la integración de Clay con Claude y ChatGPT vía Model Context Protocol. Funciona como una capa sobre la API V2 de Clay, donde vive toda la lógica de negocio, y permite que un cliente de IA consulte y opere la información financiera y contable de la empresa. Clay es el primer software de gestión financiera y contable de Chile en integrarse con Claude y ChatGPT vía MCP.

¿Cuántas herramientas tiene el MCP de Clay?
A septiembre de 2026, el MCP de Clay tiene 95 herramientas. Se suman nuevas prácticamente todas las semanas, en gran parte a partir del feedback de los clientes.

¿Cómo valida Clay las herramientas nuevas del MCP antes de publicarlas?
Con tres capas de tests que corren en DEV, Staging y PROD: un drift test que revisa que cada tool refleje bien su endpoint en API V2, un correctness test que verifica que la IA arme bien la llamada, y tests de simulación con usuarios simulados que evalúan si la IA entiende cuándo usar cada tool, incluyendo contraejemplos de tools vecinas.

¿Cómo conecto Clay con Claude o ChatGPT?
Se conecta con un token de API generado desde Clay por un administrador o propietario de la cuenta. Las guías para partir están en clay.cl/claude y clay.cl/chatgpt.