Sigo prefiriendo MCP sobre Skills: aquí está el por qué

MCP (Model Context Protocol) sigue siendo superior a Skills para dar acceso real a datos y servicios externos, según David Mohl. Mientras Skills funcionan bien para instrucciones y reasoning, MCP es la arquitectura ganadora para integraciones: reduce consumo de tokens de 77k a 8.7k, no inflaciona el contexto en conversaciones largas, y maneja determinismo en ejecución. En 2026 hay 10k+ servidores MCP activos con 97M descargas mensuales del SDK.

La verdad es que existe una narrativa instalada en la industria: “MCP está muerto, Skills son el futuro”. Ponele que entrás a X cualquier día y ves a alguien diciendo que MCP es cosa del pasado, que ya nadie lo usa, que Skills es el estándar ahora. La realidad? Bastante más matizada. David Mohl, que es un usuario pesado de IA (usa Claude Code, Codex, Gemini para codificar; confía en ChatGPT, Claude y Perplexity para gestionar prácticamente todo), acaba de escribir un articulo donde dice exactamente lo contrario: prefiere MCP, y bastante, porque resuelve un problema que Skills no toca.

Antes que nada: MCP (Model Context Protocol) es un protocolo abierto desarrollado por Anthropic que permite a los LLMs acceder a datos y servicios externos a través de una arquitectura client-server basada en JSON-RPC, sin cargar todo el contexto en el prompt.

¿Qué es MCP? Explicación del Protocolo de Contexto de Modelo

MCP se lanzó en noviembre de 2024 como respuesta a un problema real: los LLMs estaban de moda, pero conectarlos con datos y sistemas reales era un quilombo. Cada integración requería su propio wrapper, su propia lógica, su propia forma de comunicarse. Anthropic miró eso y dijo “esto necesita un estándar”.

La idea es simple pero elegante. Imaginate que el LLM es un cliente y el sistema externo es un servidor. MCP es el “USB-C de la IA” (así lo describió Anthropic): una interfaz universal. El LLM no necesita saber cómo funciona PostgreSQL, Notion, tu ERP o GitHub. Solo necesita conocer el protocolo.

¿Cómo funciona internamente? JSON-RPC bidireccional. El cliente (el LLM o la aplicación que lo envuelve) puede hacer requests al servidor MCP pidiendo acceso a recursos, invocando herramientas, u obteniendo prompts predefinidos. El servidor responde con datos estructurados. No hay magia, no hay alucinaciones mágicas. El contrato es claro, determinista.

Hoy en 2026, según el repositorio oficial en GitHub, hay más de 10,000 servidores MCP en funcionamiento, y el SDK se descarga casi 97 millones de veces mensuales. Si MCP estuviese “muerto”, esos números dirían otra cosa.

¿Qué son Skills en Claude? Diferencia conceptual clave

Skills es más reciente. Anthropic la lanzó a fines de 2025, y es un enfoque diferente. No es infraestructura, es contenido. Skills son instrucciones dinámicas cargadas en el prompt que enseñan al modelo cómo usar herramientas, frameworks o conceptos específicos, sin necesidad de reentrenar o fine-tune.

La idea es elegante: en vez de que todos los usuarios tengan el mismo contexto permanente (que satura rápido), vos cargás solo lo que necesitás. ¿Necesitás que Claude sepa usar tu CLI de deploy? Metele un Skill. ¿Que sepa las reglas de tu startup? Otro Skill. Así el modelo no gasta tokens en conocimiento que no va a usar.

El enfoque está centrado en reasoning y instrucciones. Skills no te dan acceso a datos reales en tiempo real. Te dan un manual, una guía operativa para que el modelo razone mejor sobre cómo usar ciertas herramientas. Es más like “enséñale la receta” que “conéctalo al horno”. Lo explicamos a fondo en seguridad en entornos corporativos.

Diferencias arquitectónicas: MCP vs Skills

Acá viene lo bueno, porque la diferencia técnica es donde se ve el quilombo real.

El dato que nadie menciona: si tenés 50 herramientas diferentes, usar MCP Tool Search reduce el consumo de tokens de 77,000 a 8,700 (según el reporte de Anthropic). Vos callate y leé eso de nuevo. Seis veces menos contexto. Eso es el tipo de mejora que importa en producción.

Con Skills, si mandás todos tus 50 skills en un prompt, cada uno suma tokens. Conversación larga? Problema. Múltiples Skills complejos? Peor. Tenés que empezar a strategizar sobre cuál skill cargas en cada conversación. Es admisión de que el enfoque tiene un ceiling.

Casos de uso reales: Cuándo usar cada uno

La pregunta importante no es “cuál es mejor”. Es “cuál resuelve tu problema específico”.

MCP gana cuando: acceso a datos en tiempo real

Tenés un ERP financiero con 5 años de data sobre transacciones, clientes, flujos. Claude necesita hacer consultas como “dame todos los clientes que compraron en marzo” o “cuál es el flujo promedio de facturas por cliente”. Eso vive en PostgreSQL, Oracle, o lo que sea. Acá necesitás MCP. Conectás el servidor MCP a la base, el LLM hace queries contra él, y obtenés respuestas determinísticas de datos reales. No alucinaciones. No “la verdad es que supongo que…”.

Otro: integración con GitHub. Querés que el modelo sepa qué PRs hay abiertas, qué commits se hicieron hoy, cuáles son los issues pendientes. Eso cambia minuto a minuto. Skills no sirven acá. MCP, sí.

Skills ganan cuando: lógica e instrucciones complejas

Trabajás en una startup fintech y tenés reglas de negocio retorcidas: “si el cliente es gold y la transacción es menor a X, aplicá descuento Y, pero solo si el monto total del mes no excede Z, salvo que sea un cliente desde antes de 2024”. Eso es reasoning puro. Metele eso en un Skill, y el modelo entiende la lógica, puede razonar sobre ella, argumentar por qué sí o no aplica a cada caso. Una Skill ahí reduce confusión.

Otro: documentación de tu framework interno. Tenés un patrón de código que todos usan, pero es idiosincático. Metele en un Skill cómo usarlo, cuándo no usarlo, qué errores comunes comete la gente. El modelo aprende sin saturar con cada conversación.

El combo ganador: MCP + Skills

La realidad es que no son competidores. Son complementarios. MCP provee datos reales desde fuentes externas. Skills proveen instrucciones sobre cómo razonar con esos datos. Usas los dos juntos, y ahí sí tenés algo potente. Ya lo cubrimos antes en como sucede con ChatGPT.

Ejemplo: un LLM necesita analizar transacciones de un ERP (datos vía MCP) siguiendo reglas de compliance de tu firma (instrucciones vía Skills). El modelo obtiene datos reales, razona sobre ellos usando lógica pre-definida, y devuelve decisiones confiables. Eso es arquitectura ganadora.

Por qué MCP sigue siendo superior para integraciones

Ahora el argumento de David Mohl, y por qué lo compro: MCP ganó porque resolvió un problema que Skills no toca, que es el acceso confiable, determinista, a datos externos sin saturar contexto.

Las tres ventajas que nadie menciona:

1. No consumís contexto en conversaciones largas. Vos estás chateando con Claude durante 2 horas, yendo y viniendo sobre un análisis de datos. Cada 5 minutos el modelo necesita más data del ERP. Con Skills, estarías reloadeando el skill cada vez, quemando tokens. Con MCP, el servidor está ahí. El LLM lo consulta. No entra en el contexto conversacional. Es como llamar a un servicio HTTP: no te importa el costo de la llamada per se, solo que fue rápida.

2. Determinismo y confiabilidad. MCP se basa en contrato JSON-RPC. El servidor dice “esto es lo que puedo hacer” (capabilities), el cliente pide algo específico, el servidor responde o falla limpiamente. No hay espacio para alucinaciones. Con Skills (que es reasoning puro), el modelo siempre puede interpretar una instrucción de forma inesperada. Mismatch entre lo que querías y lo que el modelo entendió. En producción, eso es un riesgo.

3. Las críticas a Skills en escala. Imaginate que sos una empresa con 50 servicios diferentes que los LLMs necesitan consultar. Con Skills, tenés 50 skills. Cada uno suma tokens al prompt. Cada conversación, tenés que decidir cuáles cargas. Es como intentar jugar al fútbol con una mochila de 50 kg. Técnicamente podés, pero es un quilombo. Con MCP, tenés 50 servidores que hablan el mismo protocolo. El cliente pregunta “¿qué podés hacer?” y cada uno dice su lista. El LLM invoca lo que necesita. No hay inflación de contexto.

¿Eso significa que Skills son malas? No. Significa que la narrativa de “Skills es el nuevo estándar universal” es simplista. Son herramientas para problemas diferentes.

¿MCP está muerto? El debate de 2026

La narrativa en X es clara: MCP era el futuro, pero llegó Skills y cambió todo. Algunos incluso dicen que MCP es cosa del pasado.

Acá está el dato que la mayoría ignora: en abril de 2026, según el repositorio oficial, hay más de 10,000 servidores MCP activos. El SDK tiene casi 97 millones de descargas mensuales. Si estuviese muerto, esos números no existirían.

¿Por qué la narrativa entonces? Ponele que pasa por varios factores:

Skills es más nuevo, más fresco. La gente nueva en la industria lo escucha primero y asume que es “lo nuevo”. MCP tiene un año y medio, así que algunos lo ven como “viejo”. El hype narrativo pesa. Alguien en X dice “MCP is dead” con confianza, se viraliza, y de repente medio mundo lo repite. Psicología de red social pura (que no es poco).

Pero el uso real? MCP sigue ganando en casos donde importa: Cursor, Claude Desktop, Cline (VS Code), Postman, Windsurf. Todas las herramientas serias que necesitaban integraciones reales apostaron a MCP porque resuelve un problema que Skills no toca.

Implementación: Componentes y herramientas de MCP

Si te das cuenta de que necesitás MCP (probablemente para acceso a datos externa real), ¿por dónde empezás? Te puede servir nuestra cobertura de en los modelos GPT.

MCP tiene tres capacidades principales:

Resources (Recursos): datos estáticos o dinámicos que el LLM puede leer. Ponele, un documento, un conjunto de datos, un schema de base de datos. El servidor dice “tengo estos recursos” y el cliente puede leerlos.

Tools (Herramientas): acciones ejecutables. El LLM dice “quiero hacer X”, el servidor ejecuta X y devuelve el resultado. Ejemplo: “insertá una fila en esta tabla”, “llamá a esta API”, “generá un reporte”.

Prompts (Plantillas): prompts predefinidos que el servidor puede servir. Útil para estandarizar cómo se le pide al LLM que haga ciertas cosas.

¿Cómo armás un servidor MCP desde cero? La mayoría de la gente usa SDKs: Anthropic tiene la especificación 2025-11-25 documentada. Podés hacerlo en Python, Node, Rust. El ejemplo clásico: conectás tu base de datos PostgreSQL, definís qué tablas y queries quieres exponer, armás el servidor MCP que wrappea eso, y listo. Claude puede consultar tu base directamente.

El ecosistema está maduro. Hay servers MCP ya hechos para Notion, Google Drive, GitHub, OpenAI, Stripe, Slack. Si necesitás integración con algo popular, probablemente ya exista.

El futuro de la integración: Patrones de arquitectura ganadores

Mirando los numeros de 2026, el patrón que está ganando no es “MCP o Skills”, es ambos. MCP provee datos, Skills proveen instrucciones. El LLM tiene acceso real a información externa (datos vivos) y lógica de reasoning (cómo pensar sobre esos datos). Eso es arquitectura.

Para empresas en Latinoamérica (startups de IA, agencias tech, consultoras que usan LLMs), esto importa porque significa que podés construir sistemas más confiables. No estás delegando todo al modelo. Le das datos reales vía MCP y reglas claras vía Skills, y el modelo razona dentro de esos límites. Es como la diferencia entre un empleado sin información (que falla) y uno con datos + procedimiento (que lidia).

El peligro es la simplificación. Si tu stack de herramientas asume que todo va vía Skills (cargar todo en el prompt), te vas a choque con límites de contexto, costos, y latencia. Pero si diseñás pensando en “MCP para datos, Skills para lógica”, te ahorras problemas.

Errores comunes: Qué no hacer

Error 1: Asumir que Skills reemplaza acceso a datos en tiempo real

Skills es estático (o semi-dinámico). Si tu data cambia cada minuto, Skills no sirve. Un Skill que dice “los precios vigentes son…” será obsoleto en una hora. MCP conectado a tu pricing engine devuelve precios actualizados. No es lo mismo.

Error 2: Sobrecargar el contexto con Skills complejos

Metiste 15 Skills en el prompt, cada uno con 200 líneas de instrucciones. Consumiste 40k tokens antes de que el usuario escriba algo. Eso es un derroche. Si necesitás 15 integraciones, probablemente debería ser MCP (que no inflaciona el contexto), no Skills. Relacionado: herramientas como Gemini.

Error 3: No considerar que MCP y Skills son complementarios

La mentalidad de “elegí uno” es un error. Ambos tienen lugar. MCP para datos, Skills para instrucciones. Usá ambos y te ahorras años de dolor.

Preguntas Frecuentes

¿Qué es mejor MCP o Skills para mi proyecto?

Preguntate esto: ¿el hard part es acceso a datos reales o reasoning? Si es datos (ERP, base de datos, APIs con info dinámica), MCP. Si es lógica (instrucciones, reglas, reasoning complejo), Skills. La mayoría de los proyectos necesita ambos.

¿Cuál es la diferencia real entre MCP y Skills?

MCP es protocolo. Skills es contenido. MCP te conecta con datos externos sin inflacionar contexto. Skills te cargan instrucciones en el prompt para que el modelo razone mejor. Son herramientas para problemas diferentes.

¿Por qué algunos expertos prefieren MCP sobre Skills?

Porque MCP resuelve un problema concreto de escala: acceso a datos reales sin sacrificar contexto. En producción, eso mata a todo lo demás. Si necesitás 50 integraciones y querés conversaciones largas sin quemar tokens, MCP gana.

¿MCP está muerto o sigue siendo relevante en 2026?

Muy vivo. 10k+ servidores MCP, 97M descargas mensuales del SDK. La narrativa de “está muerto” es simplemente hype sobre Skills siendo más nuevo. Ambos crecen porque resuelven cosas diferentes.

¿Cuándo debo usar MCP y cuándo Skills?

MCP: cuando necesitás acceso confiable a datos externos que cambian (bases de datos, APIs, sistemas en vivo). Skills: cuando necesitás que el modelo entienda lógica de negocio compleja o instrucciones específicas (procedimientos, reglas, reasoning). Idealmente, usá ambos en el mismo sistema.

Conclusión

La narrativa instalada (“MCP está muerto, Skills son el futuro”) es simplista. Son herramientas para problemas diferentes, y ambas están vivas en 2026. MCP sigue ganando porque resuelve un problema que Skills no toca: acceso determinista a datos reales sin saturar contexto.

Si estás evaluando cómo dar a un LLM acceso a tus sistemas, pensá en dos capas: una para datos (MCP), otra para lógica (Skills). Eso es arquitectura ganadora, y es lo que están haciendo las empresas serias.

¿La clave? No entres en la guerra de las narrativas en X. Entendé qué resuelve cada cosa y usá ambas donde tengan sentido. Eso te ahorra meses de pain.

¿Cuántos tokens gastás con MCP comparado con Skills?

Con MCP gastás mucho menos. Si tenés 50 herramientas, MCP reduce consumo de 77.000 a 8.700 tokens (6 veces menos). Con Skills, cada uno suma tokens al prompt, lo que infla rápidamente en conversaciones largas o múltiples skills complejos.

¿MCP sigue siendo relevante en 2026?

Totalmente. Hay 10.000+ servidores MCP activos con 97 millones de descargas mensuales del SDK. La narrativa de que está muerto es falsa. El problema es que Skills y MCP resuelven problemas diferentes, no que uno haya reemplazado al otro.

¿Es mejor usar solo MCP, solo Skills, o ambos?

El combo es lo mejor. Usá MCP para acceso a datos en tiempo real (ERP, bases, APIs) y Skills para instrucciones complejas y lógica de negocio. Juntos ofrecen soluciones más potentes y confiables que cualquiera por separado.

Fuentes

• I Still Prefer MCP Over Skills — David Mohl, 2 de abril 2026. Análisis detallado de por qué MCP sigue siendo superior para integraciones de datos
• Model Context Protocol en GitHub — Especificación oficial y repositorio de Anthropic con 10k+ servidores activos
• Especificación oficial de MCP 2025-11-25 — Documentación técnica completa del protocolo
• Skills Explained — Anuncio oficial de Anthropic sobre cómo funcionan Skills en Claude
• MCP vs AI Agent Skills: A Deep Dive — MarkTechPost, 13 de marzo 2026. Comparación técnica profunda