MCP: el nuevo estándar para conectar la IA con tus herramientas

MCP: de la integración improvisada a un contrato común

Integrar un modelo de lenguaje con una aplicación ya era sencillo cuando solo se trataba de generar texto. La situación cambió cuando los modelos pasaron a consultar bases de datos, ejecutar acciones, recuperar documentos o coordinar procesos de negocio. En ese escenario, cada proveedor, framework y aplicación developió sus propias formas de descubrir y utilizar herramientas.

El resultado es una proliferación de adaptadores difficult to maintain, una considerable duplicación de código y una experiencia inconsistente para los usuarios. Model Context Protocol, o MCP, nace como una capa de interoperabilidad para que los sistemas de IA puedan descubrir capacidades, intercambiar contexto y ejecutar acciones sin depender de una integración única y propietaria.

Anthropic presentó MCP como estándar abierto el 25 de noviembre de 2024. Desde entonces, el protocolo ha evolucionado mediante especificaciones fechadas —entre ellas 2024-11-05, 2025-03-26 y 2025-06-18— y ha sido incorporado por distintos proveedores, SDKs, IDEs y plataformas de automatización. La idea central es sencilla: establish un contrato común entre la aplicación que hospeda el modelo y los servidores que aportan datos y herramientas.

MCP no sustituye tus APIs REST, GraphQL, event buses ni bases de datos. acting as the runtime protocol that allows an AI system to use them in a discoverable, reusable and safer way.

Qué problema resuelve MCP

Un LLM no puede inventar una conexión con el sistema de facturación, el CRM o el repositorio de código. Necesita que alguien le indique qué capacidades existen, cómo invocarlas, qué parámetros aceptan y qué resultados devuelven. traditionally, that work has been solved in three different ways:

• Integraciones manuales: código específico para cada modelo, framework y SaaS.
• Plugins propietarios: mecanismos cerrados que limitan la portabilidad.
• Function calling: un mecanismo útil para estructurar llamadas, pero normalmente ligado al framework o proveedor que lo implementa.

MCP estandariza el contrato de comunicación. Un servidor MCP puede exponer, por ejemplo, una herramienta para consultar saldos, un recurso documental para consultar políticas y un prompt para generar un informe. El host descubre esas capacidades y las pone a disposición del modelo cuando son relevantes.

La analogía más extendida es la de USB-C para las integraciones de IA: una interfaz común para conectar dispositivos con capacidades diferentes. La analogía es útil, aunque conviene matizarla. MCP no elimina la necesidad de designing each capability ni garantiza que un modelo elija correctamente la herramienta. It solves a large part of the connection problem, but tool quality, authorization, orchestration and business validation remain the responsibility of the implementation.

Arquitectura de MCP: host, cliente y servidor

MCP define una arquitectura con tres componentes principales:

1. Host

El host es la aplicación en la que el usuario interactúa con el modelo. Puede ser un escritorio de chat, un IDE, un portal de atención al cliente, un panel de operaciones o una plataforma de automatización. Examples include Claude Desktop, Visual Studio Code and other assistants with native or plugin-based MCP support.

El host gestiona la conversación, los permisos, la interfaz de aprobación y la ejecución final de las acciones solicitadas por el modelo.

2. Cliente MCP

El cliente es el conector que reside dentro del host y habla MCP con uno o varios servidores. Se encarga de:

• Descubrir servidores y sus capacidades.
• Mantener la sesión y el protocolo de transporte.
• Traducir las solicitudes del modelo en operaciones MCP.
• Enviar los resultados de vuelta al modelo.
• Presentar al usuario las aprobaciones o datos adicionales que sean necesarios.

Un mismo host puede administrar varios clientes o servidores MCP. Esto permite que una aplicación conecte, por ejemplo, un servidor de documentación, otro de observabilidad y otro de gestión de tickets.

3. Servidor MCP

El servidor expone las capacidades de un sistema o servicio. Puede ser un proceso local o un servicio remoto. Each server groups related functionality behind a well-defined interface.

Un servidor de documentos podría exponer recursos; uno de despliegue, herramientas; y otro de soporte, prompts y acciones operativas. La ventaja es que la lógica de acceso queda encapsulada detrás de un contrato reusable.

La comunicación puede representarse así:

Usuario
   |
   v
Aplicación host
   |
   v
Cliente MCP <------ JSON-RPC 2.0 ------> Servidor MCP
   |                                         |
   |                                         +--> API interna
   |                                         +--> Base de datos
   |                                         +--> SaaS o microservicio
   v
 Modelo de IA

Esta separación evita que el modelo acceda directamente a credenciales, bases de datos o endpoints protegidos. El servidor funciona como una frontera de control y traducción.

Las primitivas que forman el protocolo

MCP utiliza JSON-RPC 2.0 para_requests, respuestas y notificaciones. Sobre ese transporte define tres primitivas principales y varias capacidades complementarias.

Resources: contexto controlado por la aplicación

Los recursos representan datos o información que el host puede leer y poner a disposición del modelo. La aplicación decide cuándo incluirlos en el contexto.

Un recurso se identifica mediante una URI, por ejemplo:

file:///documentos/contrato.pdf
db://clientes/123/perfil
banco://cuentas/ES12345678/saldo

Los recursos pueden admitir plantillas, como db://clientes/{id}/pedidos, y algunas implementaciones permiten suscripciones para recibir cambios. Son ideales para:

• Documentación interna.
• Registros y perfiles de clientes.
• Configuraciones y esquemas de bases de datos.
• Resultados de consultas que deben formar parte del contexto.

La diferencia frente a una herramienta es importante: el recurso describe contexto que la aplicación decide ofrecer; la herramienta representa una acción que el modelo puede solicitar.

Tools: capacidades controladas por el modelo

Las herramientas son funciones que el modelo puede seleccionar e invocar. Cada una debe definir, como mínimo, un nombre, una descripción y un esquema de entrada basado en JSON Schema.

Ejemplos:

• consultar_saldo.
• buscar_ticket.
• crear_incidencia.
• ejecutar_despliegue.
• resumir_documento.

El cliente solicita la lista mediante tools/list. Después, el modelo elige una función y el cliente ejecuta tools/call.

Las herramientas pueden incluir anotaciones como readOnlyHint, destructiveHint o idempotentHint. These annotations help the host decide how to present the action, but they are not security controls. The server must independently validate permissions and prevent unauthorized operations.

Prompts: flujos reutilizables controlados por el usuario

Los prompts son plantillas o flujos de trabajo que el usuario puede descubrir e invocar explícitamente. They can include arguments and return messages designed for a particular task.

Por ejemplo, un servidor de soporte podría ofrecer:

/resumir-incidente ticket=INC-2048

La plantilla genera instrucciones para analizar el ticket, consultar información relacionada y proponer el siguiente paso. El usuario conserva el control sobre cuándo se usa.

Sampling: el servidor solicita una generación al host

Sampling permite que un servidor pida al host que utilice su modelo para una tarea. The flow is reversed with respect to a normal tool call: the server does not need direct access to an LLM provider.

Un servidor de análisis podría solicitar una clasificación, una extracción estructurada o una segunda opinión antes de ejecutar una acción. This is useful when the host controls model selection, credentials, budgets, or data-retention policies.

Elicitation: el servidor solicita información al usuario

Elicitation permite pedir datos adicionales o una confirmación mediante la interfaz del host. It is useful when a tool cannot safely continue without clarification.

For example, before scheduling a deployment, the server could request:

• Target environment.
• Maintenance window.
• Confirmation that the operation is authorized.

Roots, completion y notificaciones

Los roots permiten que el cliente indique los límites de URI que está dispuesto a compartir, por ejemplo un directorio de trabajo. No deben considerarse una frontera de seguridad: el servidor sigue necesitando validar rutas y permisos.

La capability de completion ofrece sugerencias para completar argumentos. Las notificaciones, el progreso y la cancelación permiten una interacción más fluida, especialmente con operaciones largas.

Dos transportes principales

Stdio para servidores locales

En el transporte stdio, el host inicia un proceso local y se comunica con él mediante entrada y salida estándar. This model is especially useful for desktop applications, development tools, and scripts.

The server should write protocol messages exclusively to standard output and send logs to standard error. This prevents logs from corrupting the JSON-RPC stream.

Streamable HTTP para servidores remotos

Streamable HTTP utiliza un endpoint HTTP para transportar mensajes JSON-RPC. It can support server-to-client streams, including Server-Sent Events, and mechanisms for session continuity and resumability.

This older HTTP+SSE approach has been replaced by Streamable HTTP in recent MCP revisions, but both terms still appear in documentation and existing implementations.

For a remote server, consider:

• Autenticación del usuario y del cliente.
• Autorización granular por herramienta o recurso.
• Validación del encabezado Origin en entornos expuestos a navegador.
• Límites de tasa y tamaño de mensajes.
• Cifrado TLS.
• Registro de auditoría.
• Aislamiento de sesiones.

Ejemplo práctico: un servidor MCP para consultar saldos

El siguiente ejemplo utiliza el SDK oficial de Python y FastMCP. The server validates the account format and calls an existing internal API. The API credential stays in the server environment and is never sent to the model.

import os
import re

import httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("banco-demo")
API_URL = os.environ["BANCO_API_URL"]


@mcp.tool()
def consultar_saldo(cuenta: str) -> dict:
    """Consulta el saldo disponible de una cuenta bancaria en EUR."""
    if not re.fullmatch(r"ES\d{8}", cuenta):
        raise ValueError("La cuenta debe tener el formato ES seguido de 8 dígitos")

    response = httpx.get(
        f"{API_URL}/cuentas/{cuenta}/saldo",
        timeout=5.0,
    )
    response.raise_for_status()

    return {
        "cuenta": cuenta,
        **response.json(),
    }


if __name__ == "__main__":
    mcp.run(transport="stdio")

Después de instalar las dependencias en un entorno virtual, el host puede registrar el servidor mediante una configuración similar a esta:

{
  "mcpServers": {
    "banco-demo": {
      "command": "python",
      "args": ["server.py"],
      "env": {
        "BANCO_API_URL": "https://api.interna.example.com"
      }
    }
  }
}

La sintaxis exacta de configuración depende del host. The important principle is that the server receives the environment needed to call the backend, while the model only sees the tool contract.

During initialization, the client negotiates the protocol version and capabilities:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {
      "name": "mi-aplicacion",
      "version": "1.0.0"
    }
  }
}

El cliente envía después notifications/initialized y solicita las herramientas:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

Cuando el modelo decide consultar el saldo, el host ejecuta:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "consultar_saldo",
    "arguments": {
      "cuenta": "ES12345678"
    }
  }
}

Una respuesta moderna puede incluir contenido legible y datos estructurados:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "El saldo disponible de ES12345678 es 1.250,75 EUR."
      }
    ],
    "structuredContent": {
      "cuenta": "ES12345678",
      "saldo": 1250.75,
      "moneda": "EUR"
    },
    "isError": false
  }
}

Para una operación con efectos secundarios —una transferencia, un despliegue o un cierre de ticket— el flujo debería incorporar una aprobación explícita. The model proposes the action, the server validates it, and the host asks the user to confirm before execution when the policy requires it.

Seguridad: el punto decisivo de cualquier implementación MCP

MCP conecta modelos con sistemas capaces de producir impacto real. This makes security more than an optional extension. The protocol provides mechanisms for identity and authorization, but the application must implement a complete threat model.

Prompt injection y tool poisoning

Una descripción de herramienta maliciosa puede intentar manipular al modelo mediante instrucciones ocultas. Del mismo modo, un documento retrieved as a resource could contain text intended to alter the agent's behavior.

Controls recommended:

• Validar y versionar las descripciones de herramientas.
• Revisar el código y las dependencias de cada servidor.
• Marcar claramente contenido externo y datos recuperados.
• Limitar las herramientas disponibles para cada sesión.
• No obedecer instrucciones incrustadas en datos como si fueran comandos de sistema.

Permisos excesivos y confused deputy

El servidor no debe ejecutar todo lo que el modelo solicite. When a tool operates with a broad service account, a manipulated model could become a confused deputy and access resources the user never intended to expose.

Apply least privilege, user-specific authorization, scoped tokens, explicit audit trails, and allowlists for arguments and destinations. A tool that reads a customer profile should not automatically be able to delete that profile or export the entire database.

Token passthrough y suplantación de audiencia

No conviene que el cliente reenvíe sin validar un token de acceso hacia un servidor MCP o una API descendente. The receiving server must validate the token, its issuer, its audience, its scopes, and its expiration.

For remote HTTP servers, OAuth 2.1 and PKCE provide a robust foundation, although the exact authorization architecture depends on the deployment. In local environments, the operating-system identity and process permissions are often more relevant than OAuth.

SSRF, path traversal y acceso a archivos

Si una herramienta acepta una URL, una ruta o un identificador proporcionado por el modelo, debe aplicar controles estrictos:

• Allowlists de hosts, protocolos, puertos y directorios.
• Resolución y validación de rutas antes de abrir archivos.
• Bloqueo de redirecciones hacia redes internas.
• Restricciones de red para el proceso del servidor.
• Separación entre datos del usuario y parámetros de control.

Ejecución arbitraria de comandos

Las herramientas que ejecutan shell scripts, código o procesos son especialmente peligrosas. Nunca deben estar disponibles solo porque el modelo las ha solicitado. Las operational tools must be allowlisted, sandboxed, and executed with a controlled user, controlled environment, and limited execution time.

Fuga de información

Los logs, las respuestas y los resultados estructurados pueden contener tokens, datos personales o información confidencial. Redact secrets, minimize returned fields, classify the data, and avoid placing unnecessary content in the model context.

Confirmación humana

Las acciones irreversibles, destructivas o financieras deben exigir una confirmación explícita. The approval screen must show the actual arguments, target and expected impact, not just a generic message asking whether to continue.

MCP frente a APIs, OpenAPI y function calling

MCP often appears alongside other integration technologies, but it operates at a different layer:

Mecanismo	Responsabilidad principal	Relación con MCP
REST/OpenAPI	Contrato de APIs HTTP entre servicios	MCP puede consumir y envolver estas APIs
GraphQL	Consulta y combinación de datos	Los recursos MCP pueden usarse como fachada GraphQL
Function calling	Selección estructurada de funciones por un modelo	MCP extiende este patrón con descubrimiento y ejecución interoperable
Plugins y SDKs propietarios	Integración específica de una plataforma	MCP ofrece un contrato alternativo y portable
Orquestadores de agentes	Coordinación de tareas, memoria y agentes	MCP no reemplaza la lógica de orquestación

Una API puede tener veinte endpoints y seguir siendo inaccesible para un agente si no existe una capa que describa qué operaciones son seguras, relevantes y autorizadas. MCP cubre esa capa de experiencia de herramienta. It does not define the business transaction itself, nor does it replace API gateways, service meshes, or event-driven architectures.

En una arquitectura empresarial típica, el servidor MCP funciona como un adaptador o Fachaden between the agent and existing systems:

Agente y usuario
      |
      v
Host MCP
      |
      v
MCP Gateway: identidad, cuotas, auditoría y observabilidad
      |
      +--> Servidor MCP de conocimiento
      +--> Servidor MCP de tickets
      +--> Servidor MCP de finanzas
      +--> Servidor MCP de DevOps
              |
              v
       APIs ymicroservicios existentes

El gateway MCP puede aplicar políticas comunes, pero cada servidor debe conservar la validación específica de su dominio.

Casos de uso con mayor potencial

Soporte y atención al cliente

El agente consulta tickets, políticas, pedidos y estado de cuentas. Los recursos aportan contexto; las tools realizan búsquedas y actualizaciones; los prompts generan resúmenes consistentes.

Ingeniería y DevOps

Un servidor MCP puede exponer logs, métricas, estado de pipelines y despliegues. The model can correlate a regression with a recent change, but execution permissions must remain tightly controlled.

Knowledge management

Documentación, wikis, contratos y tickets pueden convertirse en recursos consultables. This improves grounding and reduces hallucination, provided citations, permissions, and freshness are managed correctly.

Finanzas y operaciones

Consulta de saldos, conciliaciones o conciliaciones de facturas are natural tool-based use cases. Payments, refunds, and ledger changes require stronger approval and segregation-of-duties controls.

Automatización multicanal

Un mismo servidor puede ser utilizado desde un desktop assistant, an IDE, or a customer service platform. This reduces the number of custom connectors and makes capabilities more portable.

Patrones de diseño recomendados

Una herramienta pequeña y predecible

Rather than creating a single gestionar_finanzas tool with dozens of ambiguous parameters, it is preferable to offer focused tools such as consultar_saldo, listar_transacciones and solicitar_transferencia. Smaller contracts improve selection, validation, and auditing.

Descripciones completas

The model relies heavily on the tool name and description. Explain what the tool does, when it should be used, required context, expected units, and important limitations. An incomplete description can lead to incorrect tool selection even when the implementation is correct.

Validación en varias capas

Validate the schema at the protocol boundary and business rules in the server. Validate authorization separately, and apply user confirmation for high-impact operations. Schema validation does not replace domain validation.

Structured results

Return machine-readable data whenever possible. This makes it easier for the agent to reason, reduces ambiguity, and avoids having to extract values from a large block of prose.

Idempotencia

Network interruptions can lead to retries. For write operations, use idempotency keys or other deduplication mechanisms so that a repeated request does not create duplicate payments, tickets, or deployments.

Versioning

Version the MCP server, SDK, and protocol assumptions independently. Use contract tests to detect incompatibilities and read the specification revision supported by your implementation. Pin dependencies in production and review upgrades before deployment.

Observabilidad y métricas

MCP makes AI tool calls more visible, but visibility alone does not guarantee quality. At minimum, measure:

• Task success rate: completed user objectives, not merely successful HTTP calls.
• Tool selection accuracy: whether the model selected the correct capability.
• Invocation success rate: calls that pass validation and execution.
• Latency: p50 and p95 for discovery, execution and total response time.
• Human intervention rate: approvals, corrections and cancellations.
• Token and context overhead: data included unnecessarily in the prompt.
• Cost per task: model usage plus infrastructure and integration costs.
• Security events: unauthorized attempts, repeated denials and unusual patterns.

Audit logs should record the user or workload identity, tool name, redacted arguments, authorization decision, latency, result status and request correlation identifier. Never store credentials or unnecessary personal data in those logs.

Hoja de ruta para adoptarlo en producción

1. Empieza por casos de uso acotados

Select three to five high-value tasks, preferably read-only and easy to verify. A documentation search, ticket summary or balance query provides a better starting point than an autonomous production deployment.

2. Inventaría tus APIs existentes

Before creating MCP servers, identify which operations already have stable contracts. MCP should usually adapt existing services, not duplicate them.

3. Separa lecturas y acciones

Use resources for contextual information and tools for executable capabilities. Clearly label read-only and destructive operations, and configure approvals according to impact.

4. Elige local o remoto

stdio is appropriate for local tools and development. Streamable HTTP is preferable when the server must be shared, centrally deployed, or accessible across organizational boundaries.

5. Aplica seguridad desde el primer commit

Implement least privilege, input validation, secret management, audit logging, user confirmation and isolated execution. Security added after the first production incident is usually too late.

6. Mide antes y después

Establish a baseline for task completion, latency, cost, and human intervention. Compare the MCP implementation with the previous manual or custom integration.

7. Crea un catálogo governado

Maintain approved servers, owners, versions, permissions, data classifications and support commitments. This avoids uncontrolled servers spreading across the organization.

Limitaciones y preguntas abiertas

MCP standardizes communication, but it does not solve every AI problem. Tool descriptions can be ambiguous, models can still select the wrong capability, and a standardized protocol does not make an unsafe operation safe. The ecosystem also evolves rapidly, so version compatibility and implementation maturity must be evaluated carefully.

There is also no guarantee that two servers use the same business semantics merely because both implement MCP. A tool called crear_usuario can have different rules, validations and side effects in different systems. Organizational governance remains essential.

MCP is best understood as a connectivity and interoperability layer. It works alongside APIs, event-driven systems, agent frameworks, identity platforms and AI gateways. Its long-term value will depend on how well the ecosystem combines open contracts with rigorous security and clear capability design.

Fuentes oficiales para profundizar

• Documentación de Model Context Protocol
• Especificación MCP 2025-06-18
• Transporte Streamable HTTP
• Prácticas de seguridad
• Repositorio oficial de SDKs y servidores
• Anuncio de MCP de Anthropic

Conclusión: construye una IA conectada, portable y gobernable

MCP representa un cambio importante en la forma de conectar modelos con software. Instead of building one custom bridge for every model and application, organizations can expose reusable capabilities through a common protocol.

Su éxito no dependerá únicamente de la especificación. The decisive factors will be clear tool contracts, least-privilege access, reliable versioning, human approval for critical actions, and observability across the entire chain.

For companies that want to move from pilots to production, the recommended path is clear: start with read-only use cases, reuse existing APIs, build secure MCP servers and measure real task outcomes before expanding permissions.

Tanok Tech puede ayudarte a diseñar una arquitectura MCP, crear servidores para tus sistemas y preparar integraciones de IA seguras y listas para escalar. Conversemos sobre tu caso y definamos el primer caso de uso que pueda generar valor sin comprometer el control ni la gobernabilidad.