Cargando
Cargando

MCP

Tenemos herramientas, skills y conectores. Entonces, ¿por qué existe MCP? A primera vista parece una segunda API apilada sobre la API. Es una pregunta justa — y la respuesta se reduce a quién mantiene el código de integración.

El problema del mantenimiento

Supongamos que tu agente necesita extraer tareas de Asana, revisar un Google Calendar y buscar en Slack — todo de una vez. Con herramientas personalizadas, tienes que escribir tres integraciones. Esa parte es factible. La parte dolorosa viene después: también tienes que mantener esas integraciones cada vez que uno de esos servicios cambia su API, lo cual ocurre con frecuencia. Felicidades, ahora estás manteniendo un montón de wrappers de APIs de terceros.

MCP traslada ese mantenimiento al proveedor del servicio. Asana publica un servidor MCP. Slack publica uno. Google publica uno. Cada servidor expone sus propias herramientas — con descripciones, esquemas y autenticación — a través de un protocolo estándar. Cuando su API cambia, ellos actualizan su servidor. Tú no cambias nada.

Herramientas vs. skills vs. MCP

Estas tres funciones cumplen trabajos diferentes:

  • Las herramientas conectan a Claude con tus sistemas internos — tu base de datos, tu gestor de proyectos, tus APIs propietarias. Tú eres dueño del código, así que también eres dueño del mantenimiento.
  • Las skills le enseñan a Claude un procedimiento — tu plantilla de informes, tu lista de verificación de revisión. Las skills son instrucciones, no necesariamente integraciones.
  • MCP conecta a Claude con servicios de terceros, donde el proveedor del servicio mantiene la integración. Tú no escribes el wrapper de Asana — Asana lo hizo.

La versión corta: las herramientas son para tus cosas, las skills son para tus procesos, y MCP es para las cosas de los demás.

Tarjetas comparativas para Herramientas, Skills y MCP, con la tarjeta de MCP resaltada: conecta a Claude con servicios de terceros, mantenido por el proveedor del servicio

Conectando con un servidor MCP

La forma más clara de entender MCP es apuntar a Claude hacia cualquier servidor MCP y dejar que descubra lo que hay allí. Para este ejemplo, usaremos el servidor MCP de Linear, con los detalles de conexión y el token de autenticación almacenados en un archivo .env.

Dos piezas trabajan juntas en la solicitud. La clave mcp_servers declara la conexión — un tipo, una URL, un nombre para referirse a ella y, opcionalmente, un token de autenticación. Luego, una herramienta con el tipo mcp_toolset configura qué herramientas puede usar Claude de ese servidor. El valor predeterminado es todas ellas, pero si quieres acotarlo, aquí es donde lo haces.

python
import os
import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "What tools do you have available?"}
    ],
    mcp_servers=[
        {
            "type": "url",
            "url": "https://mcp.linear.app/mcp",
            "name": "linear",
            "authorization_token": os.environ["LINEAR_MCP_TOKEN"],
        }
    ],
    tools=[
        {
            "type": "mcp_toolset",
            "mcp_server_name": "linear",
        }
    ],
    betas=["mcp-client-2025-11-20"],
)

print(response)

Observa que nunca escribimos un solo esquema de herramienta. Claude inspecciona el servidor, obtiene la lista de herramientas y sus esquemas, y elige la correcta para el prompt. Al momento de esta lección, el conector MCP está en beta — nota el encabezado beta en la solicitud.

Ejecútalo, y si tu URL de MCP apunta al endpoint MCP de Linear, Claude lista las herramientas de Linear y luego llama a una. Lo mismo funciona para prácticamente cualquier servidor compatible. No definimos ni una sola herramienta. No escribimos un cliente de Linear. Linear se encarga de eso.

Salida de terminal que lista las herramientas descubiertas del servidor MCP de Linear, seguida de Claude señalando que son herramientas de gestión de proyectos de Linear y eligiendo cuál llamar

Filtrando qué herramientas puede usar Claude

Los servidores MCP a menudo exponen muchísimas herramientas — y no siempre quieres que Claude las use todas. Tal vez no quieres que tenga permisos de escritura, o simplemente no quieres que todas esas definiciones de herramientas ocupen contexto.

La solución: deshabilitar todo por defecto, y luego habilitar solo las herramientas específicas que quieras. Aquí está ese patrón con un servidor MCP de Slack:

python
tools=[
    {
        "type": "mcp_toolset",
        "mcp_server_name": "slack",
        "default_config": {
            "enabled": False,
        },
        "configs": {
            "search_messages": {"enabled": True},
            "list_channels": {"enabled": True},
        },
    }
]

Ahora Claude puede buscar en Slack y listar canales, pero no puede publicar ni eliminar. Esto es útil cuando confías en un servicio para lecturas pero no quieres que Claude escriba en tu nombre por accidente.

Resumen

  • MCP existe para que no tengas que mantener integraciones que alguien más ya construyó. El proveedor del servicio publica un servidor MCP y lo mantiene actualizado — tú no cambias nada cuando su API cambia.
  • Elige la función correcta para el trabajo: herramientas para tus datos, skills para tu proceso, MCP para servicios de terceros.
  • Declara la conexión en mcp_servers (tipo, URL, nombre, token de autenticación opcional) y otorga acceso con una entrada mcp_toolset en tools. Claude inspecciona el servidor y descubre las herramientas por sí mismo — sin esquemas que escribir.
  • Acota el acceso configurando default_config: {"enabled": False} y habilitando herramientas específicas en configs — útil para mantener un servidor de solo lectura.
  • El conector MCP está actualmente en beta, así que incluye el encabezado beta en tus solicitudes.
  • Visita modelcontextprotocol.io para ver la lista de servidores disponibles y aprender más sobre el protocolo.