En el capítulo anterior pusimos en marcha un agente mínimo que conecta herramientas al cerebro (LLM) y gira su propio bucle. Con esa experiencia lo habrás notado: la capacidad real de un agente la determina casi por completo «a qué herramientas está conectado». En este capítulo saldremos del desgaste de fabricar esas herramientas una y otra vez, y aprenderemos a conectar de forma estándar con herramientas y datos externos mediante un estándar común: MCP (Model Context Protocol). MCP nació en Claude y hoy se está convirtiendo en el estándar de conexión que se extiende a toda la industria.
La meta es «conectar con seguridad mediante un estándar común, sin fabricar tú las herramientas»
Por qué la conexión de herramientas es el meollo del agente
El LLM en sí, por muy listo que sea, solo puede «generar palabras». Conocer el stock más reciente o escribir una línea en un archivo es imposible sin un medio para tocar el mundo exterior. Que un agente pueda girar el bucle de «investigar, ejecutar, comprobar» se debe justamente a que tiene herramientas que actúan sobre el exterior.
Es decir, el techo de la capacidad de un agente lo determinan la calidad y el número de herramientas conectadas. Con el mismo LLM, un agente que solo tiene una calculadora y un agente conectado a bases de datos, búsqueda, archivos y APIs internas pueden hacer cosas radicalmente distintas. No es raro que, en lugar de cambiar el cerebro por uno mejor, conectar buenas herramientas con acierto haga crecer mucho más la capacidad percibida.
💡 «Bien surtido de herramientas» pesa más que «muy inteligente». Ni la persona más capaz puede hacer nada con la caja de herramientas vacía. Buena parte del tiempo del desarrollo de agentes se dedica, en realidad, a diseñar «qué herramientas dar y cómo darlas con seguridad». Este capítulo es el núcleo de eso.
Los límites de la definición de herramientas «a pelo»
En el capítulo anterior definimos las herramientas con nuestras propias manos. Escribir la función, pasar al LLM el nombre, los argumentos y la descripción, y ejecutar y devolver el resultado cuando llega la invocación: ese flujo en sí es correcto y sigue siendo la base. El problema está en rehacerlo cada vez, por cada herramienta y por cada proyecto.
Pensemos, por ejemplo, en una «herramienta para buscar en una base de datos». Escribir la conexión, componer la consulta, formatear el resultado, tratar los errores, manejar con seguridad las credenciales… Todo este conjunto lo implementa por su cuenta cada uno: en tu proyecto, en el equipo de al lado y en otro lenguaje. La realidad de la definición «a pelo» es que desarrolladores de todo el mundo construyen la misma herramienta reinventando la rueda una y otra vez.
Una herramienta escrita para un proyecto queda atada a ese framework y ese lenguaje, y cuesta llevarla a otro sitio.
Al conectar M tipos de herramienta a N bases de agentes, en teoría hacen falta N×M piezas de código de conexión.
Cada vez que cambia la especificación del destino, hay que arreglar por separado las herramientas caseras desperdigadas por todas partes.
Esto se parece mucho a la época en que cada periférico necesitaba su cable propio. Una toma para la impresora, otra para el ratón: cuantos más aparatos, más explota el número de formas de conectar. Si hay «una toma común», toda esa molestia desaparece de golpe. Ahí es donde entra MCP.
Qué es MCP: el estándar común de conexión de herramientas
MCP (Model Context Protocol) es un estándar abierto para conectar la IA con herramientas y datos externos de forma estándar. Anthropic lo publicó para Claude a finales de 2024 y, después, distintas herramientas y servicios de IA lo adoptaron. A día de hoy, en 2026, está ampliamente adoptado más allá de un solo proveedor y ha crecido hasta ser un estándar de la industria que se cultiva bajo una gobernanza neutral. Lo importante es que no es el producto de una sola empresa, sino una especificación común que cualquiera puede implementar.
La idea de MCP, en una frase, es «el USB de la conexión de herramientas de IA». Igual que, al aparecer el USB, los periféricos de cualquier fabricante pasaron a usar la misma toma, una herramienta compatible con MCP funciona con «solo conectarla» en cualquier agente compatible con MCP. Al seguir el mismo acuerdo quien la crea y quien la usa, el infierno combinatorio N×M se pliega a «N + M».
El agente que tú construyes, o apps como Claude, están de este lado. Es quien pregunta al servidor «¿qué herramientas hay conectadas ahora?» e invoca las que necesita.
Es quien expone funciones como «herramientas»: manejo de archivos, búsqueda en BD, integración con SaaS… Un solo servidor puede tener varias herramientas.
Ambos conversan siguiendo un procedimiento fijado. Cuando el cliente se conecta, primero recibe del servidor «la lista de herramientas disponibles» y «la descripción y los argumentos de cada una». El LLM mira esa lista, elige la herramienta que encaja con el objetivo y la invoca, y el servidor la ejecuta y devuelve el resultado. Que este ida y vuelta funcione sin una implementación específica por herramienta es el meollo de MCP.
Cliente → Servidor : «Dime qué herramientas hay disponibles» Servidor → Cliente : «search_docs / read_file / query_db, con estas descripciones» El LLM decide : «Voy a llamar a query_db con el argumento {sql:"..."}» Cliente → Servidor : «Ejecuta query_db» Servidor → Cliente : «El resultado son estas filas de datos»
Las formas de exponerlo son, sobre todo, dos: el tipo local, que se ejecuta como proceso en tu propia máquina, y el tipo remoto, al que te conectas a través de la red. Lo local va bien para tus archivos o una BD de desarrollo; lo remoto, para integraciones con SaaS compartidas en equipo. En ambos, el acuerdo de «recibir la lista de herramientas e invocarlas» es el mismo, y la forma de manejarlo del lado del cliente apenas cambia.
📖 Primero, el panorama. Si lees antes el artículo explicativo «Qué es MCP», que ordena de forma sencilla el origen, la terminología y el estado de adopción de MCP, este capítulo entrará sin esfuerzo. Como los detalles de la especificación y las versiones evolucionan rápido, antes de implementar consulta siempre lo más reciente en la documentación oficial.
Usar y crear servidores MCP
Lo más jugoso de MCP es que puedes usar tal cual servidores ya publicados en el mundo. Las herramientas de uso frecuente, casi siempre, alguien las tiene ya preparadas como servidor MCP. Al conectarlas a tu propio agente, su capacidad crece de golpe sin reinventar la rueda.
Lectura y escritura en una carpeta indicada. La base para hacerle leer documentos o escribir resultados.
Ejecutar SQL o consultar el esquema. Ante «agrégalo», puede responder consultando los datos reales.
Búsqueda web o de conocimiento interno. Se convierte en la «mano para investigar» que trae información reciente y fundamentos.
Gestión de tareas, chat, almacenamiento… Convierte tus herramientas de trabajo actuales en manos y pies del agente.
El procedimiento de conexión en sí es sencillo. Solo tienes que arrancar el servidor que quieras usar (o indicar su URL) y registrar en la configuración del cliente la ubicación del servidor y las credenciales. A partir de ahí, el agente recibe la lista de herramientas al conectarse y las invoca según haga falta. No necesitas escribir «el interior de la herramienta de búsqueda en BD». Tu trabajo pasa a ser combinar las herramientas ofrecidas según el objetivo.
⚠️ «Conectar todo porque es cómodo» está prohibido. Cada servidor que añades suma tantas descripciones al LLM como herramientas tenga, dispersa su criterio y amplía el margen para operaciones erróneas. Lo básico es conectar solo las herramientas que ese agente realmente necesita para su objetivo. Demasiadas herramientas, más bien, bajan la precisión.
También puedes crear tus propios servidores
Las herramientas para las que no hay un servidor ya hecho —una API interna propia, lógica de negocio especial…— basta con que escribas tú mismo un servidor MCP. Ahí está la virtud de MCP: una vez que lo publicas como servidor, cualquier agente compatible puede usarlo igual. Una herramienta que creaste para un proyecto se reutiliza sin reescribir en el siguiente proyecto o en otro agente del equipo.
El interior de crear un servidor consiste en «definir como herramienta la función que quieres ofrecer, declarar su nombre, argumentos y descripción, y, cuando la invocan, ejecutar el proceso y devolver el resultado». La idea es la misma que la definición «a pelo» del capítulo anterior, pero difiere de forma decisiva en que la salida no es «un agente concreto», sino «la toma común que es MCP». El esfuerzo de crearla es una sola vez; la reutilización, tantas como quieras.
🛠 Si quieres meterte en la implementación. Para el código concreto de montar agentes y conexión de herramientas con Claude, Introducción al Claude Agent SDK es práctico. El SDK trae un mecanismo para manejar servidores MCP, y tanto conectar servidores ya hechos como crear los tuyos se puede avanzar siguiendo los pasos de la documentación oficial.
Qué herramientas dar y cómo darlas
Cuando ya sabes «conectar» herramientas, la siguiente pregunta es «qué dar y cómo darlo». Aquí está el punto de diseño que decide la calidad y la seguridad del agente, y que además es la base de los capítulos siguientes. Retengamos 3 principios.
Da solo las herramientas y el alcance que esa tarea necesita. «Si basta con leer, no des permiso de escritura». Para una BD, una cuenta limitada de solo lectura; para archivos, solo la carpeta objetivo: esa es la base.
El LLM decide si usar o no una herramienta fiándose solo de su descripción. Escribe en concreto «qué hace, cuándo usarla, qué significan los argumentos y en qué situaciones no debe usarse». Una descripción ambigua genera mal uso.
Las operaciones irreversibles —escribir, borrar, cobrar, ejecutar comandos— no van al mismo nivel que las de lectura. Añádeles siempre confirmación previa, restricción del objetivo y registro.
El ③, en especial, es importante. Las herramientas de «investigar» (buscar, consultar, leer), aunque se invoquen por error, difícilmente hacen mucho daño. En cambio, las de «cambiar» (escribir, borrar, enviar, ejecutar) generan con una sola operación errónea un resultado irreversible. La regla de oro es separar conscientemente las de lectura de las de escritura y apilar guardas sobre las segundas.
| Tipo | Ejemplo | Riesgo | Cómo darla, a modo de guía |
|---|---|---|---|
| De lectura | Buscar, consultar, leer archivos | Bajo (cuidado con el manejo de la información) | Con relativa libertad. Acota el alcance |
| De escritura | Actualizar archivos, escribir en BD, enviar | Alto (difícil de deshacer) | Confirmación, restricción y registro obligatorios |
| De ejecución | Ejecutar comandos, llamadas externas, cobros | Máximo (puerta al descontrol y al abuso) | Guarda por norma + intercalar aprobación humana |
🔒 Esto lo haremos a fondo en el capítulo 6. El control de las herramientas peligrosas, las medidas contra la inyección de prompts y el diseño del flujo de aprobación son temas ineludibles para llevar un agente a producción. Como los tratamos todos juntos en el capítulo 6, «Guardarraíles y seguridad», de este capítulo llévate solo la sensación de que «hay una diferencia de peligrosidad entre herramientas». No conectar a la ligera servidores MCP en los que no confías es también un hábito importante.
Herramientas avanzadas como el manejo del navegador
Entre las herramientas, una que ha ganado especial atención últimamente es el manejo del navegador. Mirar la pantalla, seguir enlaces, rellenar formularios, pulsar botones: si puedes delegar en el agente lo que una persona hace en el navegador, muchos servicios web sin una API propia se convierten en sus «manos y pies». También han aparecido implementaciones que ofrecen el manejo del navegador como servidor MCP, y la barrera para conectarlo ha bajado.
Ahora bien, es también una de las herramientas más potentes y de mayor riesgo. El peligro de aceptar tal cual las instrucciones que hay en pantalla (manipulación, desinformación), clics o envíos no intencionados, la exposición de credenciales: le aplican de lleno las advertencias de las «de ejecución» de la sección anterior. Lo prudente es empezar por usos más cercanos a la lectura, como navegar y obtener información, y poner guardas cuidadosas en las operaciones que implican escritura.
🌐 ¿Hasta dónde se le puede delegar? La capacidad y los límites reales de un agente que maneja el navegador se examinan en concreto en ¿Hasta dónde puede automatizar la IA las tareas del navegador?. Coger la distancia justa —«no es universal, pero acotando el uso es práctico»— evita que se te tuerza el criterio al elegir herramientas.
Más allá del navegador, cuanto más avanzada es una herramienta, más crecen en proporción «lo que puede hacer» y «lo que puede ocurrir». Cuanto más potente sea la herramienta que das, con más cuidado los 3 principios de privilegios, descripción y guardas: ese es el mensaje que hemos repetido a lo largo de este capítulo.
- La capacidad del agente la determinan la calidad y el número de herramientas conectadas. A menudo, el diseño de las herramientas pesa más que el cerebro.
- Definir herramientas «a pelo» es difícil de reutilizar y desemboca en el infierno combinatorio N×M. Acabas queriendo una toma común.
- MCP es un estándar abierto que conecta la IA con herramientas externas de forma estándar. Es el «USB de la IA», donde cliente (quien usa) y servidor (quien ofrece) conversan bajo el mismo acuerdo.
- Puedes conectar y usar servidores MCP ya hechos (archivos/BD/búsqueda/SaaS), y convertir tus herramientas propias en servidores caseros reutilizables.
- Los principios de cómo darlas: ① privilegios al mínimo ② calidad de la descripción ③ trato aparte para lo peligroso. Cuanto más potente la herramienta (como el navegador), con más cuidado.
Cuando ya sepas surtir de herramientas, el siguiente paso es «multiplicar los agentes». Avanzaremos hacia un diseño donde el trabajo que un solo agente no abarca se reparte y coordina entre varios. En el siguiente capítulo 4, «Diseño multiagente», aprenderemos el reparto de papeles y la cooperación entre agentes (A2A).