Anthropic MCP (Model Context Protocol): el estándar abierto que cambia integraciones IA

El 25 de noviembre Anthropic publicó Model Context Protocol (MCP): un estándar abierto, con SDKs en TypeScript y Python, que define cómo un LLM se conecta con datos y herramientas externas. La promesa es simple: una sola integración que sirve para cualquier modelo que soporte MCP, no una por cada proveedor. Anthropic publicó también servidores de referencia open source para los casos comunes (filesystem, GitHub, Slack, Postgres, web fetch, Google Drive).

Si esa promesa se cumple, MCP cambia la economía de cómo se integra IA con sistemas empresariales. En ALCA llevamos meses lidiando con el problema que MCP intenta resolver. Aquí va lectura técnica con foco en lo que importa para empresas medianas mexicanas.

El problema que resuelve

Hasta ahora, conectar un LLM con sus datos y tools requería integraciones específicas por proveedor:

• OpenAI tiene "function calling" con su esquema JSON.
• Anthropic tiene "tool use" con un esquema parecido pero distinto.
• Google Gemini tiene su propio formato.
• Modelos abiertos en Llama, Mistral o DeepSeek tienen variantes.

El resultado: cada vez que cambias de modelo, reescribes la capa de integración. O, peor, te amarras a un proveedor para no rehacer el trabajo. Para una empresa que quiere usar el mejor modelo para cada caso (Claude para razonamiento, GPT-4o para multimodal, modelo abierto para tareas baratas), eso significa duplicar esfuerzo o renunciar a flexibilidad.

MCP plantea un protocolo único cliente-servidor-transporte:

• Servidor MCP: pequeño proceso que expone datos o tools (leer archivos, consultar Postgres, mandar Slack, llamar tu API interna).
• Cliente MCP: el LLM o la aplicación que lo usa.
• Transporte: stdio o WebSocket, simple.

El servidor anuncia qué tools y recursos tiene; el cliente los descubre y los usa. La capa de protocolo es independiente del modelo.

Los servidores de referencia open source

Anthropic publicó servidores listos para uso en GitHub (anthropic/mcp-servers):

• Filesystem: leer y escribir archivos en directorios autorizados.
• GitHub: leer repos, issues, PRs.
• GitLab: equivalente.
• Postgres: consultas SQL de solo lectura.
• Slack: leer canales, enviar mensajes.
• Google Drive: leer documentos.
• Memory: persistencia simple para agentes.
• Web fetch / browse: traer URLs.
• Brave Search, Sentry, Sqlite, Time: utilidades varias.

Para una empresa mediana, estos servidores cubren ~70% de las integraciones típicas que un piloto de IA requeriría hoy. Lo que falta (su ERP, su CRM custom, su sistema de tickets) se construye con un servidor propio.

Cómo se ve un servidor MCP propio (~50 líneas Python)

Para dimensionar la simplicidad, un servidor MCP que expone una tool para consultar inventario en su sistema interno se ve así, en esquema:

from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("inventario-alca")

@app.list_tools()
async def list_tools():
    return [Tool(
        name="consultar_inventario",
        description="Consulta stock por SKU en almacén central",
        inputSchema={
            "type": "object",
            "properties": {
                "sku": {"type": "string"}
            },
            "required": ["sku"]
        }
    )]

@app.call_tool()
async def call_tool(name, arguments):
    if name == "consultar_inventario":
        sku = arguments["sku"]
        # llamada real a tu sistema
        stock = await tu_erp.get_stock(sku)
        return [TextContent(
            type="text",
            text=f"SKU {sku}: {stock} unidades"
        )]

Lo arrancas, lo conectas vía stdio a Claude Desktop o a tu aplicación, y el modelo ya puede consultar inventario. Sin re-implementar tool calling para cada proveedor.

Implicaciones operativas para empresas mexicanas

1. Portabilidad de integraciones entre modelos

Si construyen integraciones como servidores MCP, el día que decidan cambiar de Claude a GPT-4 o a un modelo abierto, no rehacen la integración. Esa portabilidad no la había. En un mercado donde precio y capacidad cambian cada trimestre, no estar amarrado vale.

2. Reuso entre aplicaciones

Un servidor MCP de "consultar Postgres" lo usan: el chatbot interno, el agente de soporte, el asistente de BI, el script de operación. Una integración bien hecha sirve a múltiples casos. Antes había que duplicar.

3. Surface de seguridad nueva

Los servidores MCP son procesos que reciben instrucciones del modelo y operan sobre datos sensibles. Es vector clásico de ataque si se descuida. Buenas prácticas que recomendamos desde ahora:

• Servidores MCP como procesos con permisos mínimos (no root, sin acceso a más recursos de los necesarios).
• Whitelist explícita de qué archivos, qué tablas, qué endpoints puede tocar.
• Auditoría de cada llamada: qué tool se invocó, con qué argumentos, qué devolvió.
• Sandbox cuando el modelo tenga autonomía (agentic).

4. Comunidad y adopción cruzada

OpenAI, Google y los grandes laboratorios aún no se han comprometido públicamente con MCP. Pero el ecosistema open source sí: en una semana ya empezamos a ver integraciones MCP para Cline, Continue, Zed, Cursor y otros. Si la adopción cruzada llega, MCP se vuelve estándar de facto en 2025. Si no, queda como una buena especificación de Anthropic. La apuesta razonable es que sí llega, porque resuelve un dolor real.

Lo que no resuelve MCP

Honestidad técnica: MCP es protocolo, no magia. No resuelve:

• Calidad del modelo. Si el LLM razona mal, MCP no ayuda.
• Consistencia de datos. Si la base está sucia, las tools regresan basura.
• Costo de inferencia. El modelo sigue cobrando por tokens; MCP solo organiza la integración.
• Governance organizacional. Quién puede usar qué tool, con qué datos, con qué auditoría: eso lo define la empresa, no el protocolo.

Roadmap recomendado para Q1 2025

Si su empresa ya tiene IA en pilotos o producción, esta es la priorización razonable:

Mes 1. Inventario de integraciones IA-sistemas existentes. Cuántas hay, cuál es el patrón actual de cada una, cuánto duele cambiarlas hoy.

Mes 2. Pilotear MCP en un caso simple (ej. integrar Claude Desktop con su Postgres en modo lectura). Aprender el protocolo en pequeño.

Mes 3. Construir un servidor MCP propio para una integración de valor real (su ERP, su CRM, su sistema de tickets). Empezar con tools de solo lectura.

Mes 4-6. Migrar progresivamente las integraciones existentes a servidores MCP. Establecer governance: quién aprueba un servidor nuevo, qué auditoría requiere, qué scopes son permitidos.

Lectura más allá del protocolo

MCP es un movimiento estratégico de Anthropic: si logran que el ecosistema lo adopte, convierten el problema "amarrar al cliente al proveedor" en "cualquier modelo cumple, gana el mejor por caso de uso". Esto, paradójicamente, beneficia a Anthropic en mediano plazo porque su tesis es que Claude gana por mérito de capacidad. Para empresas mexicanas, lo que importa es la consecuencia: menos lock-in, más portabilidad, integraciones que envejecen mejor.

Para una consultora como ALCA, MCP cambia cómo recomendamos arquitectura para clientes. A partir de diciembre, toda nueva integración IA-sistemas que diseñamos lo evaluamos primero como servidor MCP. Si no encaja, lo justificamos. Esa es la disciplina que probablemente todos los equipos de plataforma van a adoptar en 2025.

---

¿Quieres conectar IA con tus sistemas vía MCP? Te ayudamos. En ALCA construimos servidores MCP custom para ERPs, CRMs y plataformas internas mexicanas. Conversemos aquí.