MCPs 01

Introducción

Hay varias maneras de mejorar las habilidades de un agente mediante herramientas que permiten extender su capacidad de fábrica, como los skills, los plugins o los mcps. En este post vamos a ver cómo funcionan los mcps y cuáles son sus limitaciones y en el siguiente cómo preparar uno.

MCP, acrónimo de Model Context Protocol, es una fórmula para estandarizar la manera en que los agentes -como Claude- se conectan con el mundo exterior. Dicho de otra manera, es un protocolo estándar y abierto que permite a los modelos de IA conectarse con herramientas y fuentes de datos externas de forma universal.

La analogía más usada es el USB-C: antes de USB-C cada dispositivo tenía su propio conector. MCP hace lo mismo para la IA: en lugar de construir una integración personalizada para cada herramienta, construyes contra un único protocolo y funciona con todo.

La propuesta inicial fue lanzada, una vez más, por Anthropic en noviembre de 2024 y no tardó en adoptarse por todos los grandes del sector. OpenAI lo integró en su Agents SDK y ChatGPT en marzo de 2025, Google DeepMind anunció soporte en Gemini poco después, y hoy está presente en prácticamente cualquier herramienta de desarrollo relevante: VS Code, Cursor, GitHub, Figma, y un ecosistema de miles de servidores construidos por la comunidad.

Cómo funciona por dentro

MCP sigue una arquitectura cliente-servidor clásica. El servidor MCP es el que expone las capacidades -herramientas, datos, plantillas- y el cliente MCP es el agente o IDE que las consume. Entre los dos hay un protocolo de mensajería basado en JSON-RPC 2.0, un protocolo de mensajería ligero que define cómo se estructuran las llamadas entre cliente y servidor: cada mensaje tiene un método, unos parámetros y un identificador que permite emparejar cada petición con su respuesta.

https://www.jsonrpc.org/specification

En nuestro caso, un mensaje JSON-RPC tiene esta pinta:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": { "name": "get_figma_data", "arguments": { "url": "..." } },
  "id": 1
}

Y la respuesta:

{
  "jsonrpc": "2.0",
  "result": { "data": "..." },
  "id": 1
}

Cuando cliente y servidor se conectan, lo primero que ocurre es un handshake: se presentan, negocian la versión del protocolo y acuerdan qué capacidades ofrece cada parte. A partir de ahí ya pueden trabajar.

Un servidor MCP puede exponer tres tipos de recursos:

• Tools: funciones que el agente puede invocar, como consultar una base de datos o crear un archivo en Figma. Son el tipo más común.
• Resources: datos que el agente puede leer, como el contenido de un archivo o una URL.
• Prompts: plantillas de instrucciones reutilizables que el servidor pone a disposición del cliente.

Cuando el agente recibe la lista de tools disponibles, no las carga todas en contexto de golpe — eso sería muy costoso en tokens. En cambio, busca las relevantes según la tarea que tiene entre manos y solo entonces las invoca. El agente decide qué tool usar basándose en las descripciones que el servidor proporciona, por lo que escribir buenas descripciones es tan importante como la implementación en sí.

En cuanto al transporte, hay tres opciones: HTTP para servidores remotos (la opción recomendada hoy en día), SSE (Server-Sent Events, deprecado), y stdio para procesos locales que corren en tu propia máquina.

Para ver cómo funciona en la práctica vamos a instalar el mcp de Figma, una herramienta de diseño colaborativo, a la que no sé qué recorrido le queda después de Claude Design y Stitch, pero que hoy en día está muy extendida en el mundo del software.

Instalación

Un mcp se puede utilizar con cualquier agente, pero para este mini tutorial vamos con Claude Code, que es el más potente. Hay varias formas de instalar Claude Code en función de tu SO. En el caso de que no lo tengas instalado, puedes consultar la documentación oficial está en code.claude.com/docs/en/quickstart. Los comandos varían según tu sistema operativo y terminal:

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

macOS, Linux o WSL:

curl -fsSL https://claude.ai/install.sh | bash

Una vez instalado, abre una nueva terminal y verifica que funciona:

claude --help

Claude Code permite instalar servidores MCP en tres ámbitos distintos:

1. local (por defecto), se guarda en ~/.claude.json asociado a un proyecto y solo tú tienes acceso en ese proyecto.
2. project, se guarda en .mcp.json en la raíz del proyecto y todo el equipo tiene acceso via control de versiones
3. user, se guarda en ~/.claude.json y lo tienes solo tú en todos tus proyectos.

Además, hay que tener en cuenta que hay tres tipos de servidor según cómo se conectan:

1. HTTP: la más habitual, servidor remoto, es la opción recomendada hoy en día.
2. SSE: servidor remoto vía Server-Sent Events, está obsoleto.
3. stdio: proceso local que corre en tu propia máquina.

El comando base es:

# Servidor remoto HTTP
claude mcp add --transport http <nombre> <url>

# Servidor local stdio
claude mcp add <nombre> -- <comando> [args...]

Para especificar el ámbito:

claude mcp add --scope project --transport http <nombre> <url>

Para gestionar los servidores instalados

# Ver todos los servidores configurados
claude mcp list

# Ver detalles de uno concreto
claude mcp get <nombre>

# Eliminar un servidor
claude mcp remove <nombre>

Dentro de Claude Code, puedes consultar el estado en cualquier momento con:

/mcp

MCP Figma

Para instalarlo en el proyecto, como hemos visto, sería así:

Local, desde el directorio del proyecto, ejecuta:

claude mcp add figma https://mcp.figma.com/mcp --scope local --transport http 

Esto añade el servidor al archivo .mcp.json del proyecto local con algo así:

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Luego, abre Claude Code en la terminal:

claude

Te saldrá algo así. Selecciona la primera opción.

  MCP servers may execute code or access system resources. All tool calls require approval. Learn more in the MCP documentation.

  ❯ 1. Use this and all future MCP servers in this project
    2. Use this MCP server
    3. Continue without using this MCP server

Luego escribe /mcp, selecciona figma con las flechas y pulsa Enter. Se abrirá el navegador con el flujo OAuth de Figma. Inicia sesión con tu cuenta.

Cuando veas en la terminal:

Authentication successful. Connected to figma.

Ya está listo.

Si escribimos por consola

¿Qué tools de Figma tienes disponibles?

Nos debería salir un listado con todo lo que puede manejar ahora el agente

  Lectura de diseños
  - get_design_context — contexto completo de un nodo (código, screenshot, hints)
  - get_screenshot — captura visual de un componente/frame
  - get_metadata — metadatos del archivo
  - get_figjam — contenido de boards FigJam
  - get_variable_defs — definiciones de variables/tokens
  - get_libraries — librerías conectadas al archivo

  Búsqueda y sistema de diseño
  - search_design_system — buscar componentes en el design system
  - create_design_system_rules — crear reglas del design system

  Code Connect (mapeo Figma ↔ código)
  - get_code_connect_map — ver mapeos existentes
  - get_code_connect_suggestions — sugerencias automáticas
  - get_context_for_code_connect — contexto para un componente
  - add_code_connect_map — añadir mapeo
  - send_code_connect_mappings — publicar mapeos a Figma

  Creación
  - generate_figma_design — generar diseño en Figma
  - generate_diagram — crear diagrama en FigJam
  - create_new_file — crear archivo nuevo
  - use_figma — uso general/captura web a Figma

  Otros
  - whoami — info del usuario autenticado

Así, por ejemplo, podríamos extraer variables, componentes y layout directamente en el IDE, generar código a partir de frames seleccionados y mantener consistencia con el design system usando Code Connect, etcétera. Por ejemplo, así podríamos decirle que utilice un diseño como referencia para una web

Implementa una página web con este diseño:
https://www.figma.com/design/patatas/my-figma

Eso sí, OJO CUIDAO. Este mcp consume tokens como si no hubiera un mañana. Si no tienes una tarifa empresarial plana, es muy probable que no te compense.

Para ampliar información y entender bien todas las posibilidades, lo mejor es ir a la documentación oficial.

Limitaciones y problemas de los MCP

Desde finales de 2024, los MCPs se han considerado una pieza fundamental dentro de la ingeniería agéntica. Sin embargo, en los últimos tiempos han surgido herramientas más adecuadas para ciertos escenarios, como veremos al hablar de las skills. Y es que los MCPs presentan tres grandes problemas.

1. Sobrecarga de contexto

Cuando conectas un servidor MCP, carga todos sus schemas de tools en el contexto al arrancar la sesión, aunque nunca uses la mayoría. El GitHub MCP tiene 43 tools. El de Atlassian tiene 73. Multiplica eso por varios servidores y antes de escribir una sola línea de código ya has quemado una parte considerable de la ventana de contexto. Como veremos, las skills resuelven esto con progressive disclosure: al arrancar solo se carga el nombre y una línea de descripción de cada skill. El contenido completo solo se carga cuando es relevante. Y esto repercute en:

• la economía del token, uno de los puntos de fuga de cualquier propuesta de desarrollo con agentes, en tanto que los costes serán probablemente mayores.
• no ocupar el contexto con información que no es relevante para el proyecto, aunque esto quizás importe cada vez menos, en tanto que los contextos serán cada vez más grandes.

2. Las tools MCP son pasivas

Un servidor MCP expone funciones atómicas: get_issue, create_pr, query_db. El agente tiene que orquestar él solo cómo encadenarlas, manejar errores, decidir qué hacer si falla el paso 2 de 5.

Un Skill puede codificar todo ese workflow directamente: “cuando el usuario pida revisar un PR, primero haz X, luego Y, si falla Z haz W”. La lógica vive en el Skill, no en la cabeza del agente en cada sesión.

3. Los servidores MCP no tienen acceso al LLM

Si una tool necesita juicio -por ejemplo, filtrar 50 resultados de búsqueda por relevancia- el servidor MCP no puede usar el LLM del agente para hacerlo. Tendría que montar su propio modelo con su propia API key, su propio coste, su propia latencia.

Una skill o un subagente sí tienen acceso al LLM. Pueden razonar, filtrar, decidir, dentro del mismo contexto.

Algunas referencias al respecto:

• “MCP is dead. Long live the CLI”, blog personal de Eric Holmes, febrero 2026.

• “When does MCP make sense vs CLI?”, marzo 2026. Un hilo de Hacker News donde se debate esta cuestión.

• “Is MCP Dead? MCP vs CLI vs Agent Skills Compared”. Cheney Zhang, Milvus, abril 2026. Incluye datos de benchmarks reales.

• “MCP is Dead; Long Live MCP!”. Or Weis, Permit.io, marzo 2026.

Volveremos sobre esto más adelante y veremos en qué escenario conviene usar una herramienta u otra. De momento, vamos a dejarlo aquí.

Antes de terminar, sin embargo, un aviso muy importante: los mcps son como cualquier otro elemento externo que incorpores a un proyecto, algunos están muy bien y otros son peligrosos. Fíjate siempre en quién lo ha preparado, si es un desarrollo oficial de una compañía (microsoft, confluence, whatever) o de un grupo de corea del norte al servicio del mal.