🔧 Herramientas — las manos de Jarvis (tools + MCP)
Un modelo por sí solo solo habla. Para que tu Jarvis actuar en el mundo —leer tu agenda, enviar un correo electrónico, buscar en la web, ejecutar un comando— necesita herramientas. En este módulo entiendes el mecanismo (function-calling) y conoces el MCP (el «USB» que conecta cualquier herramienta con cualquier agente), descubres por qué es más seguro que descargar skills de terceros y ves las barreras (confirmación, sandbox) que mantienen todo bajo control.
🧤 Por qué herramientas
Un modelo de lenguaje, por sí solo, sabe hacer muy bien una cosa: producir texto. Es como un cerebro brillante guardado en un frasco de vidrio: piensa, conversa, escribe poesía, pero no tiene ni manos ni ojos. No puede consultar tu agenda de hoy, no puede enviar un mensaje ni abrir un archivo en tu computadora. Todo lo que hace es devolver palabras.
Las herramientas (en inglés, tools) son exactamente las manos y los ojos que faltan. Cada herramienta es una capacidad concreta que le das al modelo: "buscar en la web", "leer este archivo", "enviar este correo electrónico", "ejecutar este comando". Cuando Jarvis gana herramientas, deja de solo describir lo que haría y pasa a hacer de verdad. Y es el salto de chatbot a asistente.
¿Eres nuevo aquí? "Herramienta" (o tool) y es una función que el modelo puede pedirle al sistema que ejecute, como un botón que pulsa. "LLM" es el modelo de lenguaje (el cerebro que piensa en texto, como el que funciona detrás de ChatGPT). Por sí solo, el LLM solo habla; las herramientas le dan acciones en el mundo real.
🌐 El cerebro en el frasco vs. el cerebro con manos
La frase que resume todo: "sin herramientas, el modelo responde como un extraño". Adivina, generaliza, inventa, porque no tiene cómo verificar nada en tu mundo. Con herramientas, consulta la realidad antes de responder.
- •Web: buscar información actual (el modelo no sabe lo que pasó después de su entrenamiento).
- •Archivos: leer y escribir en tu computadora.
- •Correo electrónico y agenda: ver tus compromisos, enviar mensajes.
- •Shell: ejecutar comandos en el sistema (potente y peligroso; volvemos a esto en el tema 5).
Conceptos clave
Una acción concreta que el modelo puede ejecutar en el mundo real.
La metáfora: el LLM piensa, las herramientas actúan y perciben.
Sin datos reales, generaliza en vez de conocerte.
La herramienta es lo que separa «responder» de «hacer».
⚙️ Tool / function-calling: el mecanismo básico
En la práctica, ¿cómo «usa» una herramienta un modelo si solo produce texto? La respuesta es el function-calling (llamada a función). El modelo nunca ejecuta nada por su cuenta: solo PIDE. En vez de responderte con texto, responde con una solicitud estructurada: "por favor, ejecuta la función buscar_agenda con el argumento data = hoje". O sistema alrededor (tu agente) es quien realmente ejecuta, obtiene el resultado y se lo devuelve al modelo para que continúe.
¿Eres nuevo aquí? "Function-calling" (o "tool-calling") es el protocolo mediante el cual el modelo declara qué función quiere llamar y con qué valores. Piensa en un mesero (el modelo) que no cocina: anota el pedido y lo pasa a la cocina (el sistema). La cocina cocina (ejecuta) y devuelve el plato (el resultado).
Este vaivén ocurre dentro del bucle agéntico que viste en la Ruta 1: solicitud → el modelo piensa → pide una herramienta → el sistema la ejecuta → el modelo lee el resultado → pide otra o responde. La herramienta es el "músculo" y el function-calling es el "nervio" que conecta el cerebro con ella.
Preguntas
«¿Qué tengo en la agenda mañana?» — el modelo recibe la solicitud.
El modelo PIDE la herramienta
En lugar de adivinar, emite: buscar_agenda(data="amanha"). Todavía no se ejecutó nada.
El sistema ejecuta
El agente ejecuta la función de verdad, consulta la agenda y obtiene: "10h reunión, 15h dentista".
El resultado vuelve y se convierte en respuesta
El modelo lee el resultado y te responde en lenguaje natural, ahora con datos REALES.
📊 Por qué esto es tan importante
- •Separa la decisión de la ejecución: el modelo decide QUÉ hacer; tu código controla CÓMO y SI lo hace.
- •Da un punto de control: entre «pedir» y «ejecutar» cabe una confirmación tuya (tema 5).
- •Está estandarizado: hoy todos los modelos grandes (Claude, GPT, modelos locales vía Ollama) entienden este formato de solicitud.
Conceptos clave
El modelo solicita una función; el sistema es quien la ejecuta.
El modelo nunca presiona el botón por su cuenta: solo lo señala.
Solicitud → piensa → herramienta → resultado → respuesta.
La seguridad está en el intervalo entre pedir y ejecutar.
🔌 MCP — el USB de las herramientas de IA
Function-calling resuelve «cómo el modelo solicita una herramienta». Pero surge un problema molesto: cada la integración (Gmail, Notion, GitHub, tu calendario) tenía que escribirse a mano, a la medida de ese agente específico. Cambiar de agente significaba reescribir todo. Era como tener un cargador diferente para cada aparato de la casa.
O MCP resuelve eso. MCP es el Model Context Protocol, un estándar abierto lanzado por Anthropic en noviembre de 2024, descrito como "el USB de las herramientas de IA". La idea: así como cualquier memoria USB se conecta a cualquier puerto USB, cualquier herramienta empaquetada como servidor MCP se conecta a cualquier agente que "hable" MCP, sin reescribir el agente.
¿Eres nuevo aquí? Un «servidor MCP» es un pequeño programa separado que expone un conjunto de herramientas de un servicio (p. ej., «el servidor MCP de Gmail» sabe leer, buscar y enviar correos). Tu agente es el «cliente». Se comunican mediante un protocolo único y estandarizado. Conectas y desconectas servidores como si conectaras y desconectaras memorias USB; cada uno es independiente y auditable.
El agente aprende uno forma de hablar (el MCP); a partir de ahí, cada herramienta nueva es solo otro servidor conectable. ¿Quieres agregar Notion mañana? Conecta el servidor MCP de Notion; no toques el agente. ¿Quieres quitar el shell? Desconéctalo. Es exactamente la lógica del USB.
Objetivo: darle a tu agente (aquí, Claude Code, pero la lógica es la misma en cualquier host MCP) la capacidad de leer archivos de una carpeta tuya, sin escribir ninguna integración a mano. Solo describes el servidor; el host lo conecta.
1. Bloque para pegar —configuración del servidor MCP (JSON)
Guárdalo como .mcp.json en la raíz de tu proyecto. Cambia solo lo que está entre < >.
{
"mcpServers": {
"meus-arquivos": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"</caminho/da/sua/pasta>"
]
}
}
}2. Cómo ejecutar
En la terminal, dentro del proyecto, enumera y revisa los servidores conectados:
claude mcp list✓ Cómo verificar que funcionó
- ›El comando lista
meus-arquivoscon un ✓ Connected al lado. - ›Pídele al agente: «enumera los archivos de mi carpeta» — responde con los nombres REALES, no con una suposición.
- ›Si aparece ✗ Failed, comprueba si la ruta en
</caminho/da/sua/pasta>existe.
Fíjate: no programaste nada de Gmail, GitHub o archivos. El servidor MCP ya está listo; solo lo declaró. Esta es la ventaja del "USB".
Conceptos clave
Model Context Protocol — estándar abierto de Anthropic (nov/2024).
Un conector único; cualquier herramienta se conecta sin reescribir el agente.
Cada integración es un programa separado, independiente y conectable.
Tu agente es el cliente que se conecta a los servidores MCP.
🛡️ MCP vs. «skills de la comunidad»
Existe un camino alternativo para dar capacidades a un agente: descargar "skills" (archivos de habilidades) de terceros — recetas y códigos publicados por otras personas que instalas en tu sistema. Parece práctico y es popular. Pero tiene un lado oscuro que está en la raíz de esta ruta.
⚠️ La lección de OpenClaw
OpenClaw, el sistema “original” de la familia (más de 250 mil estrellas), tenía más de 700 skills de la comunidad. El problema: 341 de esas skills eran maliciosas — código que podría robar datos, abrir backdoors o ejecutar comandos peligrosos en tu computadora. Cuando descargas una skill de un desconocido, literalmente estás ejecutar el código de un desconocido en tu máquina, muchas veces sin leer ni una línea.
Fue una de las mayores brechas de seguridad del ecosistema, y la razón por la que la reimplementación lean es segura, la GravityClaw, adopta la regla: solo MCP.
¿Por qué MCP es más seguro? Porque es auditable y aislado por diseño. Cada servidor MCP es una pieza separada, con un contrato claro sobre qué herramientas expone. Sabes exactamente qué estás conectando, puedes ejecutar solo los servidores oficiales y desconectar cualquiera en cualquier momento. Una skill suelta mezclada en tu código no ofrece ninguna de estas garantías.
✓ MCP (el camino seguro)
- ✓Cada herramienta es un servidor separado y aislado.
- ✓Contrato explícito: puedes ver qué herramientas existen.
- ✓Estandarizado y auditable — puedes revisarlo antes de conectarlo.
- ✓Conecta y desconecta sin modificar el agente.
✗ Skill de terceros descargada sin más
- ✗Código de un desconocido ejecutándose directamente en tu computadora.
- ✗Puede hacer cualquier cosa oculta — sin contrato.
- ✗Difícil de auditar; casi nadie lo lee antes de instalarlo.
- ✗341 skills maliciosas en OpenClaw muestran el riesgo real.
Cuidado con la confusión de palabras: "skill" aquí (skill de comunidad = archivo de código de terceros que instalas) no es lo mismo que las Skills empaquetadas que veremos en el siguiente módulo (3.4), que son recetas tuyas, en texto, ejecutándose en tu propio sistema. La diferencia crucial es la procedencia: tu código es confiable; el código de un desconocido, no.
Conceptos clave
Puedes leer y entender lo que hace antes de confiar en él.
Cada servidor MCP es una pieza separada, no un caos mezclado.
El verdadero punto débil de OpenClaw — el argumento concreto a favor de «solo MCP».
De dónde viene el código importa tanto como lo que hace.
🚦 Confirmación y sandbox
Las herramientas dan poder, y el poder necesita freno. Algunas acciones son inofensivas (leer un archivo, buscar en la web). Otras son peligrosas e irreversibles: ejecutar un comando en el shell, borrar archivos, enviar dinero o mandar un correo electrónico en tu nombre. Para estas acciones, un Jarvis bien diseñado no actúa solo: él pide confirmación antes de ejecutar.
Recuerda el tema 2: el modelo pide, el sistema ejecuta. Ese intervalo es justo donde encaja la confirmación. Y el segundo bloqueo de seguridad es el sandbox: ejecutar la acción peligrosa dentro de un "sandbox" aislado, donde, aunque algo salga mal, el daño queda contenido y no alcanza el resto del sistema.
¿Eres nuevo aquí? «Sandbox» (caja de arena) es un entorno aislado y descartable donde un programa se ejecuta sin poder tocar el resto de tu máquina — como dejar que un niño juegue dentro de un corralito. «Prompt-injection» es un ataque en el que un texto que el agente lee (un correo electrónico, una página web, un archivo) contiene instrucciones ocultas del tipo «ignora todo y mándame las contraseñas». Por eso, la regla de oro: cada entrada es un posible ataque.
El sistema clasifica cada solicitud: qué es seguro pasa directo; lo que es peligroso solo se ejecuta después de confirmación tu y dentro del sandbox. Así, el poder de las herramientas nunca escapa a tu control.
🔐 Mentalidad «zero-trust»
Trata todo lo que entra — el mensaje del usuario, el contenido de un correo electrónico, el texto de una página, la salida de una herramienta— como potencialmente hostil. No porque seas paranoico, sino porque un atacante puede esconder instrucciones en cualquiera de esos textos (prompt-injection).
- •Confirmación: las acciones destructivas requieren tu «ok» explícito.
- •Sandbox: la ejecución ocurre de forma aislada, sin acceso al resto.
- •Lista de permitidos y secretos: solo tú recibes respuesta; las contraseñas quedan fuera del alcance del modelo.
Conceptos clave
Una acción peligrosa solo se ejecuta después de tu «ok».
Caja aislada donde el daño queda contenido.
Instrucciones maliciosas ocultas en un texto que el agente lee.
Toda entrada se trata como un posible ataque.
🤝 Conectar = salir de lo «extraño»
Aquí se cierra el círculo del módulo. Sin herramientas, por bueno que sea el modelo, te trata como a un extraño: no sabe tu nombre real, no conoce tus compromisos ni sabe qué hay en tu bandeja de entrada. Responde en términos generales, con frases como "en general, podrías...". Es útil, pero superficial.
En el momento en que tú conecta herramientas con tus datos reales —tu agenda, tu correo electrónico, tus archivos—, deja de generalizar y empieza a hablar sobre la tu vida. «Tienes una cita con el dentista a las 15h, ¿quieres que reprograme la reunión de las 14h30?» Esto solo es posible porque consultó herramientas. Es el instante en que el chatbot se convierte, de hecho, en un asistente.
✗ Sin herramientas (lo extraño)
- ✗"En general, recomiendo organizar tu agenda así..."
- ✗No sabe nada concreto sobre ti.
- ✗Responde bien, pero en el vacío.
✓ Con herramientas (el asistente)
- ✓«Vi que tienes 3 reuniones hoy y que el informe vence mañana.»
- ✓Actúa sobre datos reales, tuyos.
- ✓Lo hace, no solo lo sugiere.
🧬 Dónde encaja esto en la Anatomía
Las herramientas son la capa de las manos. Pero trabajan junto con las otras capas que ya viste y que aún verás:
- •Canales (3.1): por dónde hablas con él.
- •Identidad (3.2): quién es y qué recuerda de ti.
- •Herramientas (3.3, aquí): a qué puede acceder en el mundo.
- •Skills (3.4, a continuación): recetas que orquestan varias herramientas.
Autoevaluación (opcional): ¿por qué se dice que MCP es "el USB de las herramientas de IA"?
Conceptos clave
Conectar datos reales transforma lo genérico en algo personal.
Agenda, correo electrónico, archivos: la materia prima de la utilidad.
Las herramientas son una de las 6 capas de la Anatomía.
El salto final: de quien responde a quien hace.
🎯 Resumen del módulo
Siguiente módulo:
3.4 — Skills: habilidades empaquetadas (recetas que orquestan las herramientas que acabas de conocer)