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.
//
Busca en todas las páginas de la documentación
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.
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.
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.
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.
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.
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.
No. Un servidor puede exponer solo herramientas, solo recursos, solo prompts, o cualquier mezcla de los tres, dependiendo de las capacidades que necesite compartir.
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.
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.
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.
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.
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.
Revisado por Chris St. John·Última actualización: 16 jul 2026