El dato que casi ningún artículo en español todavía incorpora: MCP ya no es un protocolo de Anthropic. Anthropic lo publicó en noviembre de 2024 y lo donó a la Agentic AI Foundation de la Linux Foundation el 9 de diciembre de 2025, junto a Block y OpenAI como co-fundadores, con apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. En el momento de esa donación el protocolo registraba más de 97 millones de descargas mensuales de sus SDK y 10.000 servidores activos.
Esta guía está escrita desde el uso diario. Duotach es una consultora de automatización con IA con base en Buenos Aires, y corremos servidores MCP todos los días para producir los reportes de nuestras cuentas y para conectar los sistemas de clientes con asistentes de IA. Lo que sigue es qué es un servidor MCP, cómo funciona hoy (la especificación cambió en 2026 y buena parte del contenido en español quedó viejo), cuándo conviene y cuándo no, y cómo se usa sobre el stack real de una empresa de Argentina y LATAM.
En este artículo:
- ¿Qué es un servidor MCP?
- El problema que resuelve: N herramientas por M modelos
- ¿Cómo funciona un servidor MCP?
- ¿Qué cambió en la especificación de 2026?
- ¿Quién es dueño de MCP hoy?
- MCP, n8n o integración directa: cómo elegir
- Servidores MCP que ya existen y no hay que construir
- Cómo usar servidores MCP en tu empresa: casos reales
- Seguridad: los riesgos propios de MCP
- ¿Cuándo NO usar un servidor MCP?
- ¿Cómo empezar?
¿Qué es un servidor MCP?
Un servidor MCP es un programa que traduce un sistema tuyo al idioma que entienden los modelos de IA. No es una máquina que haya que alquilar, y esa es la primera confusión que conviene sacar del medio: en MCP la palabra "servidor" nombra al programa que sirve el contexto, no al hardware. Puede correr en la notebook de un empleado o en la nube, y en los dos casos se llama igual.
La documentación oficial usa una analogía que quedó pegada al protocolo: MCP es el puerto USB-C de las aplicaciones de IA. Así como el USB-C define una forma estándar de enchufar dispositivos, MCP define una forma estándar de enchufar sistemas a un modelo. El fabricante del monitor no necesita saber qué notebook vas a usar, y el que escribe un servidor MCP no necesita saber si del otro lado va a haber Claude, ChatGPT o Copilot.
Un servidor MCP puede exponer tres cosas:
- Herramientas (tools): funciones que el modelo puede ejecutar. Consultar el stock de un artículo, crear un ticket, correr una query.
- Recursos (resources): datos que el modelo puede leer. El contenido de un archivo, el esquema de una base, un documento de procedimientos.
- Prompts: plantillas de interacción reutilizables. Por ejemplo, la estructura fija con la que tu equipo pide un análisis de cuenta corriente.
La diferencia con un chatbot al que le pegás un PDF es de fondo. El modelo no está leyendo una copia de tus datos: está consultando la fuente en el momento, con los permisos que vos definiste, y puede escribir de vuelta si el caso lo requiere.
El problema que resuelve: N herramientas por M modelos
Antes de MCP, cada conexión entre un asistente de IA y una herramienta era un desarrollo propio. Si querías que tu asistente leyera el Drive, alguien escribía esa integración. Si además querías el CRM, otra integración. Y si mañana cambiabas de asistente, había que rehacer todo.
La cuenta se vuelve fea rápido. Con 6 sistemas y 3 asistentes distintos son 18 integraciones para construir y mantener. Con MCP son 6 servidores, uno por sistema, y cualquier cliente compatible los consume sin trabajo adicional. Pasás de un problema que se multiplica a uno que se suma.
Para una empresa esto se traduce en dos cosas concretas. La primera es que el trabajo de integración se hace una vez y no se tira cuando cambia la herramienta de arriba. La segunda es que el criterio de compra cambia: en vez de preguntar "¿con qué asistente se integra este proveedor?", la pregunta pasa a ser "¿expone un servidor MCP?".
¿Cómo funciona un servidor MCP?
MCP sigue una arquitectura cliente-servidor con tres participantes, definidos así en la documentación oficial de arquitectura:
- 1. Host. La aplicación de IA que usa la persona: Claude Desktop, Claude Code, Visual Studio Code, ChatGPT.
- 2. Cliente MCP. El componente que mantiene la conexión con un servidor. El host crea un cliente por cada servidor conectado, así que si tenés tres servidores hay tres clientes.
- 3. Servidor MCP. El programa que expone tus datos y funciones.
El protocolo tiene dos capas. La capa de datos define los mensajes, y usa JSON-RPC 2.0. La capa de transporte define por dónde viajan esos mensajes, y hoy hay dos opciones:
| Transporte | Dónde corre | Cuándo se usa |
|---|---|---|
| stdio | En la misma máquina que el host, por entrada y salida estándar | Servidores locales. Sin latencia de red, y el dato no sale del equipo |
| Streamable HTTP | En un servidor remoto, por HTTP POST con Server-Sent Events opcionales | Servidores compartidos por varios usuarios. Soporta bearer tokens, API keys y OAuth |
La distinción importa a la hora de decidir dónde vive el dato. Un servidor por stdio corre en la máquina del usuario y atiende a un solo cliente. Un servidor por Streamable HTTP corre en la nube y atiende a muchos, lo que lo hace la opción para una empresa que quiere un solo punto de control y de auditoría.
El ciclo de una consulta es simple:
- El cliente descubre qué ofrece el servidor (server/discover).
- Pide la lista de herramientas disponibles (tools/list), con el esquema de parámetros de cada una.
- El modelo decide cuál usar y la invoca con argumentos tipados (tools/call).
- El servidor ejecuta y devuelve contenido estructurado, que el modelo usa como contexto de la respuesta.
Cada herramienta declara su esquema de entrada en JSON Schema, así que el modelo sabe qué parámetros son obligatorios y de qué tipo antes de invocar nada. Eso es lo que hace que la conexión sea confiable y no una adivinanza.
¿Qué cambió en la especificación de 2026?
La versión vigente de la especificación es 2026-07-28. Casi todo el contenido en español que vas a encontrar describe la arquitectura de 2024 y 2025, y varias cosas dejaron de ser ciertas. Estos son los cuatro cambios que le importan a quien va a contratar o mantener un servidor MCP:
| Qué se decía antes | Qué dice la especificación vigente | Qué significa para tu proyecto |
|---|---|---|
| El protocolo mantiene estado de sesión entre requests | MCP es un protocolo sin estado: cada request lleva versión y capacidades en su campo _meta | El servidor escala mejor y tolera reconexiones sin perder el hilo |
| La conexión arranca con un handshake de inicialización | El descubrimiento se hace con server/discover, y la respuesta es cacheable | Menos ida y vuelta, y clientes que se recuperan más rápido |
| El servidor puede pedirle al cliente que corra un modelo (sampling) | Sampling está deprecado desde 2026-07-28. Las implementaciones nuevas integran directo con la API del proveedor | Un servidor nuevo que dependa de sampling nace con deuda técnica |
| El servidor manda logs al cliente | Logging está deprecado. Lo recomendado es escribir a stderr o usar OpenTelemetry | El monitoreo se resuelve con herramientas de infraestructura, no dentro del protocolo |
La primitiva de cliente que sí está vigente es elicitation: el servidor puede pedirle un dato o una confirmación al usuario antes de seguir. Es la que usarías para que el asistente pregunte "¿confirmás que emito la nota de crédito?" en vez de emitirla de una.
¿Por qué esto es un criterio de compra y no un detalle técnico? Porque si te cotizan un servidor MCP construido sobre la arquitectura de 2025, te van a entregar algo que hay que rehacer. Preguntar contra qué versión de la especificación se construye es una pregunta legítima y barata de hacer.
¿Quién es dueño de MCP hoy?
Anthropic publicó MCP como estándar abierto en noviembre de 2024. El 9 de diciembre de 2025 lo donó a la Agentic AI Foundation, un fondo dirigido dentro de la Linux Foundation, creado junto a Block y OpenAI y con apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. Los otros dos proyectos fundacionales de esa fundación son AGENTS.md y goose.
Los números que acompañaron el anuncio, citados textualmente en el comunicado del protocolo:
- Más de 97 millones de descargas mensuales de los SDK.
- 10.000 servidores activos.
- Soporte de primera clase en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y Visual Studio Code.
Esto responde la objeción que aparece siempre en la reunión de sistemas: ¿y si mañana cambiamos de proveedor de IA? Un servidor MCP no se ata a Claude. Es el mismo programa consumido por cualquier cliente compatible, y la gobernanza del protocolo ya no depende de una sola empresa. Para una empresa que evalúa una inversión a tres años, esa es la diferencia entre una integración y una apuesta.
MCP, n8n o integración directa: cómo elegir
Esta es la decisión que ningún artículo en español plantea, y es la única que importa cuando hay presupuesto de por medio. Nadie elige entre MCP y no hacer nada. Se elige entre tres caminos que cuestan distinto y sirven para cosas distintas.
| Situación | Camino | Por qué |
|---|---|---|
| El proceso corre siempre igual, con volumen alto, sin nadie decidiendo en el medio | Integración directa por API | Un modelo en el medio agrega costo, latencia y variabilidad a algo que ya es determinístico |
| Hay un flujo con pasos, condiciones y horarios, disparado por un evento y no por una persona | Orquestador tipo n8n | El valor está en encadenar sistemas y manejar reintentos, no en interpretar una pregunta |
| Hay una persona (o un agente) haciendo preguntas distintas cada vez, y hace falta consultar y operar el sistema en el momento | Servidor MCP | La pregunta no se conoce de antemano, así que no se puede prever el flujo |
En la práctica los tres conviven en el mismo proyecto y no compiten entre sí. Un cliente puede tener una automatización con n8n que procesa los pedidos que entran por WhatsApp, una API directa que sincroniza el catálogo cada noche, y un servidor MCP que le permite al equipo comercial preguntarle al sistema por el estado de una cuenta sin abrir el ERP.
La regla que usamos para decidir es una sola pregunta: ¿la pregunta es siempre la misma? Si la respuesta es sí, no hace falta un modelo en el medio. Si cada vez es distinta, ahí MCP paga.
Servidores MCP que ya existen y no hay que construir
Buena parte del trabajo ya está hecha. Hay servidores MCP publicados y mantenidos para sistemas de archivos, PostgreSQL y otras bases, Google Drive, Slack, GitHub, Sentry, Figma y herramientas de analítica. Antes de cotizar un desarrollo conviene revisar si el sistema que querés conectar ya tiene el suyo.
Del lado del cliente, los conectores remotos de Claude están disponibles en los planes Pro, Max, Team y Enterprise. En Team y Enterprise el administrador controla qué extensiones puede habilitar el equipo, puede subir extensiones propias y puede dejar solamente las aprobadas. Si tu preocupación es gobernanza, ese control existe y no hay que construirlo.
Lo que sí se construye a medida es lo que no existe, y en una empresa real eso casi siempre es el sistema propio: el ERP, el sistema de gestión vertical del rubro, la base de datos interna, el módulo que alguien programó hace ocho años. Ese es el trabajo que se cotiza, y es el que da la ventaja, porque es el que ningún competidor tuyo tiene resuelto.
El criterio es directo:
- Ya existe: herramientas globales de mercado (Drive, Slack, GitHub, bases de datos estándar). Se configura, no se desarrolla.
- A medida: todo lo que sea propio de tu empresa o de tu rubro. Se desarrolla, y ahí está el valor.
Cómo usar servidores MCP en tu empresa: casos reales
El contenido disponible en español sobre MCP está escrito desde España, con ejemplos de SAP y de normativa europea. Estos son cuatro casos sobre el stack que realmente tiene una empresa de Argentina, México o Ecuador.
1. Consultar el ERP en lenguaje natural
Tango, Bejerman, Dux y Finnegans son los sistemas donde vive la operación de buena parte de las empresas de la región. El patrón es siempre el mismo: alguien exporta a Excel, cruza dos planillas y arma el informe a mano. Un servidor MCP expone las consultas que ese equipo hace todos los días (stock por depósito, cuenta corriente de un cliente, facturación del mes por vendedor) y el equipo pregunta en vez de exportar.
Acá hay un tema que hay que resolver antes de cotizar nada y es qué expone el ERP. Algunos tienen API documentada, otros tienen base de datos accesible, y otros no tienen nada. Lo tratamos en detalle en la guía sobre integrar IA con Tango, Bejerman o Dux.
2. El sistema de gestión vertical sin API pública
Es el caso más común de la región y el que más proyectos frena. Software de despachantes de aduana, de laboratorios, de inmobiliarias, de clínicas: sistemas verticales con muchos años encima y sin API pensada para terceros. Cuando hay acceso de lectura a la base, un servidor MCP se construye sobre eso. Cuando no hay ninguna vía de acceso programático y el proveedor no la va a habilitar, no hay MCP posible, y decirlo antes de cobrar es parte del trabajo.
3. La base de conocimiento interna
Procedimientos, contratos, histórico de proyectos, minutas. Expuestos como recursos de un servidor MCP, el asistente responde con la fuente en vez de inventar, y el equipo deja de preguntarle a la persona que "sabe dónde está". Es el mismo problema que resolvimos en la base de conocimiento de una agencia de medios, donde el conocimiento de las cuentas estaba repartido entre carpetas y cabezas.
4. Consulta desde el canal donde ya trabaja el equipo
Un vendedor no va a abrir el ERP en medio de una conversación de WhatsApp. Si el asistente que atiende ese canal tiene un servidor MCP conectado al sistema, la consulta se resuelve donde ya está la persona. La conexión al canal se resuelve con el orquestador, y la consulta al sistema con MCP.
Lo que corremos nosotros
El sistema interno de trabajo de Duotach se apoya en servidores MCP. Los de Google Search Console y Google Analytics 4 corren por transporte stdio en la máquina local, con nuestras propias credenciales, así que la data de posicionamiento y tráfico de las cuentas de clientes no pasa por ningún servidor intermedio. Los de Gmail, Drive y Calendar son conectores remotos del proveedor. Con ese conjunto se produce el reporte mensual de cada cuenta el primer día de cada mes, sin exportar un solo CSV a mano.
Esa diferencia de transporte no es un tecnicismo, es una decisión de diseño: lo que toca data sensible de clientes corre local, y lo que es correo y agenda propia puede ir por conector remoto. Elegir el transporte por tipo de dato es exactamente el criterio que aplicamos cuando armamos Claude para empresas en Argentina, y la continuación natural de lo que contamos en la guía de Claude Code en Argentina.
Seguridad: los riesgos propios de MCP
MCP trae riesgos que no existían antes, y merecen algo mejor que un párrafo genérico sobre permisos. Hay dos con nombre propio.
Tool poisoning. Un atacante esconde instrucciones maliciosas dentro de la descripción de una herramienta MCP. El modelo lee esa descripción como información confiable y actúa en consecuencia, por ejemplo filtrando datos o llamando a herramientas que tenía restringidas. OWASP lo cataloga como un ataque específico de MCP. Lo grave es que no se agota en una sesión: una herramienta comprometida afecta a cualquier agente que la use.
Inyección indirecta de prompts. Variante del anterior donde las instrucciones no vienen en la descripción sino en la respuesta de la herramienta. El servidor devuelve datos que traen texto diseñado para que el modelo lo obedezca. Microsoft publicó documentación específica sobre cómo protegerse de esto en contextos MCP.
Las cuatro reglas que aplicamos en todo despliegue:
- 1. Servidor propio para sistema propio. Un servidor MCP de terceros que nadie auditó no se conecta a datos de la empresa. Para los sistemas internos, el servidor lo escribimos nosotros.
- 2. Solo lectura por default. La escritura se habilita cuando escribir es el objetivo del caso de uso, no "por las dudas".
- 3. Credenciales del servidor, nunca del usuario final. El servidor tiene su propia identidad y sus propios permisos, y registra en nombre de quién actúa. Nadie pega su usuario y contraseña en un chat.
- 4. Registro de cada llamada. Qué herramienta se invocó, con qué argumentos y qué devolvió. Sin ese registro no hay forma de auditar un incidente ni de explicarle a nadie qué pasó.
Ninguna de las cuatro es cara. Las cuatro se saltean seguido.
¿Cuándo NO usar un servidor MCP?
Hay cuatro situaciones donde MCP es la herramienta equivocada, y reconocerlas antes ahorra un proyecto entero:
- El proceso corre solo y nadie pregunta nada. Si el disparador es un horario o un evento, va un orquestador o una tarea programada. Meter un modelo en el medio agrega costo y variabilidad sin agregar criterio.
- El volumen es alto y el resultado siempre es el mismo. Miles de operaciones idénticas por día se resuelven con una integración directa. Ahí el modelo es el cuello de botella.
- El dato está en papel o en un PDF escaneado. MCP no lee lo que no está estructurado. Primero va el reconocimiento de documentos, después se ve si hace falta MCP.
- El sistema no expone ninguna vía de acceso programático. Sin API, sin base accesible y sin un proveedor dispuesto a habilitar algo, no hay servidor MCP que valga. La conversación siguiente es con el proveedor del sistema, no con nosotros.
¿Cómo empezar?
El error más caro es arrancar por la infraestructura. El orden que funciona es al revés:
- 1. Elegí una pregunta concreta que hoy cueste horas. No "conectar el ERP", sino "saber en el momento cuánto debe un cliente y desde cuándo". Una pregunta, medible, que alguien hace todas las semanas.
- 2. Fijate si el servidor ya existe. Si el sistema es de mercado, probablemente sí. Si es propio, se desarrolla, y ahí recién aparece el presupuesto.
- 3. Definí permisos y alcance de datos antes de conectar nada. Qué puede leer, qué puede escribir, con qué identidad y con qué registro. Esta conversación va antes del desarrollo, no después del primer susto.
- 4. Probá con un equipo antes de abrir a la empresa. Un área, dos semanas, y la pregunta del punto 1 respondida o no respondida. Con eso ya sabés si el siguiente caso vale la pena.
Sobre el costo
Un servidor MCP a medida se cotiza por scope, porque depende de qué expone el sistema y de cuántas operaciones se habilitan. El pack mensual de Duotach arranca en USD 700. Si querés ver cómo se arma el desarrollo del lado técnico, está en desarrollo con Claude Code, y si preferís que revisemos tu caso, escribinos.
Preguntas frecuentes sobre servidores MCP
¿Qué es un servidor MCP en palabras simples?
Es un programa que expone los datos y las funciones de un sistema en un formato estándar, definido por el Model Context Protocol, para que un modelo de IA pueda consultarlos y operarlos. Puede correr en la máquina del usuario o en la nube, y cualquier asistente compatible lo consume sin desarrollo adicional.
¿Para qué sirve MCP en una empresa?
Sirve para que un asistente de IA consulte y opere los sistemas internos sin una integración a medida por cada herramienta. Los usos habituales son consultar el ERP en lenguaje natural, responder sobre documentación interna con la fuente citada, y ejecutar acciones (crear un ticket, actualizar un registro) desde el canal donde ya trabaja el equipo.
¿MCP es solo para Claude o funciona con ChatGPT?
Funciona con ambos. Al momento de la donación del protocolo a la Agentic AI Foundation, MCP tenía soporte de primera clase en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. Un servidor MCP se escribe una vez y lo consume cualquier cliente compatible.
¿Cuál es la diferencia entre MCP y una API?
Una API es la puerta de entrada a un sistema. MCP es un estándar sobre cómo describirle esa puerta a un modelo de IA: qué operaciones hay, qué parámetros toman y qué devuelven, en un formato que el modelo puede descubrir solo. Un servidor MCP normalmente se apoya en la API que ya existe.
¿Cuál es la diferencia entre MCP y RAG?
RAG indexa tus documentos y le da al modelo los fragmentos parecidos a la pregunta. MCP conecta al modelo con la fuente viva y le permite ejecutar acciones. Para responder sobre documentación conviene RAG, para consultar un dato actualizado o hacer algo en un sistema conviene MCP, y muchos proyectos usan los dos.
¿Es seguro conectar un servidor MCP a los datos de mi empresa?
Es seguro si se despliega con criterio. Los dos riesgos propios son el tool poisoning, catalogado por OWASP, y la inyección indirecta de prompts. Se mitigan con cuatro reglas: servidor propio para sistemas propios, solo lectura por default, credenciales del servidor y no del usuario, y registro de cada llamada.
¿Cuánto cuesta implementar servidores MCP?
Depende de qué expone el sistema. Conectar servidores que ya existen (Drive, Slack, una base PostgreSQL) es configuración. Construir uno a medida sobre un ERP o un sistema vertical es desarrollo y se cotiza por scope, según cuántas operaciones se habilitan y qué vía de acceso ofrece el sistema. Nuestro pack mensual arranca en USD 700.
¿Necesito un programador para usar servidores MCP?
Para usar servidores que ya existen, no: se agregan como conectores desde la aplicación, y en los planes Team y Enterprise el administrador decide cuáles quedan habilitados. Para exponer un sistema propio sí hace falta desarrollo, porque hay que definir qué operaciones se habilitan y con qué permisos.
¿Qué diferencia hay entre un servidor MCP local y uno remoto?
El local usa transporte stdio, corre en la misma máquina que la aplicación y atiende a un solo cliente, así que el dato no sale del equipo. El remoto usa Streamable HTTP, corre en la nube y atiende a muchos usuarios, con autenticación por bearer token, API key u OAuth. Para una empresa que quiere un punto único de control y auditoría, el remoto es el camino.
¿Quién controla el protocolo MCP hoy?
La Agentic AI Foundation, un fondo dirigido de la Linux Foundation, desde el 9 de diciembre de 2025. Fue creada por Anthropic, Block y OpenAI, con apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. Anthropic publicó el protocolo en noviembre de 2024 y lo donó a esa fundación para que la gobernanza quede fuera de una sola empresa.
La diferencia entre MCP y RAG la desarrollamos en RAG para empresas.
Conclusión
Un servidor MCP es la forma estándar de que un modelo de IA consulte y opere los sistemas de tu empresa. Hoy es un protocolo de la industria y no de un proveedor, la especificación vigente es la 2026-07-28, y buena parte del trabajo de integración ya está publicada y mantenida por terceros.
La pregunta que decide si te sirve es una sola: ¿hay alguien en tu empresa haciendo preguntas distintas cada vez contra un sistema al que hoy accede exportando planillas? Si la respuesta es sí, MCP es el camino. Si el proceso corre solo y siempre igual, no lo es, y hay opciones más baratas.
El paso siguiente no es un proyecto grande. Es elegir una pregunta cara, ver si el servidor ya existe, y probarla con un equipo. Si querés que revisemos qué sistemas tuyos se pueden conectar y cuáles no, escribinos o mirá cómo trabajamos Claude para empresas en Argentina.
Fuentes
Architecture overview (Model Context Protocol)
MCP joins the Agentic AI Foundation (blog del protocolo)
Donating the Model Context Protocol and establishing the Agentic AI Foundation (Anthropic)
Protecting against indirect prompt injection attacks in MCP (Microsoft)