Todo asistente de IA choca con el mismo límite: sabe mucho, pero no ve tus sistemas. No lee tu repositorio, no consulta tu base de datos, no abre un ticket en tu herramienta de soporte. Durante mucho tiempo, cada producto lo resolvió a su manera, con plugins e integraciones que solo funcionaban allí.
El Model Context Protocol (MCP) es la respuesta estándar a ese problema. Es un protocolo abierto que define cómo un asistente de IA descubre y usa herramientas y datos externos. Escribes la integración una vez, como un servidor MCP, y funciona en cualquier cliente compatible: Claude, IDE, agentes propios.
Esta guía explica cómo funciona MCP y, sobre todo, cómo usar herramientas MCP en el día a día con seguridad. Si quieres crear tu propio servidor, el artículo hermano Cómo crear un servidor MCP en Python con FastMCP lo explica paso a paso.
Las tres piezas: host, cliente y servidor
MCP separa responsabilidades en tres papeles:
- Host: la aplicación que usas, como Claude, un IDE o un agente. Contiene el modelo y decide qué mostrarte.
- Cliente MCP: el componente dentro del host que habla el protocolo. Cada cliente mantiene una conexión con un servidor.
- Servidor MCP: el programa que expone un sistema. Puede ser un servidor de GitHub, de tu base de datos o de la API de tu empresa.
Un mismo host conecta varios servidores a la vez. Eso es lo que permite a un asistente consultar el repositorio, mirar un panel de métricas y actualizar un ticket en la misma conversación.
La conversación entre cliente y servidor usa JSON-RPC sobre uno de dos transportes: stdio, cuando el servidor se ejecuta como proceso local en tu máquina, y HTTP (Streamable HTTP), cuando el servidor es un servicio remoto.
Qué ofrece un servidor
Un servidor MCP puede publicar tres tipos de cosas, y cada una tiene un "dueño" distinto:
| Pieza | Quién decide usarla | Ejemplo |
|---|---|---|
| Herramientas (tools) | el modelo | buscar_libros, crear_issue, ejecutar_consulta |
| Recursos (resources) | la aplicación | el README del proyecto, un registro, un archivo de configuración |
| Prompts | el usuario | un comando listo como "revisar este PR" |
Las herramientas son la parte que más cambia la experiencia: con ellas el asistente deja de solo responder y empieza a actuar.
Cómo ocurre una llamada a una herramienta
Cuando haces una pregunta, el flujo es este:
- El cliente pide al servidor la lista de herramientas (
tools/list). Cada una viene con nombre, descripción y un JSON Schema de sus argumentos. - El host entrega tu pregunta al modelo junto con esa lista.
- El modelo decide si alguna herramienta ayuda y arma los argumentos siguiendo el esquema.
- El cliente ejecuta la llamada en el servidor (
tools/call) y devuelve el resultado al modelo. - El modelo lee el resultado y responde, o llama a otra herramienta.
Lo importante: el modelo elige la herramienta leyendo su descripción. Una herramienta mal descrita se ignora o se usa en el momento equivocado. Y cuando la llamada falla, el servidor devuelve un resultado marcado como error, con un mensaje que el modelo lee y puede usar para corregir el siguiente intento.
Conectar un servidor MCP a Claude
En Claude Code, un comando añade un servidor:
# servidor remoto, por HTTP
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
# servidor local, por stdio (Claude arranca el proceso)
claude mcp add biblioteca -- python /ruta/a/server.py
Después, claude mcp list muestra los servidores y el estado de cada conexión, y el comando /mcp dentro de la sesión permite autenticarte o reconectar. En la app de Claude, el camino equivalente es añadir un conector en la configuración. En todos los casos la regla es la misma: el host pasa a conocer las herramientas de ese servidor.
Usar herramientas MCP en el día a día
Con el servidor conectado, no llamas a las herramientas por su nombre: describes lo que quieres. Algunos hábitos marcan la diferencia:
- Pide el resultado, no el paso. "Lista las issues abiertas con la etiqueta bug y resume las tres más antiguas" funciona mejor que "llama a list_issues".
- Da el contexto que la herramienta no tiene. Nombre del repositorio, entorno, periodo. El modelo rellena los argumentos con lo que le digas.
- Lee la petición de confirmación. Las herramientas que escriben datos suelen pedir aprobación. Revisa los argumentos antes de aprobar, sobre todo en producción.
- Usa los prompts del servidor. Cuando un servidor ofrece prompts, ya saben combinar las herramientas adecuadas para tareas comunes.
- Prefiere pocos servidores bien elegidos. Cada herramienta conectada ocupa espacio en el contexto del modelo y es una opción más para equivocarse.
Seguridad: qué revisar antes de conectar
Un servidor MCP actúa en tu nombre. Trata la conexión como tratarías entregar una llave de acceso a un sistema:
- Confía en el origen. Instala servidores de fuentes conocidas y revisa qué ejecuta un servidor local en tu máquina.
- Mínimo privilegio. Da al token del servidor solo el acceso que la tarea exige. Un servidor que solo lee no necesita permiso de escritura.
- Cuidado con el contenido externo. Una página, un correo o un documento leído por una herramienta puede contener instrucciones ocultas. El modelo no debe tratarlas como órdenes tuyas, y tú debes desconfiar cuando el asistente propone una acción que no pediste.
- Separa lectura y escritura. Deja las herramientas de escritura siempre con confirmación y revisa lo que hicieron.
- Registra y revisa. En un equipo, prefiere servidores que registran las llamadas, para saber quién hizo qué.
MCP, API y plugins: cuál es la diferencia
MCP no sustituye tu API. Es una capa fina encima de ella, pensada para modelos: describe cada operación de forma que el modelo la entienda, estandariza errores y descubrimiento, y permite que el mismo servidor funcione en cualquier host. Una API REST sigue siendo el contrato entre sistemas; el servidor MCP es el contrato entre tu sistema y un asistente.
Por dónde empezar
Conecta un servidor que resuelva un dolor real de tu rutina, como el de tu repositorio o tu sistema de tickets, úsalo una semana con las prácticas de arriba y observa dónde acierta el asistente y dónde necesita más contexto. Cuando tu empresa tenga un sistema que aún no tiene servidor, el siguiente paso es crear el tuyo: con FastMCP, en Python, lleva una tarde.
