MCP: dar a los agentes tus herramientas internas sin darles la base de datos de producción

Antes de MCP, conectar un agente a un sistema interno significaba escribir un envoltorio de herramientas a medida por cada framework de agentes, y cada cual escribía el suyo. El protocolo estandariza eso: un servidor declara las herramientas que ofrece y cualquier cliente compatible —un agente de código, un asistente de chat, una plataforma de automatización— puede descubrirlas y llamarlas.

Eso es genuinamente útil y no es la parte interesante. La parte interesante es que, en cuanto tus sistemas son direccionables por un agente, el diseño de herramientas pasa a ser una disciplina de seguridad y fiabilidad en vez de un ejercicio de fontanería.

Diseña la herramienta, no el endpoint

El instinto es envolver la API existente uno a uno. Resístete. Un agente al que le das GET /clientes, GET /pedidos y GET /facturas hará nueve llamadas y montará mal la respuesta. Un agente al que le das resumen_cliente(id_cliente) que devuelve esa misma información ya cruzada hace una llamada y acierta.

Las herramientas deben tener la forma de las preguntas que hace la gente, no la de tu modelo de datos. Menos herramientas, más gruesas y con forma de tarea ganan en todos los ejes a un espejo fiel de la API: precisión, latencia y coste en tokens.

Lo mismo vale para la salida. Devuelve lo necesario, no el registro completo: cada campo innecesario es contexto gastado en todos los turnos siguientes, y una herramienta que devuelve un bloque JSON de 40 KB degradará el razonamiento de todo lo que venga después en la conversación.

Las descripciones son prompts

La descripción de la herramienta es cómo el agente decide si la llama. «Devuelve datos del cliente» produce llamadas al azar. «Devuelve estado de facturación, plan y número de facturas abiertas de un cliente. Úsala para preguntas sobre qué está pagando un cliente. No incluye el histórico de soporte» produce un enrutado correcto.

Escribe la descripción como instrucciones a un compañero nuevo y competente, incluyendo cuándo no usar la herramienta. La cláusula negativa es la que se deja fuera todo el mundo y hace más trabajo que la positiva.

Identidad: la decisión que hay que tomar pronto

Tres modelos, en orden creciente de esfuerzo y seguridad.

Identidad de servicio. El servidor guarda una credencial y todas las llamadas pasan por ella. Simple, y significa que cualquier usuario del agente llega a todo lo que llega el servicio. Aceptable para lectura de datos no sensibles; no aceptable para nada específico de un cliente.

Identidad delegada. Se propaga el token del usuario final y el backend aplica su autorización de siempre. Es la respuesta correcta casi siempre, porque tu modelo de permisos ya existe y reimplementarlo en la capa de herramientas es como aparecen los huecos.

Identidad de servicio acotada por agente. Un principal dedicado con una política estrecha, cuando delegar es imposible. Entonces la restricción tiene que estar en la propia firma: una herramienta que toma el identificador de cliente del contexto de la petición y no de los argumentos del modelo no puede ser convencida de traer otro cliente.

Elijas el que elijas, escribe el conjunto alcanzable, como en medir el radio de acción de un agente.

Lectura y escritura, separadas

Expón lecturas con generosidad y escrituras con estrechez. Una herramienta de escritura debería hacer una operación de negocio concreta con entradas validadas —crear_ticket_soporte(asunto, cuerpo, id_cliente)— y nunca un ejecutar_sql genérico ni un llamar_api(metodo, ruta, cuerpo), que son los dos atajos más habituales y ambos entregan todo de golpe.

Limita la frecuencia por agente, registra cada llamada con sus argumentos y la identidad bajo la que corrió, y haz que las operaciones destructivas exijan un token de confirmación que solo pueda producir un flujo humano.

Operarlo

Un servidor MCP es un servicio de producción. Necesita comprobaciones de salud, tiempos límite, una versión y un camino de obsolescencia para las herramientas que retires: los agentes se rompen igual que los clientes. Ejecútalo dentro de tu red, ponle autenticación delante y no lo expongas a internet, porque un endpoint de herramientas al que llega cualquiera es una API sin capa de autorización.

Y sé escéptico con los servidores de terceros. Instalar uno le da un canal hacia el contexto de tu agente; una descripción de herramienta maliciosa o descuidada es un vector de inyección. Revisa lo que instalas con la seriedad que aplicarías a una dependencia con credenciales, porque es exactamente eso.

Qué hacer esta semana

Lista las cinco preguntas que tu equipo le hace más a menudo a los sistemas internos, las que hoy significan abrir tres pestañas. Esas son tus cinco primeras herramientas, y casi nunca son un mapeo uno a uno de ningún endpoint que ya tengas.