¿Qué es un MCP? (Model Context Protocol) explicado para developers

Tiempo estimado de lectura: 7 min

Definición técnica y utilidad del MCP.
Arquitectura y componentes básicos del MCP.
Problemas reales que el MCP busca resolver.
Beneficios de la implementación de MCP en proyectos.
Riesgos y pautas de uso de MCP.

Introducción

Qué es un MCP? Si trabajas con IA aplicada, agentes o automatización, es probable que ya te hayas encontrado con el problema real: los modelos LLM “razonan” bien, pero no tienen acceso nativo y seguro a tus herramientas (bases de datos, CRMs, repos, APIs internas) ni un estándar consistente para hacerlo. MCP (Model Context Protocol) aparece precisamente para ordenar ese caos: define un protocolo para que una app (cliente) conecte modelos con herramientas y contexto externo de forma estructurada.

En este artículo vas a entender qué es un MCP, cómo se compone (cliente/host/servidor), qué resuelve frente a integraciones ad-hoc, riesgos reales (seguridad, prompt injection) y un criterio práctico para decidir si te conviene.

Fuentes (URLs) para ampliar y citar:

Documentación oficial de MCP (Model Context Protocol)
Repositorio y especificación (GitHub)
Claude + MCP (anuncio/guías de Anthropic, según versión, buscar “MCP” en su documentación pública)

Qué es un MCP? Definición técnica sin hype

MCP (Model Context Protocol) es un protocolo estándar para conectar aplicaciones que ejecutan o orquestan LLMs (clientes/hosts) con servidores de contexto (MCP servers) que exponen:

Tools (acciones): llamadas a funciones / capacidades externas (por ejemplo, “crear issue en Jira”, “consultar clientes en HubSpot”, “leer un fichero del repo”, “ejecutar una query parametrizada”).
Resources (recursos): contexto recuperable (documentos, ficheros, páginas internas, resultados de búsqueda interna, catálogos, etc.).
Prompts (plantillas): prompts reutilizables y versionables para tareas frecuentes, con inputs definidos.

La idea central: en vez de integrar cada herramienta “a mano” con prompts frágiles y wrappers propietarios, MCP propone un contrato para que un cliente pueda descubrir capacidades (“qué herramientas hay”, “qué inputs requieren”) y ejecutarlas con un flujo consistente.

Si estás pensando “esto suena a function calling”, vas bien: MCP se relaciona, pero la diferencia clave es el nivel de estandarización e interoperabilidad entre herramientas y clientes, y el foco en “contexto + tools” como primera clase.

El problema real que MCP intenta resolver

En producción, integrar un LLM con sistemas reales suele fallar por razones muy poco glamourosas:

Cada integración es un snowflake
Un wrapper para GitHub, otro para Slack, otro para DBs, cada uno con su formato, auth y errores.
El contexto es un patchwork
Unas cosas se meten en el prompt, otras se recuperan con RAG, otras con function calls… y el modelo termina con información parcial o contradictoria.
La superficie de seguridad crece sin control
Tokens por todos lados, permisos excesivos, falta de auditoría, y riesgo de prompt injection al mezclar texto no confiable con instrucciones.
Difícil de mantener y versionar
Cuando una herramienta cambia (schema, endpoint, permisos), se rompe el agente; nadie sabe dónde.

MCP intenta dar una respuesta “de ingeniería”: un protocolo para que el acceso a herramientas y contexto sea descubrible, tipado/estructurado, y más fácil de gobernar.

Arquitectura MCP: host, client y server (y qué hace cada uno)

La terminología exacta puede variar según la documentación, pero el modelo mental útil es:

1) Host (aplicación “contenedora”)

Es la aplicación donde vive la experiencia: un IDE, un chat interno, un agente de soporte, un copiloto para operaciones, etc. Ejemplos típicos en el ecosistema: apps tipo “Claude Desktop” o un IDE plugin (según integraciones del momento).

2) MCP Client (el conector desde el host)

El cliente MCP es quien:

Se conecta a uno o varios MCP servers.
Descubre “qué ofrecen” (tools/resources/prompts).
Presenta esas capacidades al modelo (o al runtime del agente).
Ejecuta llamadas a tools y gestiona respuestas.

3) MCP Server (expositor de capacidades)

Un MCP server es un proceso/servicio que expone un conjunto de herramientas y contexto, normalmente asociado a un sistema o dominio:

“mcp-github”: issues, PRs, commits
“mcp-slack”: canales, mensajes, posting
“mcp-postgres”: queries parametrizadas, introspección acotada
“mcp-filesystem”: lectura controlada de rutas

El punto importante: no estás “dando Internet” al modelo. Estás dando herramientas específicas con inputs acotados y (idealmente) permisos mínimos.

Qué expone MCP exactamente: Tools, Resources y Prompts

Tools: acciones ejecutables (con contrato)

Una tool es una función invocable por el cliente, con:

nombre estable
descripción
esquema de parámetros (típicamente JSON Schema o equivalente)
salida estructurada

Esto reduce el típico “haz una request a X” en lenguaje natural y lo reemplaza por un contrato explícito.

Ejemplo conceptual (simplificado):

tool: create_jira_ticket
input: { "projectKey": "OPS", "summary": "...", "description": "...", "priority": "P2" }
output: { "issueKey": "OPS-1234", "url": "..." }

Resources: contexto recuperable con identificadores

Resources son “cosas que puedes leer” de forma controlada:

un doc interno
un fichero del repo
un runbook
una página de Confluence
un resultado de búsqueda interna

Lo importante es que el recurso se referencia (ID/URI) y se recupera vía el server, no pegando texto arbitrario en el prompt sin trazabilidad.

Prompts: plantillas versionables

Para equipos, esto importa más de lo que parece:

Prompts con inputs definidos
Versionado
Reutilización por múltiples agentes/hosts
Menos dependencia del “prompt mágico” local

Cómo encaja MCP con RAG, function calling y agentes

MCP no “reemplaza” RAG ni el function calling; los organiza.

RAG (Retrieval Augmented Generation): se centra en recuperar texto relevante desde un corpus (vector DB, búsqueda semántica). MCP puede exponer ese retrieval como resource o tool (“search_docs”, “get_doc_by_id”).

Function calling: muchos modelos ya soportan llamadas a herramientas. MCP define cómo describir y ejecutar herramientas de forma estandarizada a través de servidores.

Agentes: un agente es un loop (plan → act → observe) con memoria, herramientas y políticas. MCP es una forma de inyectar herramientas/contexto de manera mantenible.

Criterio: si tu problema es “el modelo no tiene el contexto correcto”, RAG puede bastar. Si tu problema es “necesito acciones seguras y auditables en sistemas reales”, MCP se vuelve mucho más relevante.

Beneficios reales (cuando compensa)

1) Interoperabilidad y reutilización

Un MCP server para un sistema (por ejemplo, GitHub) puede ser consumido por múltiples hosts/clientes sin reescribir integraciones.

2) Contratos explícitos

Al tener esquemas de entrada/salida:

baja la ambigüedad
mejora la validación
facilitas testing
reduces “prompt glue code”

3) Gobernanza y permisos más claros

Si lo implementas bien, puedes:

limitar qué tools existen
limitar qué acciones pueden ejecutar
auditar invocaciones
rotar credenciales por servidor/entorno

4) Menos “caja negra” en producción

MCP te fuerza (en el buen sentido) a diseñar capacidades como API internas, no como frases en un prompt.

Riesgos y anti-patrones: lo que se rompe en producción

Prompt injection sigue existiendo (solo cambia el campo de batalla)

Si tu MCP server expone tools potentes y el modelo consume texto no confiable (emails, tickets, webs), es posible que el modelo sea inducido a llamar tools de forma peligrosa.

Mitigaciones típicas:

allowlists de tools por workflow
scopes por identidad/entorno
human-in-the-loop para acciones críticas (pagos, borrados, cambios de permisos)
sanitización y separación estricta entre “instrucciones del sistema” y “datos externos”
políticas: “nunca ejecutes tool X sin confirmación explícita”

Herramientas demasiado genéricas = superficie de ataque enorme

Anti-patrón clásico: exponer una tool tipo run_sql(query: string) sin constraints. Mejor: tools específicas y parametrizadas:

get_customer_by_id(customerId)
list_invoices(customerId, fromDate, toDate)
create_refund(invoiceId, reasonCode) (con límites)

Observabilidad insuficiente

Si no logueas:

inputs/outputs (con redacción/PII handling)
tiempos
errores
decisión del agente (“por qué llamó a esta tool”)

…vas a sufrir en debugging y en compliance.

Coste de mantenimiento

MCP no elimina trabajo: lo desplaza. Ahora mantienes servidores MCP con sus versiones, auth, despliegue y SLAs. Compensa cuando hay reutilización y valor real.

Cuándo usar MCP (y cuándo NO): criterio senior

Usa MCP si:

Estás construyendo agentes o copilotos internos que requieren acciones en herramientas reales.
Tienes varias integraciones y quieres estandarizar (evitar N wrappers por host).
Tu equipo necesita gobernanza (permisos, auditoría, versionado).
Quieres separar responsabilidades: el equipo de plataforma mantiene servers; los equipos de producto consumen capacidades.

No uses MCP (todavía) si:

Solo necesitas responder preguntas con documentación: con RAG bien hecho suele bastar.
Tienes un caso único y pequeño: una integración directa puede ser más simple.
No puedes dedicar esfuerzo a seguridad/observabilidad: MCP sin disciplina puede ser peor que un sistema cerrado.

Ejemplo práctico: “agente de soporte” con MCP (sin fantasía)

Caso: soporte B2B técnico. Quieres que el agente:

lea el ticket
consulte estado del cliente en CRM
revise errores recientes en logs
proponga respuesta y, si procede, abra un issue

Con MCP, lo razonable es:

MCP server “crm”: get_account(accountId), list_open_cases(accountId)
MCP server “logs”: search_errors(service, timeframe, query) (acotado)
MCP server “github/jira”: create_issue(...)

El host (tu app) define políticas:

solo herramientas permitidas en modo “draft”
create_issue requiere confirmación humana
respuestas siempre citan resource IDs usados

Resultado: menos “magia”, más sistema.

MCP y automatización: cómo encaja con n8n y workflows

Si ya automatizas con n8n, MCP encaja como una capa adicional cuando introduces LLMs y agentes:

n8n es excelente orquestando flujos deterministas (triggers, transformaciones, integraciones).
MCP estandariza cómo un modelo accede a herramientas/contexto.

Un patrón realista:

n8n orquesta eventos (nuevo lead, ticket, alerta).
El LLM decide qué hacer y llama herramientas expuestas vía MCP.
n8n ejecuta tareas “de backoffice” y deja trazabilidad.

En muchos equipos, el LLM no debería tener acceso directo a todo. n8n puede actuar como “capa de control” (rate limits, approvals, logs), mientras MCP estructura las capacidades.

Si estás construyendo este tipo de sistemas (agentes que ejecutan trabajo real, no demos), tiene sentido apoyarte en un equipo que lo haya implementado en producción. En Dominicode Labs trabajamos precisamente en automatización e IA aplicada con criterio, incluyendo diseño de workflows con n8n, integración segura de herramientas, y construcción de agentes con gobernanza (permisos, observabilidad, despliegue).

Checklist de implementación (pragmático) antes de adoptar MCP

Define el catálogo de tools mínimo
5–15 tools bien diseñadas ganan a 200 genéricas.
Modela permisos y entornos
dev/staging/prod separados; scopes por identidad (quién invoca qué)
Diseña outputs estructurados
evita respuestas “texto libre” cuando esperas datos.
Añade observabilidad desde el día 1
correlation IDs por ejecución, logs redactados, métricas de latencia y ratio de error por tool.
Plan de seguridad
confirmación humana para acciones irreversibles, allowlists por workflow, límites (rate limiting, timeouts).
Estrategia de fallback
qué ocurre si una tool falla, circuit breakers, respuestas parciales con trazabilidad.

Conclusión: MCP como estándar útil, no como bala de plata

Qué es un MCP? Es un protocolo para conectar modelos con contexto y herramientas de manera estandarizada, con mejores contratos y potencial de gobernanza. Su valor aparece cuando pasas de “chat con documentos” a sistemas que actúan: agentes, automatización, copilotos internos y flujos productivos.

MCP no te regala seguridad, ni observabilidad, ni buen diseño de herramientas: te obliga a tomarte esas decisiones en serio. Y ahí es donde suele estar la diferencia entre un demo y un sistema que puedes mantener seis meses después.

Referencias:

https://modelcontextprotocol.io/
https://github.com/modelcontextprotocol/spec
https://www.anthropic.com/ (documentación y anuncios relacionados con MCP)

¿Qué es MCP?

MCP (Model Context Protocol) es un protocolo estándar diseñado para conectar aplicaciones que utilizan modelos de lenguaje (LLMs) con herramientas y contexto externo, permitiendo una interacción más estructurada y segura. Este protocolo ayuda a evitar problemas comunes como la falta de gobernanza y la inseguridad en las integraciones.

¿Cómo funciona MCP?

MCP funciona mediante la definición de un cliente que se conecta a uno o varios servidores MCP. El cliente puede descubrir qué herramientas y recursos están disponibles, y ejecutarlos mediante un conjunto de contratos que establecen las entradas y salidas de cada herramienta.

¿Cuáles son los beneficios de usar MCP?

Los beneficios incluyen interoperabilidad y reutilización de servicios, contratos explícitos que reducen la ambigüedad, una mejor gobernanza y controles de seguridad, así como una mayor claridad operacional en la producción.

¿Qué riesgos implica implementar MCP?

Implementar MCP puede conllevar riesgos como la posibilidad de inyecciones de prompt, exposición a herramientas demasiado genéricas y falta de observabilidad si no se controlan adecuadamente las integraciones. Es importante tener un plan de mitigación y asegurar buenas prácticas de seguridad.

¿Cuándo debería usar MCP?

Deberías considerar el uso de MCP si estás desarrollando agentes internos que requieren acciones en herramientas reales, si deseas estandarizar múltiples integraciones o si necesitas un sistema de gobernanza claro para las herramientas que se utilizan.

¿Qué es un MCP? (Model Context Protocol) explicado para developers