Sigo prefiriendo MCP sobre Skills

• MCP es una interfaz estándar basada en abstracción de API que permite a los LLM solicitar tareas sin conocer la estructura interna de la herramienta, y admite uso remoto y actualizaciones automáticas
• La arquitectura Zero-Install, la autenticación OAuth y la seguridad mediante sandboxing reducen la carga de instalación y los problemas de permisos, ofreciendo el mismo entorno en cualquier plataforma
• En cambio, Skills genera mucha fricción en entornos reales de ejecución por su dependencia de instalación vía CLI, la complejidad de autenticación y despliegue, y los problemas de compatibilidad entre plataformas
• Skills debe verse como una capa de conocimiento y MCP como una capa de conexión; al interactuar con sistemas externos, el LLM debería usar MCP, mientras que para transmitir conocimiento procedimental conviene usar Skills
• Servicios de túnel en la nube como MCP Nest permiten acceder remotamente a servidores MCP locales, por lo que se consideran clave para construir un entorno de integración de IA estandarizado

---

Ventajas de MCP

• Model Context Protocol (MCP) se basa en una estructura de abstracción de API que permite a un LLM ejecutar tareas simplemente haciendo solicitudes, sin necesidad de entender el funcionamiento interno de las herramientas
  • Ejemplo: cuando un LLM interactúa con DEVONthink, llama a devonthink.do_x() y el servidor MCP se encarga de todo el procesamiento
• Permite uso remoto Zero-Install: el cliente solo necesita indicar la URL del servidor MCP para funcionar de inmediato, sin instalaciones adicionales
• Admite actualizaciones automáticas: si un servidor MCP remoto se actualiza con nuevas herramientas o recursos, todos los clientes pueden usar al instante la versión más reciente
• La autenticación basada en OAuth refuerza la seguridad y evita que el usuario tenga que administrar tokens manualmente
• Tiene alta portabilidad, ya que se puede acceder al mismo servidor MCP desde Mac, móvil, web y otros entornos
• Su estructura con sandboxing limita los permisos de ejecución directa sobre el entorno local y solo expone una interfaz controlada
• Gracias a la búsqueda inteligente y actualización automática, solo se cargan las herramientas necesarias y, aun en instalaciones locales, se pueden actualizar automáticamente al ejecutarse

Límites y fricción de Skills

• Skills es útil para enseñar a un LLM cierto conocimiento o formas de uso, pero cuando llega el momento de ejecutar acciones reales, la dependencia del CLI se vuelve un problema
• La mayoría de los Skills requieren instalar un CLI aparte, pero las versiones web de ChatGPT, Perplexity o Claude no pueden ejecutar CLI
• Esto provoca problemas como los siguientes
  • Complejidad de despliegue: el CLI debe distribuirse y mantenerse como binario, NPM, uv, etc.
  • Problemas de manejo de secretos: los tokens de autenticación se guardan en texto plano en archivos .env, o la autenticación se pierde cuando la sesión se reinicia
  • Fragmentación del ecosistema: como la instalación y actualización de Skills cambia según la plataforma, aparecen problemas de compatibilidad y errores al parsear YAML
  • Desperdicio de contexto: aunque el LLM solo necesite llamar una función, debe cargar todo SKILL.md
• Un Skill que incluya la instrucción “instala primero el CLI” añade complejidad innecesaria; reemplazarlo por un MCP remoto es más eficiente

Criterios para elegir la herramienta adecuada

• Cuándo usar MCP: cuando un LLM necesita conectarse con sistemas externos como sitios web, servicios o aplicaciones, debe usarse como interfaz estándar
  • Ejemplo: Google Calendar debería procesar autenticación y ejecución mediante un MCP remoto basado en OAuth, sin exigir instalación de CLI
  • También sería ideal que Chrome, Hopper, Xcode y Notion ofrecieran endpoints MCP integrados para controlar sus funciones
• Cuándo usar Skills: cuando el objetivo es transmitir conocimiento puro y contexto
  • Para enseñar cómo usar herramientas ya instaladas (curl, git, gh, gcloud)
  • Para estandarizar terminología interna, flujos de trabajo y estilo de redacción dentro de una organización
  • Para compartir conocimiento procedimental como procesamiento de PDF o manejo de secretos (por ejemplo, cómo usar fnox)
• Skills debe entenderse como una capa de conocimiento, y MCP como una capa de conexión

Conectores y manuales

• Para distinguir claramente el rol de Skills y MCP, se propone llamar a Skills manuales para LLM (LLM_MANUAL.md) y a MCP conectores (Connector)
• Ejemplos reales en operación
  • mcp-server-devonthink: servidor MCP local que permite al LLM controlar DEVONthink directamente
  • microfn: ofrece MCP remoto en mcp.microfn.dev
  • Kikuyo: ofrece MCP remoto en mcp.kikuyo.dev
  • MCP Nest: servicio que permite acceso remoto a servidores MCP locales mediante túneles en la nube (mcp.mcpnest.dev/mcp)
• En algunos proyectos también se ofrece un Skill para CLI, pero resulta más útil un Skill que explique cómo usar MCP
  • El Skill funciona como una capa de conocimiento que explica funciones de MCP, relaciones entre herramientas y cuándo usarlo
  • MCP se encarga de la conexión y la ejecución reales
• Esta combinación permite que el LLM aproveche MCP de forma eficiente sin pasar por pruebas y errores repetitivos

Uso combinado de MCP y Skill

• Los errores de formato de fecha, límites de búsqueda y otros patrones poco intuitivos detectados al usar MCP pueden organizarse en un Skill para reutilizarlos
• El Skill creado de esta forma funciona como una chuleta de MCP y ayuda al LLM a operar con precisión sin desperdiciar tokens innecesariamente
• Mediante la carpeta .claude/skills se pueden mantener instrucciones de comportamiento de IA por proyecto y gestionar procedimientos frecuentes en forma de dotfiles
• El futuro de la integración de IA depende de interfaces estandarizadas (MCP), y conviene evitar enfoques fragmentados basados en CLI
• Se espera que grandes servicios como Skyscanner, Booking.com, Trip.com y Agoda.com ofrezcan MCP oficial

Introducción a MCP Nest

• MCP Nest es un servicio que permite acceder remotamente a servidores MCP solo locales (como Fastmail o Gmail) mediante túneles en la nube
• Puede usarse de la misma forma en clientes compatibles con MCP como Claude, ChatGPT y Perplexity
• Permite mantener el mismo entorno MCP en todos los dispositivos sin exponer directamente la máquina local

[jujumilk3]

Simplemente son dos cosas completamente distintas, ¿por qué siguen saliendo este tipo de comentarios?

[xguru]

Porque tengo que promocionar MCP Nest al final del texto... jajaja. Parece que las afirmaciones comparativas están ganando bastante fuerza.

[jjw9512151]

Skills es la esgrima y MCP es la espada... tienen usos distintos y ambos son necesarios.

[ide127]

Skills y MCP cumplen roles distintos, pero siento que este tipo de textos sigue generando confusión.

[ide127]

Ya de por sí, la industria de la IA está en plena tormenta y llena de falsos profetas.

[GN⁺]

Opiniones en Hacker News

• Lo que quiero enfatizar es que, más que en la preferencia personal, hay que enfocarse en el diseño de herramientas que necesitan los LLM para trabajar de forma óptima
  MCP más bien agrega fricción. Por ejemplo, si trabajas con sistemas embebidos, basta con hacer que el LLM tenga una interfaz de monitoreo basada en CLI para depurar, reiniciar, ejecutar el emulador, etc. directamente, y documentar su uso en un archivo de skill
  Si la tarea es simple, MCP es innecesario. Por ejemplo, cosas como git o calcular costos de AWS el LLM ya las maneja bien. Solo conviene crear y documentar herramientas propias para sistemas complejos

  • Da la impresión de que en la discusión sobre MCP se están mezclando demasiados conceptos. La clave es la persistencia de sesión
    Si es algo de una sola vez, basta con CLI o API, pero si se necesita acceso persistente, un servidor MCP sí resulta útil
    Un MCP bien armado le enseña al agente cómo usarlo sin desperdiciar prompt. Imitar acceso persistente con un archivo de skill es ineficiente. MCP es la forma más efectiva de integrar herramientas externas en la sesión del agente
  • MCP y skill son complementarios. Verlos como opuestos es un malentendido
  • La cadena de herramientas actual para LLM todavía parece una etapa de transición sin estandarización. En vez de meter información en distintos lugares como .md o skill, hace falta un estándar que la organice en el lugar óptimo mediante bucles automatizados de autorreflexión
  • Yo también sigo un enfoque parecido. La mayoría de las herramientas CLI las hizo Claude directamente, y casi no uso IDE
    Incluso reemplacé las funciones de refactorización de JetBrains con scripts, y la velocidad de la sesión bajó de 5 minutos a 10 segundos
    Todavía no uso MCP para nada. La combinación REST + Swagger + codegen + Claude + skill me basta
  • La ventaja de MCP es el control de permisos. Por ejemplo, si no quieres que la IA tenga permisos de escritura en git, puedes limitar lo que se expone con MCP. Solo con READ_ONLY_SKILL no alcanza

• Esta discusión al final se reduce a desarrollador individual vs colaboración a escala organizacional
  Si trabajas solo y quieres un ciclo de retroalimentación rápido, CLI es mejor; si necesitas control y consistencia a nivel organización, entonces conviene MCP
  Hoy MCP consume mucho contexto, pero se espera que mejore con divulgación progresiva

  • En las organizaciones existe el problema de que controlar el acceso con MCP es difícil. Una persona por error quizá borre dos cosas, pero un agente puede eliminar miles en un instante. Con CLI se puede limitar el alcance de acceso y es más seguro
  • El desperdicio de contexto es un problema de implementación del cliente. La carga progresiva se puede hacer incluso sin cambiar la especificación
  • MCP y CLI son herramientas con objetivos distintos, y son más potentes cuando se usan juntas

• Yo quiero un agente que use directamente las herramientas CLI existentes en vez de una API
  Si ya uso CLI en local, no hay razón para agregar MCP. Tampoco quiero modelos remotos
  Si hace falta llamar una API, con skill alcanza

  • Yo también meto comandos curl directamente en skill para llamar APIs personalizadas. El LLM maneja bien ese tipo de cosas
  • Pero para el manejo de secretos, MCP es más seguro. Si primero levantas el servidor MCP, la clave no queda expuesta en el entorno del agente
  • MCP funciona como una capa de frontera de seguridad entre el agente y el mundo externo. No siempre hace falta, pero es útil
  • En algunos entornos el LLM puede no tener acceso a CLI. En ese caso, invocar CLI vía skill no sirve de nada
  • También están los problemas de autenticación (authn) y autorización (authz). MCP permite controlarlos como middleware

• MCP y Skill no son una relación de suma cero
  MCP se encarga de una interfaz estandarizada en la capa de infraestructura, y Skill del contexto de comportamiento específico del proyecto
  Si combinas ambos, obtienes estabilidad y flexibilidad

  • MCP al final no deja de ser una forma de envolver CLI. De hecho, MCP tiene más sobrecarga de contexto
  • Algunos MCP de pago sí tienen valor real. Por ejemplo, un MCP para búsqueda web es más cómodo que poner a correr tu propio crawler
  • En agentes alojados en la nube, la combinación Skill + MCP es una estructura clave. Facilita la autenticación y la gestión de dependencias
  • El autor también apoya esta combinación. MCP tiene alta portabilidad y se puede usar igual en ChatGPT, Claude, Perplexity, etc.
  • Skill puede ser ignorado por el LLM, pero las políticas de MCP tienen capacidad de enforcement del lado del servidor

• La mayor parte de la discusión gira en torno a personas que ejecutan agentes de programación en local
  En ese entorno, Skill resulta más cómodo, pero los usuarios comunes usan servicios en la nube como ChatGPT
  En ese caso, MCP pasa a ser la opción por defecto. Su punto fuerte es la autenticación y el acceso remoto

  • Pero algunos creen que MCP no es más que un wrapper ruidoso de API
    Hay que levantar un servidor, y para el LLM eso termina siendo más carga. Skill es más simple porque codifica la documentación de la API en un formato amigable para LLM
  • También hubo una respuesta diciendo que la afirmación de que “la mayoría de los usuarios no usan agentes locales” necesita sustento
  • Incluso hubo una broma corrigiendo el typo ‘agronomic’ por ‘ergonomic’

• Yo prefiero Skill, porque permite reutilizar tal cual las herramientas CLI que usan las personas
  Skill es documentación legible y editable por humanos, así que LLM y humanos comparten las mismas herramientas
  En cambio, con MCP hay que crear una API nueva solo para el LLM y mantener la documentación por separado
  Skill se carga solo cuando hace falta, así que mantiene limpio el contexto

• Quienes defienden “solo Skill” suelen ser no técnicos, y quienes insisten en “solo CLI” suelen ser desarrolladores individuales
  MCP encaja mejor en entornos enterprise. Estandariza autenticación e interfaces

  • Mucha gente tiene una visión negativa de MCP por la inestabilidad de JIRA MCP. Un skill basado en acli resultó más estable
  • Yo construí directamente un MCP interno para mi empresa. Le conecté autenticación de Google Workspace, y así Claude puede consultar datos internos o desplegar apps de forma segura
    MCP es fácil de actualizar y desplegar, así que también tiene buena accesibilidad para no técnicos
  • También está la postura de que, como las empresas ya tienen sistemas internos de autenticación, CLI es mejor
    MCP al final no es más que una estructuración de un subconjunto de la API
  • MCP se puede levantar rápido. Una cadena Codex → LiteLLM → VLLM → MCP se arma en minutos
  • Yo veo los sistemas SaaS existentes como legado. Un SQL DB local es más eficiente que una API con acceso difícil a los datos
    MCP no es más que otro protocolo RPC, y el problema de autenticación sigue sin resolverse

• Yo creo que MCP es necesario por la irracionalidad humana
  Muchas organizaciones todavía no ofrecen API ni CLI. MCP llena esa desconexión digital
  Las cadenas de reporte y la política interna de las empresas frenan la automatización, y MCP puede rodear ese obstáculo

  • Yo también estoy de acuerdo. Si los agentes de tus colegas pudieran colaborar entre sí, la digitalización organizacional sería mucho más sencilla. MCP es bueno porque oculta esa complejidad de cableado

• Skill tiene el problema de context bloat porque hay que meter toda la documentación en el contexto
  MCP sufre algo parecido, pero con búsqueda de herramientas se puede hacer carga progresiva
  El problema más grande es que la salida de MCP entra directo al contexto del agente. Si llamas servicios MCP a través de CLI, puedes filtrar o cachear

  • También hubo quien respondió: “entonces, ¿por qué no usar simplemente solicitudes HTTP?”
  • El autor explicó que las versiones recientes de MCP ya lo resuelven con lazy loading basado en descubrimiento de herramientas. Claude Code usa subagentes para evitar que los logs se desborden
  • Yo lo resolví envolviendo el MCP local con una caché en memoria. Le doy un ID a la salida de cada herramienta, y luego llamo otras herramientas con ese ID. Funciona bien para ahorrar tokens y mejorar la velocidad

• Skill sirve bien para capturar conocimiento intuitivo, y MCP es más adecuado para automatización repetible
  Si el LLM está escribiendo el mismo script varias veces, lo eficiente es fijarlo como herramienta

  • La mayoría de los procesos deberían preprocesarse con scripts, y dejar al LLM solo la planificación y la verificación
    En otras palabras, la clave es preprocesar con scripts tanto como sea posible
  • También se pueden incluir scripts directamente dentro de skill. Skill también puede contener código
  • El autor original aclaró que el texto lo escribió una persona real en un vuelo, no una IA
  • Alguien comentó que también usa skill para tareas repetitivas, y a partir de eso siguió una explicación desde la perspectiva del contrato de API de MCP
    Si es un script pequeño, basta con ponerlo en el contexto y decir “usa esto”