Quieres que tu agente deje de escribir las migraciones como no toca. Hay tres sitios donde puedes meter eso, y ninguna razón evidente para elegir uno. Puedes escribirlo en AGENTS.md. Puedes empaquetarlo como skill. Puedes levantar un servidor MCP que exponga una tool de migraciones. Todas las guías que he leído responden a una pregunta distinta de la mía, que no es qué son estas cosas sino qué me cuesta cada una en los cuatrocientos turnos en los que no se usa.
Ese coste es real y es invisible. Una capacidad entregada por el canal equivocado no da error. Se queda en la ventana, quitándole sitio a la tarea sin hacer ruido, y te enteras más tarde, cuando el agente empieza a leer por encima justo aquello que más te importaba que leyera.
Los tres canales, rápido
No voy a volver a deducir qué va en un fichero de reglas. Ese argumento ya tiene su sitio en dónde deberían vivir tus decisiones, y la versión corta es que los ficheros de reglas cargan hechos operativos del repo, no decisiones de producto.
Un fichero de reglas (AGENTS.md, el estándar abierto definido en agents.md, o un fichero de proveedor como CLAUDE.md) es texto que el harness lee y pone delante del agente. Está siempre. Ese es todo su sentido y también todo su problema.
Una skill es una carpeta con una descripción y un cuerpo. El harness le enseña al agente las descripciones de lo que hay disponible, y trae el cuerpo solo cuando una tarea parece encajar. Anthropic describe el patrón general en lo que ha escrito sobre context engineering, donde los agentes se quedan con identificadores ligeros y van a buscar el contenido real cuando lo necesitan en lugar de precargarlo todo de antemano.
Un servidor MCP es un proceso vivo con el que el agente habla por un protocolo. No es texto, es una conexión con herramientas reales detrás, y por eso puede guardar credenciales, atacar una base de datos o devolverte algo que era cierto hace un segundo. La especificación actual ha vuelto el protocolo stateless en su núcleo y ha añadido un método server/discover para que los clientes pidan las capacidades del servidor cuando les interesa tenerlas por adelantado.
El reparto no es solo mío. Cuando GitHub ha puesto los dos en general availability dentro de su code review de Copilot, ha trazado la misma línea: las skills cargan las herramientas internas y los estándares de código de tu equipo como ficheros SKILL.md en el repo, y las conexiones MCP traen contexto de plataformas de terceros como gestores de incidencias o catálogos de servicios.
Tres mecanismos distintos. Lo interesante no es la taxonomía, es qué le pasa a cada uno en un turno en el que la tarea no tiene nada que ver con él.
Cuándo carga es toda la pregunta
Conecta unos cuantos servidores MCP y mira lo que lleva encima tu agente antes de que hayas escrito la tarea. Todas las tools de todos los servidores conectados, cada una con su nombre, su descripción y su esquema, descritas lo bastante bien como para que el modelo sepa elegir entre ellas. Ese inventario viaja con la petición. Está el turno en que usas la tool de base de datos y está los cuatrocientos turnos en que no.
Con el fichero de reglas pasa lo mismo, y esa parte ya está documentada en este cluster: cada línea que el harness autocarga se paga en cada llamada. Lo que quiero añadir es que la regla se generaliza. Todo lo que el harness cablea de forma permanente se paga de forma permanente, y los servidores MCP son la versión más cara porque la lista de tools crece con cada servidor que conectas y nadie la poda nunca. El contexto es un recurso finito lo gastes en lo que lo gastes, y esta es una factura que aceptaste sin leerla.
La skill es la única de las tres con un estado de reposo barato. El agente lleva la descripción y nada más hasta que una tarea encaja. Puedes tener cien skills instaladas y no pagar casi nada por las noventa y nueve que ahora mismo no vienen a cuento.
| Canal | Cuándo carga | Coste en un turno ajeno | Cómo falla |
|---|---|---|---|
| Fichero de reglas | siempre, en cada llamada | el fichero entero | envejece y despista |
| Servidor MCP | conectado toda la sesión | la descripción de cada tool | ahoga a la tarea, o el proceso se cae |
| Skill | bajo demanda, al encajar | solo la descripción | no la elige nunca |
Esa última columna es la que todo el mundo se salta, y es donde de verdad muerde la elección.
Cada uno falla a su manera
Un fichero de reglas falla envejeciendo. Sigue diciendo algo que dejó de ser cierto, no salta ningún error, y el agente lo obedece con total confianza. Ese modo de fallo tiene su propia pieza en tu fichero de reglas les está mintiendo a tus agentes, así que lo dejo ahí.
Una skill falla en la puerta. El agente no llega a ver el cuerpo, y por eso el fallo es invisible desde dentro de la skill: el contenido está perfecto y sencillamente no la eligieron. La descripción es la parte que sostiene todo, y es la parte que todo el mundo escribe la última, con prisa, cuando el trabajo interesante ya está hecho. Si tu skill se llama helpers y la describes como “utilidades del proyecto”, va a perder todos los emparejamientos contra una tarea que la necesitaba. Cuando parece que una skill no funciona, el cuerpo casi nunca es el problema.
Un servidor MCP falla en dos direcciones a la vez. Puede fallar a gritos, que es el caso bueno, porque un proceso muerto o un error de auth se ven. El caso malo es silencioso. Conecta suficientes servidores y el agente empieza a elegir mal entre cuarenta tools casi idénticas, o el inventario de tools se come el sitio que necesitaba la tarea. Un servidor con una tool afilada vale más que un servidor con treinta, y esto es justo lo contrario de cómo se distribuyen casi todos.
se paga cada turno
- texto de las reglas
- cada esquema de tool
- en reposo cuesta igual
se paga al usarse
- descripción de la skill
- el cuerpo al encajar
- en reposo casi nada
Lo que yo tengo montado
El reparto con el que me he quedado, operando agentes en más de un motor:
- Los hechos operativos que son ciertos en todos los turnos van al fichero de reglas. Cómo se compila, cómo se corren los tests, qué no se toca. Lo bastante corto como para que se siga leyendo en vez de ojearse.
- Los procedimientos que aplican a veces van a skills. Cómo hacemos una migración, cómo cerramos una release, la lista de revisión de cualquier cosa que toque dinero. Son los que hincharían un fichero de reglas hasta volverlo inútil, y son exactamente para lo que se inventó la carga bajo demanda.
- Todo lo que necesita estado vivo, credenciales o un sistema real va a MCP. Es el único de los tres que puede llegar de verdad a tu base de datos, y el coste permanente merece la pena cuando necesitas alcance de verdad. Conecto pocos servidores y desconecto los que un proyecto no usa.
- Las decisiones de producto no van a ninguno de los tres. Van a un artefacto que carga su porqué y se puede comprobar, que es el argumento de la pieza de los ficheros de reglas y la razón por la que la memoria duradera vive fuera de la sesión.
El fallo que más veo es un equipo tirando de MCP porque suena a la opción seria, cuando lo que tenían era un procedimiento. Un procedimiento es una skill. Levantar un servidor para eso te compra una factura de contexto permanente y un proceso más que se puede caer, a cambio de un texto que podrías haber cargado bajo demanda.
Nada de esto hace que la salida del agente sea fiable por sí sola. Entregar bien una capacidad significa que el agente tiene más probabilidades de tener delante las instrucciones correctas, que es un paso anterior a si el trabajo se hizo bien. Eso se sigue resolviendo con evidencia en la puerta, no con lo bien que empaquetaste las instrucciones.
Dónde encaja PaellaDoc
Los tres son formas de poner texto o alcance delante de un agente en el momento adecuado, y ninguno es un sitio donde guardar lo que decidió tu producto. Ese es el hilo de todo lo que construyo. La pregunta del canal es una pregunta de harness, parte de que el harness es lo que merece ingeniería, y es la clase de decisión que ahora tomas a mano y vuelves a tomar cada vez que añades una herramienta. PaellaDoc guarda las decisiones, los criterios y los porqués como artefactos que viajan con la tarea y se comprueban ejecute quien ejecute, de modo que el canal que elijas sea un detalle de entrega y no el sitio donde ha acabado viviendo la memoria de tu producto. Sostener todo eso a mano es de lo que va eres el runtime.
FAQ
¿Uso una skill o un servidor MCP?
Si la capacidad es conocimiento o procedimiento, texto que le dice al agente cómo hacer algo, usa una skill y págala solo cuando encaje. Si necesita datos vivos, credenciales o conexión con un sistema real, usa MCP, porque una skill no puede alcanzar nada por sí sola. El test es si le estás enseñando algo al agente o le estás dando alcance.
¿Conectar más servidores MCP ralentiza a mi agente?
Te cuesta contexto en cada turno, porque el inventario de tools viaja con cada petición uses esas tools o no. También complica la elección, porque el modelo tiene más opciones casi idénticas entre las que decidir. Conecta los servidores que el proyecto necesita de verdad y quita el resto.
¿Por qué mi skill no se activa nunca?
Casi siempre es la descripción, no el cuerpo. El agente decide si carga una skill solo con el nombre y la descripción, así que una descripción vaga pierde el emparejamiento antes de que se vea el contenido. Escribe la descripción como la situación en la que aplica, con las palabras que usaría una tarea.