Comprendiendo MCP: Herramientas, Recursos y Prompts
El Protocolo de Contexto del Modelo, o MCP, es un protocolo abierto para conectar modelos de IA con herramientas, datos y servicios externos.
Antes de MCP, cada integración entre un modelo y un sistema externo era un trabajo personalizado, cableado manualmente para un cliente y un backend a la vez.
MCP reemplaza ese cableado único con un contrato compartido, de modo que una única implementación de servidor puede exponer sus capacidades a cualquier cliente compatible con MCP sin reescribir la integración cada vez.
Ese contrato se construye a partir de tres primitivas, y comprender para qué sirve cada una es el primer paso para diseñar un buen servidor MCP.
Resumen
- Idea Central: MCP estandariza cómo un modelo de IA descubre y utiliza capacidades externas a través de tres primitivas: Herramientas, Recursos y Prompts.
- Por Qué Importa: Sin un protocolo compartido, cada integración modelo-sistema es específica, frágil y está bloqueada a un solo cliente.
- Conceptos Clave: Herramientas (funciones invocables), Recursos (datos legibles, direccionables por URI), Prompts (plantillas parametrizadas reutilizables), diseño independiente del cliente, descubrimiento.
- Cuándo Usar: Utiliza MCP cuando una capacidad deba ser utilizable por más de un cliente de IA, cuando desees un contrato estable entre tus sistemas y cualquier modelo, o cuando estés construyendo un servidor destinado a sobrevivir a una única integración.
- Limitaciones / Compensaciones: MCP añade una capa de esquema y sobrecarga de protocolo en comparación con la conexión directa de una llamada a función en una sola aplicación.
- Temas Relacionados: llamada a funciones, esquemas de herramientas, URIs de recursos, plantillas de prompts, selección de transporte.
Fundamentos
En su centro, MCP define una relación cliente-servidor.
Un cliente MCP, como Claude Code, Claude Desktop, Cowork o una aplicación personalizada construida sobre el Agent SDK, se conecta a un servidor MCP.
El servidor anuncia lo que puede hacer, y el cliente (y el modelo detrás de él) decide cuándo y cómo utilizar esas capacidades.
Lo que el servidor anuncia cae exactamente en tres categorías.
Las Herramientas son funciones invocables.
Una herramienta tiene un nombre, una descripción y un esquema que describe sus entradas, y cuando el modelo decide usarla, el cliente envía una llamada y el servidor devuelve un resultado.
Esta es conceptualmente la misma idea que la llamada a funciones en una API típica de LLM, solo que estandarizada para que cualquier cliente MCP pueda descubrirla e invocarla de la misma manera.
Los Recursos son datos legibles, no acciones.
Un recurso es cualquier cosa direccionable por una URI: un archivo en disco, una fila en una base de datos, la respuesta de una API interna, un valor de configuración.
En lugar de que el modelo llame a una función para obtener datos, el cliente puede leer un recurso directamente, similar a cómo un navegador busca una URL.
Los Prompts son plantillas de prompts reutilizables y parametrizadas.
Una plantilla de prompt empaqueta instrucciones, quizás con marcadores de posición para argumentos, de modo que múltiples clientes puedan invocar exactamente el mismo prompt bien probado en lugar de que cada uno improvise su propia redacción.
Piensa en los prompts como la forma en que el servidor dice "aquí está la forma correcta de pedir esto", compartida una vez y reutilizada en todas partes.
Un ancla mental simple: Las Herramientas son verbos, los Recursos son sustantivos y los Prompts son guiones.
Mecánicas e Interacciones
La relación entre estas tres primitivas se aclara una vez que consideras cómo un cliente realmente usa un servidor durante una sesión.
Cuando un cliente se conecta, pregunta al servidor qué ofrece, y el servidor responde con listas de sus herramientas, recursos y prompts, cada uno con metadatos que el cliente puede presentar al modelo o a un usuario.
Para las herramientas, esos metadatos son un esquema: el nombre de la herramienta, una descripción en lenguaje natural y una definición estructurada de sus argumentos esperados.
El modelo lee estas descripciones y esquemas para decidir, durante una conversación, si llamar a una herramienta en particular ayudaría a responder la solicitud actual.
Para los recursos, el cliente puede listar las URIs disponibles y leer sus contenidos, ya sea porque el modelo lo solicitó o porque la aplicación circundante eligió adjuntar ese contexto directamente.
Para los prompts, el cliente (o un usuario) selecciona un prompt con nombre, opcionalmente suministra argumentos y recibe de vuelta un conjunto completo de mensajes listos para enviar al modelo.
Un solo servidor generalmente mezcla los tres.
Un servidor de documentación, por ejemplo, podría exponer una herramienta search_docs, un recurso docs://page/{id} para leer una página individual y un prompt summarize_page que siempre le pide al modelo que resuma una página de la misma manera bien ajustada.
# Forma ilustrativa solamente - consulta las páginas "Definición de Herramientas Invocables" y
# "Exposición de Datos Legibles como Recursos MCP" para ver el código completo del servidor.
server.tool("search_docs", handler=search_docs_handler)
server.resource("docs://page/{id}", handler=read_page_handler)
server.prompt("summarize_page", handler=summarize_prompt_handler)La distinción mecánica importante es quién inicia el intercambio y qué tipo de resultado regresa.
Una llamada a herramienta es iniciada por el modelo y devuelve un resultado que se convierte en parte de la conversación.
Una lectura de recurso puede ser iniciada por el modelo o iniciada directamente por el cliente, y devuelve datos, no un resultado calculado.
Una invocación de prompt es típicamente iniciada por el usuario o el cliente y devuelve contenido de mensaje destinado a sembrar o dirigir una conversación, no datos brutos o un efecto secundario.
Consideraciones Avanzadas y Aplicaciones
La razón por la que MCP define tres primitivas en lugar de solo "funciones que el modelo puede llamar" es que la llamada a funciones ordinaria solo cubre el caso de las Herramientas, y lo hace de una manera estrechamente ligada a una API y un cliente.
Si has utilizado la llamada a funciones directamente contra una API de modelo, ya has construido algo similar a una herramienta MCP, solo que sin el formato de esquema estandarizado, sin descubrimiento y sin portabilidad a otros clientes.
MCP toma esa misma idea y le añade un sobre de protocolo, además de dos primitivas más que la llamada a funciones por sí sola no aborda bien: acceso a datos masivos o estructurados (Recursos) e instrucciones compartidas y versionadas (Prompts).
Esta distinción importa más una vez que un servidor necesita servir a más de un cliente.
Una herramienta implementada como una función única dentro de una sola aplicación debe ser reimplementada, y puede desincronizarse, si una segunda aplicación desea la misma capacidad.
Una herramienta MCP definida una vez en un servidor está inmediatamente disponible, con el mismo esquema y comportamiento, para cualquier cliente que se conecte a ese servidor, ya sea Claude Code en la máquina de un desarrollador o una aplicación personalizada del Agent SDK en producción.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Llamada a funciones ordinaria | Simple, sin capa adicional, más rápido de prototipar | Ligado a un solo cliente y una integración de API | Una sola aplicación que nunca compartirá la capacidad |
| Herramienta MCP | Reutilizable en cualquier cliente MCP, esquema y descubrimiento estandarizados | Requiere ejecutar o conectarse a un servidor, más partes móviles | Capacidades que múltiples clientes o equipos necesitan |
| Recurso MCP | Clara separación de "leer datos" de "tomar acción", almacenable en caché | No apto para nada que tenga efectos secundarios | Archivos, filas de bases de datos, respuestas de API que el modelo debe leer |
| Prompt MCP | Instrucciones consistentes y versionadas entre clientes | Otro artefacto para diseñar y mantener | Flujos de trabajo compartidos donde la calidad de la redacción importa |
Elegir la primitiva correcta para una capacidad dada es en sí misma una decisión de diseño que vale la pena tomar en serio.
Exponer una fuente de datos de solo lectura como una herramienta en lugar de un recurso funciona, pero oculta al cliente que la operación es segura para almacenar en caché y no tiene efectos secundarios.
Por el contrario, exponer algo con efectos secundarios, como enviar un correo electrónico, como un recurso sería engañoso, ya que los recursos están destinados a ser leídos, no ejecutados.
Obtener esta clasificación correcta desde el principio hace que el comportamiento de un servidor sea predecible para cualquier cliente que se conecte a él más tarde, incluidos los clientes que no construiste tú mismo.
Conceptos Erróneos Comunes
- "Las herramientas MCP son solo llamadas a funciones con pasos adicionales." El mecanismo subyacente de llamada y respuesta es similar, pero la capa de protocolo es lo que hace que una herramienta sea utilizable por cualquier cliente compatible en lugar de una integración cableada.
- "Los recursos y las herramientas son intercambiables si una herramienta puede simplemente devolver datos." Una herramienta que solo lee datos todavía lleva la implicación de una acción; un recurso es explícitamente direccionable y almacenable en caché de una manera que una llamada a herramienta no lo es.
- "Los prompts son extras opcionales que la mayoría de los servidores omiten." Los prompts importan más exactamente cuando la consistencia entre clientes es importante, como un flujo de trabajo de soporte compartido o una instrucción estandarizada de revisión de código.
- "Un servidor MCP tiene que exponer las tres primitivas." Un servidor puede exponer solo herramientas, solo recursos, solo prompts, o cualquier combinación; nada requiere las tres.
- "MCP es una característica específica de Claude." MCP es un protocolo abierto; es compatible con Claude Code, Claude Desktop y Agent SDK, pero cualquier cliente compatible con MCP puede usar un servidor conforme.
Preguntas Frecuentes
¿Qué problema resuelve realmente MCP que la llamada a funciones no resuelve?
- La llamada a funciones vincula una integración de modelo a un conjunto de funciones escritas a mano en una sola aplicación.
- MCP estandariza el contrato (esquemas, descubrimiento, invocación) para que el mismo servidor funcione en cualquier cliente compatible sin reescribir la integración.
¿Son las herramientas MCP lo mismo que la llamada a funciones?
Conceptualmente sí, las herramientas son el equivalente MCP de la llamada a funciones. La diferencia es que el esquema y el comportamiento de una herramienta se definen una vez en un servidor y son descubribles por cualquier cliente, en lugar de estar codificados en el código de integración de una sola aplicación.
¿Cuándo algo debería ser un Recurso en lugar de una Herramienta?
- Usa un Recurso cuando la operación sea una lectura sin efectos secundarios, como obtener un archivo, una fila de base de datos o una respuesta de API.
- Usa una Herramienta cuando el modelo necesite realizar una acción o un cálculo, incluso si esa acción también devuelve datos.
¿Qué es exactamente un Prompt en términos de MCP?
Un Prompt es una plantilla reutilizable y parametrizada que produce un conjunto de mensajes listos para enviar a un modelo. Permite a un servidor empaquetar una instrucción bien probada una vez para que cada cliente que la invoque obtenga la misma redacción consistente.
¿Necesita cada servidor MCP definir las tres primitivas?
No. Un servidor puede exponer solo herramientas, solo recursos, solo prompts, o cualquier mezcla de los tres, dependiendo de las capacidades que necesite compartir.
¿Quién inicia una lectura de recurso frente a una llamada a herramienta?
- Una llamada a herramienta es iniciada por el modelo durante una conversación, basándose en la descripción y el esquema de la herramienta.
- Una lectura de recurso puede ser iniciada por el modelo o directamente por la aplicación cliente adjuntando contexto.
¿Puede el mismo servidor MCP servir tanto a Claude Code como a una aplicación personalizada?
Sí. Ese diseño independiente del cliente es un objetivo central de MCP: una única implementación de servidor puede servir a Claude Code, Claude Desktop, Cowork y aplicaciones personalizadas del Agent SDK sin cambios.
¿Qué sucede si expongo una operación con efectos secundarios como un Recurso?
Funciona mecánicamente, pero engaña a cualquier cliente que asuma que los recursos son seguros de leer repetidamente o de almacenar en caché, ya que los recursos están destinados a representar datos legibles, no acciones con consecuencias.
¿Es un Prompt lo mismo que un prompt del sistema?
No exactamente. Un Prompt MCP es una plantilla nombrada y parametrizada que un cliente selecciona e invoca explícitamente, a menudo con argumentos, en lugar de una instrucción fija antepuesta silenciosamente a cada conversación.
¿Por qué es importante el descubrimiento para las herramientas MCP?
- El descubrimiento permite a un cliente preguntar a un servidor qué capacidades ofrece antes de usarlas.
- Sin descubrimiento, un cliente necesitaría conocimiento codificado de cada herramienta, recurso y prompt que un servidor soporta, lo que anula el propósito de un protocolo compartido.
¿Es MCP útil solo para herramientas de desarrollo local?
No. Los servidores MCP pueden ejecutarse localmente a través de stdio para herramientas locales, o remotamente a través de HTTP/SSE para servidores alojados y compartidos; el protocolo en sí no asume un estilo de implementación.
¿Cómo decido si una nueva capacidad pertenece a mi servidor MCP en absoluto?
- Pregúntate si más de un cliente o flujo de trabajo la necesitará; si es así, una primitiva MCP es una buena opción.
- Pregúntate si encaja limpiamente como una acción (Herramienta), datos legibles (Recurso) o una instrucción reutilizable (Prompt); si no encaja en ninguna de las tres, puede que no pertenezca a este servidor.
Relacionado
- Fundamentos de los Conceptos Centrales de MCP - un recorrido práctico que define una sola herramienta y conecta un cliente a través de stdio.
- Definición de Herramientas Invocables en un Servidor MCP - cómo escribir esquemas y manejadores de herramientas en profundidad.
- Exposición de Datos Legibles como Recursos MCP - cómo servir archivos, filas y respuestas de API como URIs de recursos.
- Comparación de Herramientas, Recursos y Prompts MCP - una comparación lado a lado para elegir la primitiva correcta.
- Creación de Plantillas de Prompts Reutilizables con Prompts MCP - empaquetado de prompts parametrizados para múltiples clientes.
Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y la especificación actual del Protocolo de Contexto del Modelo. Los nombres de los modelos, las versiones del SDK y la especificación MCP cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs y modelcontextprotocol.io antes de confiar en ellos.