Published in: agentes de ia

Model Context Protocol (MCP): guía técnica 2026

Author Diego Parada

Published on: 5 de junio de 2026

En noviembre de 2024, Anthropic publicó la especificación del Model Context Protocol (MCP). En menos de seis meses, OpenAI lo adoptó en su Agents SDK, Microsoft lo integró en Copilot Studio y decenas de editores de código empezaron a soportarlo de forma nativa. Si construyes agentes IA en 2026 y no entiendes qué es MCP, cómo funciona su protocolo y por qué importa, vas tarde.

Esta guía técnica cubre MCP desde los fundamentos del protocolo hasta código funcional. Primero verás la arquitectura Host-Client-Server, luego las tres primitivas (resources, tools y prompts), después el ciclo de vida de la negociación JSON-RPC 2.0, y finalmente cómo construir un servidor MCP en Python y desplegarlo. También incluimos un caso real: el plugin elementor-mcp-api que mantenemos en producción en Baigency como parte de nuestros desarrollos de agentes de IA para empresas, y que expone 20 abilities MCP para editar páginas WordPress desde cualquier cliente LLM.

El objetivo no es un survey superficial. Cada sección da respuesta concreta a una pregunta técnica específica, con código ejecutable y referencias a la especificación oficial.

¿Qué es Model Context Protocol (MCP)?

Model Context Protocol es un protocolo abierto que estandariza la forma en que aplicaciones de IA se comunican con fuentes de datos y herramientas externas. Antes de MCP, integrar un LLM con un sistema externo —una base de datos, una API de negocio, un sistema de archivos— requería escribir una integración ad-hoc para cada par (modelo, herramienta). Con MCP, cualquier cliente que entienda el protocolo puede hablar con cualquier servidor que lo implemente, sin código de glue específico.

Anthropic lo describe con una analogía que se ha vuelto la referencia del ecosistema:

«MCP is like a USB-C port for AI applications — a universal connector that lets any AI model plug into any data source or tool.»

— Anthropic, anuncio oficial MCP, noviembre 2024

El problema que resuelve es clásico en ingeniería de sistemas: el problema M×N. Si tienes M modelos de IA y N herramientas externas, sin estándar necesitas M×N integraciones. Con MCP, cada herramienta escribe un servidor una sola vez y cada modelo escribe un cliente una sola vez: el total es M+N. Este patrón se aplica a cualquier arquitectura agéntica, independientemente del tipo de agente de IA que estés construyendo.

Quién lo creó y quién lo soporta

Anthropic diseñó MCP y publicó la especificación completa en GitHub (modelcontextprotocol/specification) bajo licencia abierta. La especificación define el protocolo de transporte, el formato de mensajes y las primitivas. El soporte inicial llegó con Claude Desktop. Desde entonces se han sumado Cursor, Zed, Continue.dev, y en Q1 2025 OpenAI adoptó MCP en su Agents SDK de Python. La adopción cross-vendor convierte MCP en el primer estándar de facto para conectar LLMs con herramientas externas.

MCP vs function calling vanilla

Function calling (el mecanismo nativo de OpenAI, Google y Anthropic) permite al modelo invocar funciones definidas en el prompt del sistema. La diferencia fundamental con MCP es el descubrimiento dinámico: en function calling, las herramientas disponibles van hardcoded en cada request. En MCP, el cliente pregunta al servidor qué tools y resources ofrece en tiempo de ejecución, y el servidor puede cambiarlas sin que el cliente lo sepa de antemano. Esto permite architecturas donde el conjunto de herramientas evoluciona sin redeployar el cliente.

Arquitectura: Host, Client, Server

MCP define tres capas con responsabilidades claramente separadas: el host, el client y el server. Esta separación es deliberada —permite que cada capa evolucione de forma independiente y que el modelo no tenga conocimiento directo de los sistemas de backend.

┌──────────────────────┐     1:N      ┌──────────────────┐     1:1      ┌──────────────────┐
│        Host          │ ───────────▶ │     Client       │ ───────────▶ │     Server       │
│  (Claude Desktop,    │              │  (por servidor,  │   stdio/SSE  │  (tu negocio,    │
│   Cursor, tu app)    │              │   dentro del     │   HTTP       │   tu DB, tu API) │
└──────────────────────┘              │   host)          │              └──────────────────┘
                                      └──────────────────┘

El Host

El host es la aplicación que el usuario utiliza directamente: Claude Desktop, Cursor, Zed, o cualquier aplicación propia que integres. El host orquesta la conversación con el LLM y gestiona el ciclo de vida de los clients MCP. Es responsable de presentar al usuario las confirmaciones cuando un server solicita ejecutar una acción con side effects. Un host puede conectarse simultáneamente con múltiples servers, y mantiene un client separado por cada conexión. El host también decide qué información del contexto MCP inyectar al modelo en cada turno de conversación.

El Client

El client es el componente interno del host que habla el protocolo MCP con un server concreto. Hay exactamente un client por server conectado. El client negocia las capacidades con el server durante la inicialización, descubre las primitivas disponibles (tools, resources, prompts), y traduce las solicitudes del LLM a mensajes JSON-RPC 2.0. El client no tiene estado de conversación propio: su función es exclusivamente protocolar. Si el host se conecta con tres servers distintos, instancia tres clients independientes.

El Server

El server es un proceso externo que expone capabilities al client. Puede ejecutarse localmente en el mismo equipo (comunicación por stdio) o de forma remota (comunicación por HTTP+SSE o Streamable HTTP). El server no sabe nada del modelo que está detrás del client: solo recibe mensajes JSON-RPC y devuelve respuestas. Esta separación es crítica para la seguridad: el server opera con sus propios permisos y credenciales, completamente aislado del LLM. Un mismo server puede atender múltiples clients simultáneos si el transport lo permite.

Transport layer

MCP define tres mecanismos de transporte. stdio (lectura/escritura estándar) es el más simple: el host lanza el server como subproceso y se comunica por pipes. Es el estándar para servers locales y la opción más segura para datos sensibles. HTTP + Server-Sent Events (SSE) permite servers remotos: el client hace POST para enviar mensajes y el server responde con un stream SSE. Streamable HTTP es la variante más nueva (2025), que unifica el canal en un único endpoint HTTP bidireccional con soporte de streaming. Los mensajes van siempre serializados como JSON-RPC 2.0.

Las primitivas: Resources, Tools, Prompts

MCP estandariza tres tipos de primitivas que un server puede exponer. Cada una tiene semántica diferente en cuanto a quién las consume, si tienen side effects, y cuándo usarlas. Entender estas diferencias evita diseños incorrectos. En la práctica, la mayoría de los ejemplos de agentes de IA en producción combinan los tres tipos.

Resources

Resources son datos que el server pone a disposición del LLM para lectura. No ejecutan acciones: devuelven contenido. Un resource puede ser un archivo, un registro de base de datos, una respuesta de API externa, o cualquier dato que el modelo necesite como contexto. El server los expone con un URI propio (por ejemplo, file:///etc/config.json o db://clientes/123). El client puede pedirlos con resources/list para descubrir qué hay disponible, y luego con resources/read para obtener el contenido. Los resources pueden ser estáticos o dinámicos: el server puede notificar al client cuando cambian mediante el mecanismo de subscriptions definido en la spec.

Tools

Tools son acciones que el LLM puede invocar. Son el equivalente a function calling, pero con discovery dinámico y schema JSON Schema para cada herramienta. Cada tool tiene un nombre, una descripción en lenguaje natural (que el modelo usa para decidir cuándo llamarla), y un inputSchema en JSON Schema que especifica los parámetros. Cuando el modelo decide invocar una tool, el client envía un mensaje tools/call al server con los parámetros. El server ejecuta la acción y devuelve el resultado. Los hosts como Claude Desktop presentan una confirmación al usuario antes de ejecutar tools con el annotation destructive: true.

Prompts

Prompts son templates de mensajes reutilizables que el server registra y el usuario puede invocar desde la interfaz del host. No son instrucciones del sistema globales: son fragmentos de conversación estructurados, con argumentos opcionales, que el servidor puede generar dinámicamente. Un editor de código podría exponer un prompt /explain-error que reciba como argumento el mensaje de error y genere automáticamente el contexto adecuado para que el modelo lo analice. Los prompts permiten que el server encapsule patrones de uso complejos y los ponga accesibles al usuario sin que este tenga que escribirlos.

Cómo funciona la negociación protocolo paso a paso

Toda conexión MCP sigue un ciclo de vida definido por la especificación. El punto de entrada es la fase initialize, donde client y server negocian versión del protocolo y capabilities. Si la negociación falla, la conexión se termina. Solo tras un initialized exitoso puede el client empezar a usar tools, resources o prompts.

El mensaje initialize en JSON-RPC 2.0 tiene esta forma real, según la spec técnica de MCP:

// Request del client al server
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ClaudeDesktop",
      "version": "1.0.0"
    }
  }
}

// Response del server
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "prompts": { "listChanged": false }
    },
    "serverInfo": {
      "name": "mi-servidor-mcp",
      "version": "0.1.0"
    }
  }
}

// El client confirma que recibió el initialize (notificación, sin respuesta esperada)
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Discovery dinámico de capabilities

Una vez inicializado, el client puede pedir en cualquier momento la lista de primitivas disponibles usando tools/list, resources/list o prompts/list. Si el server declaró listChanged: true en el initialize, también puede enviar notificaciones proactivas al client cuando la lista cambie —por ejemplo, cuando se instala un nuevo plugin en el backend y aparecen nuevas tools. Este mecanismo de discovery dinámico es lo que diferencia MCP de function calling hardcoded: el conjunto de capacidades puede cambiar en tiempo de ejecución sin tocar el cliente.

Ciclo de vida completo

El ciclo de vida de una sesión MCP sigue esta secuencia: initialize (negociación de versión y capabilities), initialized (confirmación del client), uso normal (tools/call, resources/read, etc.), y finalmente shutdown cuando el host decide cerrar la conexión. La spec define que el client debe enviar una notificación de cierre antes de terminar el proceso del server, especialmente en transport stdio donde el server es un subproceso del host.

Construir tu primer servidor MCP en Python

El SDK oficial de Python para MCP se instala como paquete mcp. El módulo principal para construir servers es mcp.server.fastmcp, que expone una API con decoradores similar a FastAPI. A continuación el ejemplo completo, ejecutable con Python 3.10+.

Setup

Instala las dependencias con uv (recomendado por la documentación oficial) o con pip estándar.

# Con uv (recomendado)
uv init mi-servidor-mcp
cd mi-servidor-mcp
uv add mcp

# Con pip
pip install mcp

Hello world: tool + resource

Este servidor expone una tool add que suma dos enteros, y un resource system://time que devuelve la hora del sistema. Es el caso mínimo funcional que cubre las dos primitivas de uso más frecuente:

"""
mi_servidor.py — Servidor MCP mínimo con una tool y un resource.
Requiere: mcp >= 1.0.0
"""

from datetime import datetime
from mcp.server.fastmcp import FastMCP

# Instanciar el servidor con un nombre descriptivo
server = FastMCP("mi-servidor-ejemplo")


@server.tool()
def add(a: int, b: int) -> int:
    """
    Suma dos enteros y devuelve el resultado.
    Úsala cuando el usuario pida sumar números.
    """
    return a + b


@server.resource("system://time")
def system_time() -> str:
    """
    Devuelve la fecha y hora actuales del servidor en formato ISO 8601.
    Útil cuando el agente necesita saber la hora del sistema.
    """
    return datetime.now().isoformat()


if __name__ == "__main__":
    # transport="stdio" es el default para uso local con Claude Desktop
    server.run(transport="stdio")

El decorador @server.tool() registra la función como una MCP tool. FastMCP infiere automáticamente el inputSchema JSON Schema a partir de las type annotations de Python. La docstring se usa como campo description que el LLM lee para decidir cuándo invocar la tool. El decorador @server.resource() registra el resource con el URI especificado.

Conectar con Claude Desktop

Para que Claude Desktop cargue tu server al arrancar, edita el archivo claude_desktop_config.json (en ~/Library/Application Support/Claude/ en macOS, o el equivalente en Windows):

{
  "mcpServers": {
    "mi-servidor-ejemplo": {
      "command": "python",
      "args": ["/ruta/absoluta/a/mi_servidor.py"],
      "env": {
        "PYTHONPATH": "/ruta/absoluta/a/mi_servidor"
      }
    }
  }
}

Si usas uv, puedes especificar "command": "uv" y "args": ["run", "mi_servidor.py"] para que uv gestione el entorno virtual automáticamente. Reinicia Claude Desktop tras modificar el archivo. Si el server arranca correctamente, aparecerá un icono de herramientas en el input de Claude Desktop con las tools disponibles.

Debugging con mcp dev

El paquete MCP incluye un CLI de desarrollo que lanza el server y muestra todos los mensajes JSON-RPC en tiempo real. Es la forma más rápida de verificar que el protocolo funciona antes de conectar un host real:

mcp dev mi_servidor.py

El CLI abre el MCP Inspector en el navegador, donde puedes llamar manualmente a cada tool y resource, ver el JSON de request y response, y verificar que los schemas son correctos. Si ves un error en el initialize, revisa primero la versión del SDK y que el transport sea stdio.

Con este patrón básico ya puedes construir servers MCP que conectan cualquier LLM con la lógica de tu negocio. En la práctica, los agentes de IA que desplegamos en producción combinan varios servers de este tipo, cada uno responsable de un dominio acotado.

Caso real: MCP para WordPress en producción

En Baigency desarrollamos elementor-mcp-api, un plugin WordPress de código abierto que expone 20 abilities MCP para editar páginas Elementor de forma programática desde cualquier cliente LLM. El plugin lo usamos en producción para generar y publicar landings a escala —el caso concreto es automatizar la creación de más de 100 páginas programáticas sin intervención manual en el editor visual.

Arquitectura del plugin

El plugin sigue un patrón de tres capas. La capa inferior son los endpoints REST de WordPress (/wp-json/neoservice/v1/), que operan directamente sobre el árbol de datos de Elementor almacenado en post_meta. La capa intermedia es el WordPress Abilities API, que permite registrar abilities tipadas con input/output schema en JSON Schema. La capa superior es el WordPress MCP Adapter, que traduce esas abilities al protocolo MCP estándar y las expone en el endpoint /wp-json/mcp/mcp-adapter-default-server. Cualquier cliente MCP —Claude Desktop, Cursor, un agente Python propio— puede conectarse a ese endpoint y obtener acceso completo a la edición de páginas.

Código real: ability update-element

Este es el código exacto del archivo includes/class-abilities-provider.php del plugin. La ability neoservice/update-element permite actualizar los settings de cualquier widget Elementor conociendo solo el ID del elemento:

wp_register_ability('neoservice/update-element', [
    'label'       => 'Update Element Settings',
    'description' => 'Update the settings of a specific Elementor element by its ID.
                      Merges new settings with existing ones.
                      Use get-page-structure first to find element IDs.',
    'category'    => 'neoservice-elementor',
    'input_schema' => [
        'type'       => 'object',
        'required'   => ['post_id', 'element_id', 'settings'],
        'properties' => [
            'post_id' => [
                'type'        => 'integer',
                'description' => 'The WordPress page/post ID.',
            ],
            'element_id' => [
                'type'        => 'string',
                'description' => 'The Elementor element ID (8-char hex string).',
            ],
            'settings' => [
                'type'        => 'object',
                'description' => 'Settings to merge into the element.
                                  Use get-widget-schema to see available settings.',
            ],
        ],
        'additionalProperties' => false,
    ],
    'execute_callback' => function ($input) {
        $post_id = (int) $input['post_id'];
        $data    = Elementor_Data::get_page_data($post_id);
        if (!$data) return new \WP_Error('not_found', 'Page not found.');

        $ok = Elementor_Data::update_element_settings(
            $data,
            $input['element_id'],
            $input['settings']
        );
        if (!$ok) return new \WP_Error('not_found', 'Element not found.');

        Elementor_Data::save_page_data($post_id, $data);
        return ['success' => true, 'element_id' => $input['element_id']];
    },
    'permission_callback' => [self::class, 'can_edit'],
    'meta' => self::meta_write(),
]);

El patrón es idéntico al de cualquier MCP server: un nombre único, un input schema JSON Schema, una execute_callback que es la lógica real, y un permission_callback que valida que el usuario autenticado tiene permisos. La diferencia con un servidor Python es solo el runtime y el helper wp_register_ability() que hace el registro en el sistema de abilities de WordPress.

Lecciones aprendidas en producción

Tres problemas frecuentes al operar un MCP server sobre WordPress. Primero: idempotencia. Las tools de escritura deben ser idempotentes cuando sea posible; si el agente reintenta por timeout, la segunda llamada no debe romper el estado. El mismo patrón aplica cuando el agente integra otros canales conversacionales, como un chatbot de IA para WhatsApp que invoca tools del backend para responder al usuario. Segundo: CSS cache. Elementor cachea el CSS agresivamente; tras cualquier modificación de elemento, el server debe llamar a flush-css o el cambio no será visible. Tercero: llamadas secuenciales. No lanzar múltiples PATCH en paralelo sobre la misma página: cada llamada carga, modifica y guarda el árbol completo, y las llamadas paralelas se sobreescriben entre sí. Si necesitas editar una landing con agentes de IA para empresas, secuencializar las operaciones sobre la misma página es crítico.

MCP vs alternativas: function calling, ChatGPT plugins, LangChain Tools

El ecosistema tiene varias formas de conectar LLMs con herramientas externas. La tabla siguiente compara las características técnicas más relevantes para decidir cuándo usar cada una.

MCP y los modelos generativos modernos

Aunque MCP es agnóstico al modelo, su mayor valor aparece cuando se combina con agentes de IA generativa que necesitan acceder a contexto externo en tiempo real. La separación cliente-servidor permite que el mismo backend de herramientas alimente a Claude, GPT-4o, Gemini o cualquier modelo futuro sin reescritura.

Cuándo no usar MCP

MCP añade complejidad de protocolo que no siempre está justificada. Si solo necesitas conectar un LLM con una función interna dentro del mismo proceso y no planeas reusar ese código con otros modelos, function calling vanilla es más simple. MCP es la elección correcta cuando: (a) el server necesita funcionar con múltiples clientes LLM distintos, (b) el conjunto de tools puede cambiar en tiempo de ejecución, (c) necesitas separar el proceso del modelo del proceso del backend por razones de seguridad o escalado, o (d) quieres que el servidor sea reutilizable en el ecosistema de herramientas estándar del registry oficial de MCP servers.

Seguridad y consideraciones de producción

MCP traslada capacidades reales de ejecución a agentes LLM. Un diseño de seguridad descuidado puede convertir un server MCP en una superficie de ataque seria. Las consideraciones siguientes no son opcionales para entornos de producción.

Autenticación por tipo de transport

En transport stdio, el server es un subproceso lanzado por el host. La autenticación no es necesaria en el protocolo MCP porque el acceso al proceso ya implica acceso al sistema operativo del usuario. La seguridad la provee el OS. En transport HTTP remoto, la especificación recomienda OAuth 2.0. El server debe verificar el token en cada request antes de ejecutar cualquier tool. No implementar autenticación en un MCP server HTTP remoto es equivalente a exponer una API pública sin auth.

Secretos y variables de entorno

No hardcodear credenciales en el código del server. Los secretos van en variables de entorno, que el host puede inyectar en el proceso del server a través de la clave env del bloque de configuración en claude_desktop_config.json. En producción, usar un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) en lugar de archivos .env. El archivo .env nunca debe commitearse al repositorio.

Permission model y consentimiento del usuario

La especificación MCP define el campo annotations en cada tool para declarar si tiene side effects (destructive: true) o si es idempotente. Los hosts como Claude Desktop usan estas annotations para decidir si mostrar una confirmación al usuario antes de ejecutar. Implementa siempre annotations correctas: una tool que escribe en base de datos debe declararse como destructive aunque sea una escritura controlada. El consentimiento explícito del usuario es parte del modelo de seguridad del ecosistema MCP.

Sandboxing y logging

Ejecuta los MCP servers con el mínimo de privilegios necesarios. En Linux, considera seccomp o ejecutar el server en un contenedor sin red si solo necesita acceso local. El logging de todas las llamadas a tools —request, parámetros, resultado, timestamp, usuario— es imprescindible para auditoría. En producción, la observabilidad de un MCP server debe ser equivalente a la de cualquier microservicio: trazas, métricas y logs estructurados.

Ecosistema MCP en 2026: clientes, servidores y frameworks

El ecosistema ha crecido de forma significativa desde el lanzamiento en noviembre de 2024. La adopción cross-vendor es el indicador más relevante de que MCP se está consolidando como estándar. Para ver el estado del mercado de agentes de IA en 2026 más allá del protocolo MCP, hemos publicado un análisis dedicado.

Clientes que soportan MCP de forma nativa

• Claude Desktop — referencia de la implementación original de Anthropic.
• Cursor — editor de código con soporte MCP desde principios de 2025; permite conectar servers de contexto de código.
• Zed — editor con integración MCP para asistentes de código.
• Continue.dev — extensión VS Code/JetBrains con soporte MCP para contexto de repositorio.
• OpenAI Agents SDK (Python) — adoptó MCP en Q1 2025; permite usar cualquier MCP server como tool source para agentes GPT-4o.

Servers populares en el registry oficial

El registry oficial de MCP servers incluye implementaciones de referencia para los casos de uso más comunes: GitHub (operaciones de repositorio), Slack (mensajería), PostgreSQL (consultas SQL), Brave Search (búsqueda web), Puppeteer (automatización de browser), y sistemas de archivos locales. Son el punto de partida recomendado antes de construir un server propio para un caso estándar.

Frameworks que envuelven MCP

Para equipos que vienen del mundo de las automatizaciones con IA de bajo código (n8n, Make, Zapier), los frameworks que envuelven MCP ofrecen el siguiente nivel de control. LangGraph incorpora un adapter MCP que permite usar cualquier MCP server como tool node en un grafo de agentes. El sitio oficial de documentación MCP mantiene una lista actualizada de SDKs en Python, TypeScript, Go, Rust y Kotlin. Si construyes un agentes de IA sobre estos frameworks, la integración MCP reduce el tiempo de implementación de herramientas externas de semanas a horas.

Preguntas frecuentes sobre Model Context Protocol

¿MCP reemplaza a function calling?

No. MCP y function calling son complementarios. Function calling es el mecanismo del modelo para invocar herramientas definidas en el prompt; MCP es el protocolo que estandariza cómo un client descubre y llama a esas herramientas en un server externo. En la práctica, cuando un cliente MCP invoca una tool del servidor, el host traduce esa invocación al mecanismo de function calling nativo del modelo. MCP no elimina function calling; estandariza la capa por encima de él para que el cliente y el servidor puedan ser independientes.

¿Funciona MCP con GPT-4 / Gemini o solo con Claude?

MCP funciona con cualquier LLM cuyo host soporte el protocolo. OpenAI adoptó MCP en su Agents SDK de Python en Q1 2025, lo que significa que los agentes GPT-4o pueden usar cualquier MCP server como fuente de tools. Google no ha anunciado soporte nativo oficial en Gemini API a fecha de este artículo, pero los frameworks de terceros como LangGraph permiten bridging. La ventaja de MCP como estándar abierto es exactamente esta: un server escrito una vez funciona con múltiples modelos, sin reescritura.

¿Qué diferencia hay entre un servidor MCP local (stdio) y uno remoto (SSE/HTTP)?

La diferencia es el modelo de comunicación y las implicaciones de seguridad. Un server stdio local es un subproceso del host: se lanza en la misma máquina, hereda el entorno del usuario, y se comunica por pipes estándar. No hay red implicada. Un server HTTP/SSE remoto es un proceso independiente —en otro host, en la nube— accesible vía URL. Requiere autenticación explícita (OAuth 2.0 según la spec), expone una superficie de red, y puede ser compartido por múltiples usuarios. Elige stdio para datos sensibles en local; HTTP para servers compartidos o cloud.

¿MCP es seguro para producción con datos sensibles?

MCP en sí no define controles de seguridad: eso es responsabilidad del implementador. Para datos sensibles en producción, los requisitos mínimos son: transport stdio si el server es local (sin exposición de red), OAuth 2.0 si el server es remoto, variables de entorno para credenciales (nunca en código), permission model correcto con annotations destructive en tools con side effects, y logging de auditoría de todas las llamadas. Con estos controles, MCP es tan seguro como cualquier microservicio con auth propia.

¿Cómo añado autenticación a un servidor MCP remoto?

La especificación MCP recomienda OAuth 2.0 para servers HTTP remotos, pero no lo impone a nivel de protocolo: la autenticación ocurre en la capa HTTP antes del handshake MCP. La implementación práctica depende del framework: en FastMCP se puede añadir middleware HTTP que valide el Authorization: Bearer header antes de que llegue el request al router MCP. Para servers simples con un único cliente conocido, un API key en header (X-API-Key) con HTTPS es aceptable. Para producción con múltiples usuarios, OAuth 2.0 con Authorization Code Flow es el estándar correcto.

¿Puedo usar MCP sin Claude Desktop?

Sí. Claude Desktop es solo uno de los hosts posibles. Puedes conectar un MCP server desde cualquier cliente que implemente el protocolo: el OpenAI Agents SDK de Python, Cursor, Continue.dev, o un cliente propio escrito con los SDKs oficiales. Para construir un agente IA para WordPress u otros sistemas propios, es habitual escribir el host manualmente usando el SDK Python o TypeScript de MCP, sin depender de ninguna aplicación de terceros. El protocolo es completamente abierto y la spec está publicada.

Conclusión

Model Context Protocol resuelve un problema estructural real: la proliferación de integraciones M×N entre modelos y herramientas. La arquitectura Host-Client-Server, el discovery dinámico de capabilities, y el soporte de transports desde stdio hasta HTTP streamable lo convierten en el diseño correcto para sistemas de agentes que necesitan escalar. La adopción de OpenAI en Q1 2025 confirma que MCP está dejando de ser un estándar de Anthropic para convertirse en el estándar del ecosistema.

Para equipos que construyen agentes en producción, la apuesta más sólida en 2026 es implementar los backends de herramientas como MCP servers desde el principio. El coste inicial de implementar el protocolo se amortiza rápido: el mismo server funciona con Claude, con GPT y con cualquier cliente futuro que adopte MCP.

En Baigency construimos agentes IA con MCP para empresas que integran stacks de negocio reales: CRMs, ERPs, CMS, bases de datos propietarias. Desde un agente de IA para ventas que consulta el CRM en tiempo real, hasta un agente de voz con IA que invoca tools del backend mientras conversa con el cliente: en todos los casos, el patrón es el mismo y MCP es la capa que lo hace mantenible. Si necesitas conectar tu infraestructura con un agente Claude o GPT, o quieres saber cómo desplegamos MCP servers en producción, contacta con nosotros a través del formulario.