El dashboard ismcpdead.com monitorea en tiempo real la adopción y sentimiento alrededor del Protocolo de Contexto de Modelos (MCP), el estándar abierto de Anthropic que permite que los LLM accedan a herramientas y datos de forma estándar. Según los datos del sitio, en abril de 2026 hay más de 10.000 servidores MCP indexados, el SDK se descarga 97 millones de veces mensualmente (combinado Python y TypeScript), y el crecimiento de servidores remotos se multiplica por 4 desde mayo de 2025. Pero la adopción sigue siendo cautelosa: mientras 72% de developers dicen que van a aumentar su uso de MCP en el próximo año, 50% cita seguridad como preocupación principal.
En 30 segundos
- MCP es un protocolo estándar para que los LLM accedan a herramientas; ismcpdead.com es un dashboard que rastrea su adopción y sentimiento de desarrolladores en tiempo real
- 97 millones de descargas mensuales del SDK (Python + TypeScript), 10.000+ servidores indexados, 4x crecimiento en servidores remotos desde mayo 2025
- 72% de builders esperan aumentar uso en 12 meses, pero 50% identifica seguridad como bloqueante principal y 38% dice que las preocupaciones de seguridad actualmente detienen su adopción
- Adopción confirmada en Block, Bloomberg, Amazon, Google DeepMind, OpenAI y herramientas como VS Code, Zed y Sourcegraph
- El desafío crítico: MCP es protocolo específico para LLMs, no reemplaza APIs, y los errores de integración vienen por confundir los dos
MCP (Protocolo de Contexto de Modelos) es un protocolo abierto que define cómo los modelos de lenguaje acceden a herramientas, datos y servicios externos de forma estandarizada, similar a cómo USB-C unificó los conectores. Lo creó Anthropic en noviembre de 2024, y desde entonces pasó de ser un experimento de Claude a un estándar que OpenAI, Google y otras empresas están adoptando oficialmente.
El punto ismcpdead.com (nota: el nombre es una broma — “¿MCP está muerto?” cuando obvio que no) es que monitorea este crecimiento en vivo. No es un blog de análisis. Es un dashboard que tira métricas duras sobre cuánta gente está usando MCP, qué sienten sobre él, y dónde están los fricciones.
De cero a 97 millones de descargas: la curva de adopción de MCP
Los números hablan. Según ismcpdead.com, el SDK de MCP (disponible en Python y TypeScript) suma 97 millones de descargas mensuales combinadas. Eso es MUY diferente de lo que pasaba hace 5 meses.
Mirá la timeline: en noviembre de 2024, cuando Anthropic lo anunció, prácticamente no había servidores MCP en la red. Hoy, hay 10.000+ indexados. Y acá viene lo interesante (porque no todas las métricas suben en línea recta): los servidores remotos — esos que cumplen funciones específicas, no son locales — crecieron 4 veces desde mayo de 2025. Es decir, la gente no solo agregó MCP; empezó a diseñar arquitecturas que asumen que MCP existe.
¿Y qué empresas se mueven? Block, Bloomberg, Amazon, Google DeepMind. OpenAI integró soporte oficial en marzo de 2025. Rot Financial Intelligence reportó 9.000 clones de su servidor MCP en apenas 5 días, con una conversión del 18.4%. Herramientas como VS Code, Zed y Sourcegraph ya tienen servidores MCP o experimentan con ellos.
El sentimiento: optimismo con gallo de pelea
Ahora, aquí es donde el dashboard revela algo importante que los comunicados de prensa no te dicen. Ya lo cubrimos antes en seguridad en protocolos de integración.
72% de los developers encuestados esperan aumentar su uso de MCP en los próximos 12 meses. 54% cree que va a convertirse en el estándar de facto (spoiler: probablemente sí). Pero — y esto es un PERO grande — 50% menciona seguridad como su principal preocupación. Y 38% dice que sus preocupaciones de seguridad les están bloqueando activamente la adopción ahora.
Eso no es una diferencia de opinión. Es fricción real. Los builders QUIEREN adoptar MCP. Les da miedo. Y es por razones concretas: token management, validación de permisos, auditoría de qué herramientas está llamando un modelo (especialmente si es remoto), y sandboxing. Si tu LLM está hablando con 20 servidores MCP simultáneamente, ¿vos tenés visibilidad sobre qué está pasando? ¿Cómo sabes que no está enviando data sensible a un servidor que no debería?
MCP vs APIs: no son lo mismo (y eso cambia todo)
Acá está el error más grande que veo en cómo la gente entiende MCP.
| Aspecto | APIs Tradicionales | MCP |
|---|---|---|
| Propósito | Comunicación cliente-servidor genérica | Integración específica LLM-herramientas |
| Auto-discovery | Documentación manual (OpenAPI, Swagger) | El servidor describe capacidades al iniciar; el modelo las entiende dinámicamente |
| Lenguaje | Requests HTTP, JSON estructurado | Instrucciones naturales del modelo (tool calling) |
| Contexto | Stateless, request-response | Stateful; el modelo acumula contexto entre llamadas |
| Overhead | Bajo; protocolo estándar desde 1999 | Mayor; requiere procesamiento de prompts + serialización |
| Cuándo usarla | Apps web, mobile, integraciones de software | Cuando un LLM necesita acceso composable a múltiples herramientas |
Las APIs siguen siendo la fundación. MCP es una capa de orquestación que se sienta encima de APIs. Si tu base de datos no tiene API REST, tampoco va a tener servidor MCP.
El diferencial real: MCP permite que un modelo vea qué herramientas tiene disponibles, entienda qué hace cada una leyendo la descripción, y las llame cuando las necesite (si es que las necesita). No hay que escribir prompts específicos diciendo “si el usuario pregunta por X, llamá al endpoint Y”. El modelo lo deducde. Eso suena simple, pero tiene implicaciones profundas para cómo diseñás sistemas.
Dónde duele: desafíos reales de implementación
La adopción de MCP en empresas tiene tres fricciones principales.
Overflow de contexto: Cuando conectás un LLM a 10, 15, 20 servidores MCP simultáneamente (ejemplo: servidor de CRM, servidor de datos de clientes, servidor de facturación, servidor de inventario, servidor de calendario), cada uno describe sus capacidades al modelo. Eso consume tokens. Rápido. Los modelos pueden terminar eligiendo la herramienta incorrecta simplemente porque el contexto se saturó y la descripción de la herramienta correcta quedó “prioridad baja” en los attention weights.
Documentación incompleta en los servidores: Un servidor MCP es tan útil como lo claras que sean sus descripciones. Si decís “esta herramienta recupera datos”, ¿el modelo entiende el formato? ¿Las limitaciones? ¿Qué pasa si hay un error? Muchos servidores tempranos tienen documentación débil porque sus autores pensaban “bueno, el modelo lo va a entender”. No lo entiende. Lo explicamos a fondo en integración de ChatGPT en herramientas.
Subís el servidor, el modelo lo prueba con un request confuso, falla, y termina siendo más un lastre que una herramienta útil (que no es poco).
Control de acceso y auditoría: Un modelo llamando a un servidor MCP que está en el interior de tu red corporativa genera preguntas incómodas. ¿Quién autoriza? ¿Cómo limitás qué datos puede pedir? ¿Cómo auditás? Las soluciones existen (tokens, role-based access, logging), pero no son triviales.
Errores comunes que ves cuando la gente implementa MCP
Confundir MCP con una API, punto. Y luego estar sorprendido de que MCP requiere que el modelo interprete instrucciones naturales en lugar de simplemente hacer un request HTTP. No, tu modelo no puede simplemente “llamar” al servidor — tiene que entender qué hace, cuándo lo necesita, y pasar los parámetros correctos. Eso requiere prompting, iteración y testing.
Asumir que tools = agents. Un servidor MCP que expone herramientas no hace que tu modelo sea un agent automáticamente. Un agent toma decisiones autónomas, evalúa resultados, reintenta. MCP simplemente da acceso a herramientas. Vos todavía tenés que diseñar la lógica de decisión. (Si es que eso cuenta como mejora.)
Esperar independencia total del modelo. El comportamiento de un servidor MCP depende fuertemente del modelo que lo llama. Claude en mayo de 2026 interpreta tool calls diferente de GPT-4o. Los mismos servidores, resultados distintos. Si tu arquitectura asume que el modelo es intercambiable, la vas a pasar mal.
Creer que MCP elimina la necesidad de RAG. No la elimina. Las complementan. RAG te trae contexto relevante a la memoria del modelo. MCP te da acceso a herramientas dinámicas. Usá ambas si tu caso de uso lo requiere. Más contexto en compatibilidad con modelos GPT.
Asumir que los servidores MCP son arquitectura centralizada como microservicios web. La verdad es más caótica. Hay servidores locales (tu máquina), remotos (servidores en tu red corporativa), públicos (GitHub, npm registry), y todo eso puede estar conectado a un mismo modelo. La topología no es predecible. El debugging es un dolor.
Qué significa para equipos en Latinoamérica
Si construís sistemas de IA (ya sea una startup, o un equipo interno en una empresa), MCP es el futuro que ya está acá. No es una opción dentro de 3 años. OpenAI lo adoptó. Google está integrando. Los browsers (Zed, VS Code) lo soportan.
El tiempo para aprender MCP ahora es cuando hay guías, cuando los errores no te destrozan la startup, cuando aún hay diferenciación en cómo lo implementás.
¿Vos qué estás construyendo? ¿Un chatbot para soporte? MCP te deja conectar directamente a tu CRM, tu knowledge base, tus ticketing system. Que el modelo vea qué tiene disponible y lo use solo cuando sea necesario. Sin middleware. ¿Herramienta interna de análisis de datos? MCP conecta el modelo a tus bases de datos, dashboards, herramientas de query sin que vos tengas que escribir 500 líneas de glue code.
El catch: necesitás entender los problemas de seguridad. Necesitás documentar bien. Y necesitás estar listo para iterar cuando las cosas no salgan como esperabas.
Preguntas Frecuentes
¿MCP es un reemplazo para APIs?
No. MCP está construido sobre APIs. Si tu servicio no tiene API, tampoco va a tener servidor MCP. Lo que MCP agrega es una capa de descubrimiento y orquestación específica para modelos de lenguaje. Tu API puede existir sin MCP; tu servidor MCP no. Tema relacionado: alternativas como Gemini en adopción.
¿Qué tan seguro es MCP en el contexto de datos sensibles?
MCP en sí es un protocolo; la seguridad depende de cómo lo implementés. Necesitás autenticación (tokens, OAuth), autorización (qué puede llamar cada herramienta), logging (quién llamó qué), y sandboxing (el modelo no puede acceder a recursos que no debería). Muchas implementaciones tempranas perdieron seguridad por no hacer esto. No es problema de MCP; es problema de pereza en la implementación.
¿Puedo usar MCP hoy o debería esperar a que madure más?
Depende de tu riesgo de tolerancia. Si estás experimentando en un equipo interno de IA, usalo ahora. Si estás en producción sirviendo millones de requests, esperá a 2027 cuando haya estándares de seguridad más definidos. El crecimiento que mide ismcpdead.com es real; el producto sigue siendo temprano.
¿Qué modelo debo usar para MCP: Claude, GPT-4, Gemini?
Hoy, Claude (especialmente Claude 3.5 Sonnet) es la mejor opción porque Anthropic lo diseñó para MCP. OpenAI agregó soporte en GPT-4 en marzo de 2025, así que ese también funciona. Gemini tiene herramientas propias que cumplen un rol similar pero no es exactamente MCP. Probá con lo que tengas; los resultados varían.
¿Es ismcpdead.com una fuente confiable de datos sobre adopción?
Sí, pero con asterisco. Tira números sobre descargas de SDK y servidores indexados, que son hechos verificables. El sentimiento (porcentaje de builders preocupados por seguridad) es extraído de encuestas a la comunidad y tiene el sesgo típico de cualquier survey en internet: responden los que tienen opinión fuerte. No es estadística científica, pero es tendencia real.
Conclusión
MCP no está muerto. MCP está acá, creciendo 4x en servidores remotos, alcanzando 97 millones de descargas mensuales, e integrándose en OpenAI, Google y herramientas que usás todos los días. El dashboard ismcpdead.com (un nombre que es una broma privada de la comunidad de IA) documenta esto en tiempo real.
Lo que cambió es que ahora sabemos que la adopción no es teórica. Hay desafíos reales — seguridad, documentación, overflow de contexto — pero no son showstoppers. Son problemas de implementación que la comunidad está resolviendo.
Si estás construyendo sistemas con LLMs, aprendé MCP ahora. No porque sea perfecto — no lo es — sino porque es el estándar que dominará durante los próximos 3-5 años. Los que entienden bien van a tener ventaja. Los que confunden MCP con APIs van a perder tiempo y dinero.