atareao con Linux

Esto es lo que le faltaba a tu IA para ser útil de verdad

Vistas: 1
atareaoComenta
0:00 / 0:00
Esto es lo que le faltaba a tu IA para ser útil de verdad

En el episodio 829, me lié a hablar de skills y de cómo podías crear los tuyos propios. Fue un episodio útil, sí, pero reconozco que me enrollé demasiado. Hablé de las skills más interesantes, de cómo montarlas, de cómo configurarlas… pero no te mostré ninguna en concreto, no profundicé lo suficiente. Y claro, me quedó esa espinita clavada. Así que esta vez le he dado la vuelta al enfoque. En lugar de hablar de skills, he decidido centrarme en los verdaderos MCPs, el Model Context Protocol, y he seleccionado siete que considero absolutamente imprescindibles. Te los voy a mostrar uno por uno, con ejemplos reales, para que veas de primera mano cómo transforman a la IA de una máquina de hablar a una máquina de hacer. Porque al final, como te vengo contando desde el principio, los MCPs no son ni más ni menos que herramientas. Y una IA sin herramientas, créeme, es bastante inútil.

La IA es tonta, literalmente

Suena fuerte, lo sé. Pero tengo que decirlo claro: un modelo de lenguaje no sabe ni qué hora es, ni cómo leer un archivo, ni si tienes issues abiertos en GitHub, ni cómo te llamas. No sabe absolutamente nada. De hecho, fíjate, cada vez que empiezas a hablar con cualquier modelo de lenguaje empiezas de cero. Salvo que tengas un contexto inicial que se lo hayas facilitado, la sesión arranca en blanco. No hay memoria, no hay acceso al sistema de archivos, no hay conexión con el mundo exterior. Es como tener al empleado más brillante del mundo encerrado en una habitación sin ventanas, sin teléfono, sin internet y sin papeles.

Y yo me pregunto: ¿de qué te sirve un genio encerrado en una celda?

Pues eso. La IA generativa es increíble generando texto, pero el mundo real no está hecho de texto. Está hecho de archivos, de bases de datos, de repositorios de código, de páginas web, de horas del día, de relaciones entre personas y conceptos. Si la IA no puede tocar nada de eso, su utilidad se limita a charlar y poco más.

Aquí es donde entra el Model Context Protocol, o MCP como lo llamamos los amigos. Te cuento qué es exactamente y por qué debería importarte.

¿Qué es eso del MCP? La arquitectura host-cliente-servidor

El Model Context Protocol es un protocolo abierto creado por Anthropic, los mismos de Claude, que estandariza cómo las aplicaciones de IA se conectan con fuentes de datos y herramientas externas. Es un estándar, no un producto propietario. Y esto es importante porque, a diferencia de los plugins de ChatGPT que solo funcionan en ChatGPT, el MCP es un estándar abierto que cualquier aplicación puede implementar.

La arquitectura es sencilla y elegante. Tiene tres roles principales:

  • MCP Host: es la aplicación de IA que coordina todo. Puede ser Claude Desktop, VS Code, Claude Code, OpenCode, Cursor… cualquier aplicación que quiera darle superpoderes a la IA.
  • MCP Client: es el componente que mantiene la conexión con un servidor MCP concreto. Por cada servidor que conectes, tendrás un cliente.
  • MCP Server: es el programa que proporciona las herramientas y el contexto. Filesystem, GitHub, SQLite, Fetch… cada uno es un servidor que expone funcionalidades específicas.

La comunicación entre el cliente y el servidor se hace a través de JSON-RPC 2.0, un protocolo de llamada a procedimiento remoto ligero y bien conocido. Y el transporte puede ser de dos formas: stdio transport, que usa la entrada y salida estándar para procesos locales, el que más rendimiento da sin overhead de red, o Streamable HTTP transport, que usa HTTP POST con SSE opcional para servidores remotos.

Pero lo más interesante viene ahora. El servidor expone tres tipos de primitivas:

  • Tools: son funciones ejecutables que la IA puede invocar. Cosas como leer un archivo, escribir una consulta SQL, crear un issue en GitHub.
  • Resources: son fuentes de datos contextuales. Archivos, bases de datos, APIs.
  • Prompts: son plantillas reutilizables para estructurar interacciones.

Y hay un mecanismo de autodescubrimiento fascinante. El cliente envía una petición tools/list y el servidor responde con un array que contiene el nombre, la descripción y el esquema de entrada de cada herramienta, en formato JSON Schema. La IA sabe exactamente qué parámetros necesita cada herramienta. No hay adivinación, no hay configuración manual. Es puro discovery.

Cinco razones para adoptar MCPs

Antes de meternos en harina con los servidores concretos, déjame darte cinco razones de peso para que empieces a usar MCPs ya mismo.

Primera, estandarización. MCP es un protocolo abierto, no propietario. Si aprendes a configurar un servidor MCP en Claude Desktop, sabrás configurarlo en VS Code, en OpenCode, en Cursor y en cualquier otro host que lo soporte. Es como el USB-C para la IA: un conector universal para herramientas.

Segunda, aislamiento. Cada servidor MCP se ejecuta en su propio proceso. Si el servidor de GitHub se cuelga, los demás siguen funcionando perfectamente. No hay dependencias cruzadas, no hay riesgo de que un servidor se lleve por delante a los demás.

Tercera, escalabilidad. Puedes tener tantos servidores como necesites. ¿Necesitas acceso a archivos? Un servidor. ¿Necesitas consultar bases de datos? Otro servidor. ¿Necesitas gestionar issues de GitHub? Otro más. Y si un día dejas de necesitar uno, lo quitas y listo. No hay que modificar nada más.

Cuarta, seguridad. Los servidores MCP tienen control de acceso granular. El servidor de Filesystem, por ejemplo, solo opera dentro de los directorios que le hayas autorizado. No puede salirse de ahí. No puede leer tu carpeta de contraseñas si no se lo permites. Y las herramientas marcan explícitamente si son de solo lectura, si son destructivas o si son seguras de repetir.

Quinta, interoperabilidad. Si un host habla MCP, funciona. No importa si es Claude Desktop, VS Code, OpenCode o cualquier otro. El protocolo es el mismo. Es la magia de los estándares abiertos.

Esto no es como los plugins de ChatGPT, que solo funcionan en ChatGPT. MCP funciona en todas partes.

Dicho esto, te presento los siete servidores MCP que considero imprescindibles. Empiezo por el que más uso en mi día a día.

MCP Filesystem: el pan nuestro de cada día

El servidor de Filesystem es, sin duda, el MCP más práctico para el día a día. Te permite leer archivos, escribirlos, buscarlos, moverlos, crear directorios, obtener metadatos… hasta 17 herramientas distintas que transforman a tu IA en un asistente de gestión de archivos de primera categoría.

Lo mejor de todo es el control de acceso. El servidor solo opera dentro de los directorios que le hayas autorizado explícitamente. Puedes configurarlo de dos formas: pasándole los directorios permitidos como argumento de línea de comandos, o mediante los MCP Roots, donde el cliente notifica dinámicamente los directorios permitidos.

Imagínate el escenario. Estás trabajando en un proyecto y necesitas revisar varios archivos de configuración, buscar una función en concreto en todo el código, o modificar un archivo YAML. Con el MCP Filesystem, puedes pedírselo directamente a la IA:

  • Léeme el archivo docker-compose.yml
  • Busca todos los archivos que contengan la palabra database en el directorio src/config
  • Edita la línea 23 del archivo settings.json y cambia el puerto de 8080 a 9090

Y la IA lo hace. Sin que tengas que abrir un editor, sin buscar manualmente. Le pides lo que necesitas y ella se encarga.

El servidor incluye herramientas muy bien pensadas. La de edit_file, por ejemplo, permite hacer ediciones selectivas con patrón de coincidencia y tiene un modo dry-run para que puedas ver los cambios antes de aplicarlos. La de search_files hace búsquedas recursivas con patrones glob. La de directory_tree te da un árbol JSON recursivo del directorio. Son 17 herramientas que cubren prácticamente cualquier operación que puedas necesitar con archivos.

La configuración es sencillísima. En tu opencode.json o en la configuración de MCP de tu host favorito, añades esto:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/ruta/permitida"]
    }
  }
}

Y ya está. Con esto tan sencillo, tu IA puede leer y escribir archivos como si tuviera manos. Es, como te digo, el pan nuestro de cada día.

MCP SQLite: consulta bases de datos como si nada

El segundo MCP que quiero mostrarte es el de SQLite. Este servidor te permite consultar bases de datos SQLite directamente desde la IA. Y ojo, que esto es más útil de lo que parece.

Tengo que hacer una aclaración importante. El servidor oficial de SQLite del repositorio de MCP fue archivado en mayo de 2025 por el steering group del protocolo. Pero no te preocupes, porque sigue funcionando perfectamente y la comunidad lo mantiene vivo. De hecho, está disponible como paquete de Python y se instala en un momento.

Las herramientas que incluye son las que esperarías: read_query para consultas SELECT, write_query para INSERT, UPDATE y DELETE, create_table para crear tablas, list_tables para listarlas, describe-table para ver el esquema, y una curiosa llamada append_insight que permite añadir notas a un memo de negocio.

¿Para qué puedes usarlo? Pues imagina que tienes una base de datos SQLite con tus gastos mensuales, o con el catálogo de tu biblioteca de libros, o con los datos de tu servidor de música. Le pides a la IA:

  • Dime cuánto me he gastado este mes en suscripciones
  • Muéstrame los libros que tengo pendientes de leer
  • ¿Cuál es el artista que más tengo en mi colección?

Y la IA ejecuta la consulta SQLite y te responde. Sin que tengas que abrir un cliente de bases de datos, sin recordar la sintaxis exacta de SQL. Tú preguntas en lenguaje natural y la IA se encarga del resto.

La configuración es igual de sencilla:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "~/test.db"]
    }
  }
}

Eso sí, hay una cosa que me parece importante mencionar: el no-determinismo. Cuando tienes varios servidores MCP ejecutándose, el orden en el que la IA invoca las herramientas no es predecible. Unas veces consultará primero el tiempo y luego los archivos, y otras veces al revés. Esto puede dar lugar a respuestas diferentes para la misma pregunta. No es un bug, es una característica del diseño: el modelo evalúa qué herramientas necesita y las invoca en el orden que considera más adecuado en cada momento.

MCP GitHub: tu repositorio al alcance del chat

Si desarrollas software, este MCP te va a cambiar la vida. El servidor de GitHub te permite gestionar issues, pull requests, repositorios, buscar código, revisar archivos… todo desde el chat de la IA. Y encima es el servidor oficial de GitHub, no un proyecto de la comunidad.

El servidor original de MCP para GitHub fue archivado, como el de SQLite, pero GitHub lanzó su propio servidor oficial escrito en Go, con más de 32.700 estrellas en el momento de escribir esto. Tiene dos modalidades: remota y local.

La modalidad remota está hosteada por GitHub en la API de GitHub Copilot. No requiere Docker, no requiere instalar nada. Solo configuras la URL y el token de autenticación:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

La modalidad local se ejecuta con Docker y funciona con OAuth o con un Personal Access Token de GitHub.

Pero lo realmente potente es la cantidad de herramientas que ofrece. El servidor organiza sus capacidades en toolsets para no saturar el contexto. Por defecto carga los de contexto, repositorios, issues, pull requests y usuarios. Pero tienes muchos más: GitHub Actions, code scanning, Dependabot, discussions, gists, proyectos, notificaciones, estrellas…

Más de 26 herramientas en total. Puedes crear issues, listarlos, actualizarlos, cerrarlos. Puedes crear pull requests, mergearlos, revisarlos. Puedes buscar repositorios, leer archivos, buscar código, crear ramas, forkear proyectos… prácticamente todo lo que harías desde la web de GitHub, pero desde el chat.

Y lo mejor es que puedes filtrar los toolsets para ahorrar tokens. Si solo necesitas gestionar issues, configuras el servidor con los toolsets de issues y repos, y te olvidas del resto. El contexto de la IA no se satura con herramientas que no vas a usar.

Imagínate el flujo de trabajo. Estás programando, te surge un bug, le dices a la IA: Crea un issue en el repositorio tal describiendo este bug. O abres un PR y le pides: Revisa este pull request y dime si ves algo raro. O simplemente: ¿Qué issues tengo abiertos en este repositorio?

Todo sin salir del editor, sin abrir el navegador, sin cambiar de contexto. Es una pasada.

MCP Web Fetch: lee internet sin mover un dedo

Este es otro de esos MCPs que no sabías que necesitabas hasta que lo pruebas. El servidor de Web Fetch permite a la IA obtener contenido de páginas web y convertirlo a Markdown. Es decir, tu IA puede leer páginas web por ti.

Esto tiene implicaciones enormes. ¿Necesitas documentación de una librería? Tráeme la documentación de la API tal. ¿Quieres saber la última noticia sobre un tema? Búscame las últimas noticias sobre este tema. ¿Tienes que consultar el precio de un producto? Dime cuánto cuesta esto en esta tienda.

La herramienta principal es fetch, que recibe una URL y devuelve el contenido convertido a Markdown. Pero tiene un truco que me parece brutal: el ahorro de tokens. El servidor trunca la respuesta a un máximo de caracteres que tú configures, por defecto 5000, y además puedes usar start_index para leer una página web en fragmentos. En lugar de traerte los 15.000 caracteres de golpe, y llenar el contexto de la IA, puedes leer la página en trozos hasta encontrar la información que necesitas.

Esto es un ahorro salvaje. Por darte un ejemplo, una página web típica de documentación puede tener 15.000 caracteres. Si la IA tuviera que traérsela entera, casi la mitad del contexto se iría en esa página. Con el MCP Web Fetch puedes limitarlo a 5.000 caracteres, o incluso menos si sabes lo que buscas. Y usando fragmentación, puedes ir consumiendo solo lo necesario.

La cuestión es que el ahorro de tokens no es un capricho. En las IAs actuales el contexto es limitado y caro. Cada token que gastas en una web es un token que no puedes usar para el razonamiento. Con este MCP, optimizas el uso del contexto de forma drástica.

La configuración es trivial:

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  }
}

Eso sí, una advertencia: este servidor puede acceder a direcciones IP locales o internas. Es un riesgo de seguridad que debes tener en cuenta. Por defecto respeta el robots.txt de las webs, pero si necesitas ignorarlo, puedes pasarle el flag --ignore-robots-txt. Y puedes configurar un proxy si lo necesitas.

MCP Time: por fin la IA sabe qué hora es

Parece una tontería, pero no lo es. Uno de los problemas más frustrantes de la IA es que no sabe qué hora es. Le preguntas ¿qué hora es en Tokio ahora mismo? y te responde cualquier cosa porque no tiene acceso al reloj del sistema.

El MCP Time soluciona esto de raíz. Es un servidor sencillo, con solo dos herramientas, pero increíblemente útil:

  • get_current_time te da la hora actual en cualquier zona horaria IANA.
  • convert_time te permite convertir una hora de una zona a otra.

¿Usos prácticos? Muchísimos. Estás organizando una reunión con un colega de México y otro de Berlín. Le preguntas a la IA: ¿A qué hora son las 10 de la mañana en México en Berlín? Y la IA te responde al instante, porque tiene acceso al servidor de tiempo.

O simplemente quieres saber si es de día en Japón para saber si puedes molestar a un compañero. La IA lo sabe.

El servidor usa nombres de zona IANA, que son los estándar: Europe/Madrid, America/Argentina/Buenos_Aires, Asia/Tokyo. Por defecto detecta la zona horaria de tu sistema, pero puedes sobrescribirla con el flag --local-timezone.

La configuración, como no podía ser de otra forma:

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    }
  }
}

Tres líneas y tu IA ya no volverá a inventarse la hora. Te puedo asegurar que desde que lo tengo configurado, me ha sacado de más de un apuro.

MCP Memory: la IA que no olvida

Y aquí llegamos a dos MCPs que me parecen especialmente interesantes. El primero de ellos es MCP Memory, un servidor de memoria persistente basado en un grafo de conocimiento.

Te explico. Una de las limitaciones más grandes de las IAs actuales es que cada sesión empieza de cero. No importa si has estado hablando media hora con ella sobre tus preferencias, tus proyectos y tus contactos; en cuanto cierras la sesión, todo se borra. Al día siguiente, la IA no se acuerda de ti ni de nada de lo que hablasteis.

El MCP Memory soluciona esto almacenando información en un grafo de conocimiento persistente. Funciona con tres conceptos fundamentales:

  • Entity: un nodo del grafo, con un nombre único y un tipo. Por ejemplo, "name": "Lorenzo", "entityType": "person".
  • Observation: un hecho atómico sobre una entidad. Por ejemplo, "Escribe el podcast atareao con Linux".
  • Relation: una conexión dirigida entre entidades. Por ejemplo, from: "Lorenzo", to: "atareao con Linux", relationType: "hosts".

Con estos tres conceptos, la IA construye un grafo de conocimiento que persiste entre sesiones. Se almacena en un archivo JSONL, por defecto memory.jsonl, y se actualiza con cada interacción.

El resultado es que la IA te reconoce cuando vuelves. Sabe cómo te llamas, cuáles son tus preferencias, en qué proyectos estás trabajando, qué herramientas usas. No tienes que volver a explicarle todo cada vez.

Las herramientas disponibles son nueve: create_entities, create_relations, add_observations, delete_entities, delete_observations, delete_relations, read_graph, search_nodes, open_nodes. Suficientes para gestionar cualquier grafo de conocimiento que se te ocurra.

Puedes usarlo como base de conocimiento personal. Imagina que le dices a la IA: Acuérdate de que prefiero Python sobre JavaScript para proyectos nuevos, o Guarda que mi usuario de GitHub es atareao. La próxima vez que le preguntes algo relacionado, lo sabrá.

MCP Sequential Thinking: pensar paso a paso

Y el séptimo MCP, el que cierra esta lista, es el Sequential Thinking. Este es diferente a todos los anteriores porque no es una herramienta que invoques tú directamente. Es un servidor que fuerza a la IA a pensar de forma estructurada, paso a paso.

El MCP Sequential Thinking implementa una única herramienta llamada sequential_thinking. Y los parámetros que recibe son muy interesantes:

  • thought: el paso de pensamiento actual
  • nextThoughtNeeded: si se necesita otro paso
  • thoughtNumber: el número del pensamiento actual
  • totalThoughts: la estimación total de pensamientos
  • isRevision: si revisa un pensamiento anterior
  • revisesThought: qué pensamiento reconsidera
  • branchFromThought: desde qué pensamiento bifurca
  • branchId: identificador de bifurcación
  • needsMoreThoughts: si necesita más pasos

Fíjate en los parámetros de revisión y bifurcación. Esto permite que la IA no solo piense de forma lineal, sino que pueda volver atrás, revisar sus pasos, y explorar caminos alternativos. Es como tener un razonamiento humano, con capacidad de corrección y exploración.

¿Cuándo es útil? Para debugging de problemas complejos, para planificación de migraciones, para comparación de arquitecturas, para análisis con múltiples variables. Cualquier problema donde el alcance no esté claro inicialmente se beneficia de este enfoque.

Por ejemplo, puedes decirle: Planifica una migración de base de datos de PostgreSQL 14 a 16, lista los riesgos, y revisa el plan si el tiempo de inactividad supera los 5 minutos. La IA empezará a pensar paso a paso, evaluando riesgos, considerando alternativas, y si encuentra que el downtime inicial supera el límite, bifurcará a un plan B.

La configuración es igual de simple que las anteriores:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

La IA lo invocará automáticamente cuando detecte que necesita razonar de forma estructurada. Tú no tienes que hacer nada, solo plantear el problema.

Configuración en OpenCode, consumo de tokens y RAM

Una vez que tienes claros los siete MCPs, llega la parte práctica: cómo configurarlos. Te voy a contar cómo se hace en OpenCode, que es el que uso yo, pero el proceso es muy similar en cualquier host.

OpenCode usa la clave mcpServers en el archivo de configuración opencode.json. La estructura es siempre la misma: un nombre para el servidor, el tipo de transporte (stdio), el comando a ejecutar, y los argumentos.

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."],
      "env": []
    },
    "fetch": {
      "type": "stdio",
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    },
    "time": {
      "type": "stdio",
      "command": "uvx",
      "args": ["mcp-server-time"]
    }
  }
}

Y hay comandos específicos para gestionar los MCPs:

  • opencode mcp list — lista los servidores configurados
  • opencode mcp add ... — añade un servidor nuevo
  • opencode mcp debug github — diagnostica el estado de conexión
  • opencode mcp auth github — inicia el flujo OAuth manual
  • opencode mcp logout github — limpia los tokens OAuth

Una cosa que me parece interesante es que OpenCode permite desactivar MCPs por agente. Puedes tener un servidor de GitHub configurado pero desactivado globalmente, y activarlo solo para un agente específico que se dedique a tareas de desarrollo. Esto ahorra contexto porque el modelo no carga las herramientas que no va a usar.

Y hablando de contexto, aquí viene un tema importante: el consumo de tokens y RAM. Cada servidor MCP que añades consume memoria RAM y, cuando la IA lo invoca, consume tokens. Los servidores en Python consumen entre 50 y 150 MB de RAM cada uno. Los de TypeScript entre 30 y 80 MB. Y los de Rust, si te animas a compilarlos, entre 10 y 30 MB.

¿Es mucho? Depende. En un ordenador de escritorio con 16 GB de RAM, tener seis o siete servidores MCP ejecutándose no supone ningún problema. Pero si estás en un portátil más modesto, igual te interesa seleccionar solo los que realmente necesitas.

En cuanto a tokens, la cuestión es más sutil. Cuando la IA se conecta a un servidor MCP, recibe la lista de herramientas disponibles con sus descripciones y esquemas de entrada. Esto ocupa contexto. Si tienes 20 herramientas con descripciones largas, puedes perder entre 500 y 1.000 tokens solo en la meta-información. No es una barbaridad, pero hay que tenerlo en cuenta si trabajas con contextos ajustados.

Crear tu propio MCP: Python SDK vs Rust

Hasta ahora hemos visto servidores MCP ya hechos, listos para usar. Pero una de las grandes ventajas del protocolo es que puedes crear tus propios servidores. Si tienes una herramienta interna, una API propia, una base de datos específica, puedes crear un MCP que la exponga a la IA.

Y aquí tienes dos caminos principales: el SDK de Python y el SDK de Rust.

El SDK de Python es, con diferencia, el más popular. Tiene más de 24.000 estrellas en GitHub y permite crear un servidor MCP completo en unas 15 líneas de código. Es ideal para prototipado y para servidores simples. El consumo de RAM es moderado, entre 50 y 150 MB, y el tiempo de arranque ronda el medio segundo. Si nunca has creado un MCP, este es tu punto de partida.

El SDK de Rust —el crate rmcp— es la opción para los que buscan máximo rendimiento. Los servidores compilados a nativo arrancan en milisegundos y consumen entre 10 y 30 MB de RAM. Es la opción ideal para producción. Pero claro, requiere saber Rust, y la curva de aprendizaje es más pronunciada.

Luego tienes otras opciones: el SDK de TypeScript, que es con el que están escritos muchos de los servidores oficiales, Filesystem, Memory, Sequential Thinking, con un consumo de RAM intermedio entre Python y Rust. Y el SDK de Go, que es el que usa el servidor oficial de GitHub.

Para el usuario doméstico, Python o TypeScript son más que suficientes. La diferencia real en rendimiento solo se nota cuando tienes muchos servidores ejecutándose simultáneamente o cuando necesitas un tiempo de arranque mínimo. Para el día a día, un servidor en Python cumple perfectamente.

MCP vs Skills: no compiten, se complementan

En el episodio 829 hablé de skills. En este episodio he profundizado en MCPs. Y quizá te estés preguntando: ¿skills o MCPs? ¿Cuál es mejor?

La respuesta es que no compiten, se complementan.

Los skills definen cómo debe comportarse la IA. Son el manual de estilo, las reglas de negocio, las preferencias de formato. Le dicen a la IA: responde siempre en markdown, pregunta antes de escribir archivos importantes, usa tono informal. Son instrucciones, reglas, comportamientos.

Los MCPs definen qué puede hacer la IA. Son las herramientas, las capacidades. Le dicen a la IA: puedes leer archivos del sistema, puedes consultar SQLite, puedes gestionar issues de GitHub. Son acciones, no reglas.

Un ejemplo práctico: imagina que tienes un skill que dice siempre pregunta antes de sobrescribir un archivo, y un MCP Filesystem que proporciona la capacidad de escribir archivos. El skill pone la regla, el MCP da la capacidad. Los dos trabajan juntos.

Así que no te líes. Usa skills para el comportamiento y MCPs para las capacidades. Los dos son necesarios.

Conclusión: la IA sin MCPs es como un ordenador sin internet

Llegados a este punto, creo que ha quedado claro. Una IA sin MCPs es una IA manca. Puede hablar bonito, puede generar texto coherente, puede mantener una conversación, pero no puede hacer nada en el mundo real. No puede leer tus archivos, no puede consultar tu base de datos, no puede gestionar tus issues, no puede buscar en internet, no sabe qué hora es, no te recuerda de una sesión a otra, y no puede pensar de forma estructurada.

Con los siete MCPs que te he mostrado —Filesystem, SQLite, GitHub, Web Fetch, Time, Memory y Sequential Thinking— tu IA pasa de ser un loro parlanchín a ser un asistente realmente útil. Y lo mejor de todo es que puedes empezar con uno o dos, los que más te interesen, e ir añadiendo más según los necesites.

No hace falta que los configures todos de golpe. Empieza por el Filesystem, que es el más práctico. Luego añade el Time, que es el más sencillo. Cuando te sientas cómodo, añade el Fetch. Y así, poco a poco, vas construyendo tu ecosistema de herramientas.

Lo bueno del MCP es que es un estándar abierto. No estás atado a ningún proveedor, a ninguna plataforma. Si mañana decides cambiar de Claude Desktop a OpenCode, o de OpenCode a VS Code, tus MCPs funcionan igual. No tienes que reconfigurar nada, solo copiar la configuración.

Y si te animas, crea tu propio MCP. Con el SDK de Python, en 15 líneas de código puedes tener un servidor que exponga tus herramientas favoritas. No hay límites.

Así que ya sabes. Dale manos a tu IA. Conéctale los MCPs. Y verás como deja de ser una máquina de hablar para convertirse en una máquina de hacer. Te aseguro que no volverás atrás.

Más información

Deja una respuesta