¿Qué son AI Skills y Tools?

🔧 ¿Qué es un Skill?

En el contexto de los agentes de IA, un skill (también llamado un tool or function) es una capacidad empaquetada y reutilizable que un LLM puede invocar para interactuar con el mundo fuera de su ventana de contexto. Los skills cierran la brecha entre la comprensión del lenguaje y la acción en el mundo real.

Cada skill tiene cuatro componentes:

• Name — un identificador único que el modelo usa para referirse al skill (p. ej., web_search)
• Description — texto en lenguaje natural que explica qué hace el skill y cuándo usarlo; el LLM lee esto para decidir cuándo invocar el skill
• Esquema de entrada — una definición estructurada de los argumentos (JSON Schema); el modelo los completa según la tarea
• Implementation — el código real que se ejecuta: una llamada API, una consulta a la base de datos, un comando de shell, o cualquier otra operación

Ejemplo: A get_weather skill tiene la descripción "Obtiene el clima actual de una ciudad", acepta { "city": "string" } como entrada, y llama a una API de clima. El LLM nunca ve la clave de la API ni la llamada HTTP — solo recibe el resultado de vuelta como texto.

⚙️ Cómo funciona la invocación de herramientas

Cuando un agente tiene acceso a skills, el LLM no los invoca directamente — él requests una llamada generando una salida estructurada. El runtime (tu código de aplicación) ejecuta la llamada real y devuelve el resultado. Aquí está el ciclo completo:

1. Registro de herramientas — Tu código envía al modelo una lista de skills disponibles con sus descripciones y esquemas
2. Razonamiento del modelo — El LLM lee la tarea y las herramientas disponibles, decide qué herramienta invocar y con qué argumentos
3. Solicitud de llamada a herramienta — El modelo emite un mensaje "tool call" estructurado (p. ej., { "tool": "web_search", "args": { "query": "current Gemini models" } })
4. Execution — Tu código runtime llama a la función, API o servicio real
5. Inyección de resultados — El resultado se añade de nuevo al contexto de la conversación
6. Razonamiento continuo — El modelo lee el resultado y o bien invoca otra herramienta, hace una pregunta de seguimiento o genera la respuesta final

Este bucle puede repetirse muchas veces en un solo turno. Una tarea agente compleja podría llamar a 10–20 herramientas en secuencia antes de producir una respuesta final.

📊 Skills vs Plugins vs MCP Servers

La terminología ha evolucionado rápidamente. Así es como los conceptos se relacionan históricamente:

Distinción clave: El uso tradicional de herramientas se define en línea en el código de tu aplicación. Los MCP servers son procesos independientes que exponen herramientas sobre un protocolo estandarizado — haciéndolas reutilizables entre diferentes clientes de IA (Claude Desktop, Cursor, VS Code, agentes personalizados). Leer más: Qué es MCP.

🗂️ Categorías de herramientas y niveles de riesgo

No todas las herramientas conllevan el mismo riesgo. Agrupar por nivel de riesgo ayuda a definir el espacio de acción y dónde añadir puntos de control human-in-the-loop:

🏗️ Anatomía de un buen Skill

La decisión de diseño más importante para un skill es su description. El LLM lee las descripciones para decidir qué herramienta invocar — una descripción mal redactada conduce a la selección errónea de la herramienta, llamadas no realizadas o argumentos ambiguos.

Qué hace efectiva una descripción

• Sé explícito sobre cuándo usarlo — "Usa esta herramienta cuando el usuario pregunte por datos en tiempo real o eventos actuales" es mejor que "Busca en la web"
• Indicar lo que NO hace — "No devuelve datos históricos de más de 30 días"
• Describir el formato de salida — "Devuelve un arreglo JSON de resultados de búsqueda con campos title, url y snippet"
• Mantenerlo por debajo de 200 palabras — descripciones más largas de ~200 tokens pueden sobrecargar la atención del modelo cuando se registran muchas herramientas

Principios de diseño de esquemas

• Requerido vs opcional — Marca los campos como required solo si es realmente necesario; los campos opcionales con valores por defecto reducen errores del modelo
• Usar enums para valores restringidos — "format": {"enum": ["json", "markdown", "text"]} evita valores alucinados
• Preferir herramientas idempotentes — Las herramientas que se pueden reintentar de forma segura (lecturas, búsquedas) son más seguras que acciones de una sola vez (envíos, eliminaciones)
• Devolver datos estructurados — Las respuestas JSON son más fáciles para que el modelo razone que los blobs de texto no estructurados

💡 Ejemplos en el mundo real

✅ Buenas prácticas

Permisos mínimos

Conceder a cada agente solo las herramientas que necesita para su tarea específica. Un agente que responde preguntas frecuentes no necesita write_file or send_email. Cuanto más pequeño sea el espacio de acción, menor será el radio de impacto si el agente es manipulado. Véase: Agencia excesiva.

Auditar todas las llamadas a herramientas

Registrar cada llamada a herramienta con sus argumentos y resultado. Esto permite depuración, atribución de costos y detección de comportamiento anómalo (p. ej., un agente leyendo ~/.ssh/ cuando debería acceder solo al directorio del proyecto). Plataformas AgentOps como LangSmith facilitan esto.

Intervención humana para acciones irreversibles

Cualquier acción que sea difícil o imposible de deshacer — enviar mensajes, eliminar datos, realizar compras — debe requerir confirmación humana explícita antes de su ejecución. Inserta puntos de control HITL en el runtime del agente, no solo en el prompt. Los prompts se pueden anular; el código no.

Cuidado con el envenenamiento de herramientas

Si permites que los agentes instalen o descubran MCP servers dinámicamente, un servidor malicioso puede registrar una herramienta con una descripción que contenga instrucciones ocultas. Revisa siempre las descripciones de herramientas antes de añadirlas al registro del agente. Véase: Envenenamiento de herramientas.

Escribir retornos de error claros

Cuando una herramienta falla, devuelve un error estructurado con suficiente contexto para que el modelo se recupere o escalé — no un stack trace de excepción sin procesar. Ejemplo: { "error": "rate_limited", "retry_after": 5 }. Un error bien descrito permite que el agente reintente, use una herramienta alternativa o informe al usuario con gracia.