Cómo escribimos este blog post desde Claude (sin tocar el repo)

Montamos un CMS sin pantalla, autenticado con API key y expuesto como servidor MCP remoto. El equipo escribe artículos hablándole a Claude. Esto es lo que decidimos, por qué, y un par de cosas que no esperábamos.

Aviso de honestidad antes de empezar: este post lo escribió Claude. No es una metáfora de marketing tipo “impulsado por inteligencia artificial”. El texto que estás leyendo se generó en una conversación de chat, alguien lo revisó, lo aprobó, y se publicó automáticamente sin que nadie abriera el repositorio del sitio.

Tampoco es magia. Es la consecuencia bastante predecible de una decisión técnica que tomamos hace pocas semanas, cuando intentamos resolver un problema chico: cómo facilitarle al equipo escribir posts de blog sin pedirles que aprendan git, frontmatter en YAML, ni el flujo de pull requests.

El problema (que parece chico hasta que lo vivís)

Nuestro blog está armado con Astro como sitio estático. Cada post es un archivo Markdown en src/content/blog/, con un frontmatter en YAML al inicio. Para publicar uno nuevo, alguien tiene que:

1. Clonar el repo o entrar a la UI de GitHub
2. Crear un branch
3. Escribir el .md con el frontmatter correcto
4. Subir la imagen al lugar adecuado
5. Abrir un pull request
6. Esperar la review
7. Mergear y esperar el build

Para un equipo con un perfil técnico mixto, ese flujo es prohibitivo. Quien no usa terminal todos los días no se siente cómodo. Y “delegar la publicación al developer” se rompe a la primera semana, porque el developer también quiere dormir.

La salida obvia era un CMS visual: Sveltia, Decap, Strapi, Contentful. Todas son herramientas válidas. De hecho probamos Sveltia y casi lo terminamos: faltaba solamente desplegar un OAuth broker en Cloudflare Workers para que el editor pudiera autenticarse contra GitHub.

Y ahí frenamos. Porque agregar una pantalla de admin nueva, configurar OAuth, mantener un worker aparte, y aceptar que los artículos del blog vivieran versionados en git nos pareció exactamente el tipo de complejidad que no queríamos. Era resolver un problema chico construyendo una herramienta grande.

La decisión rara: un CMS sin pantalla

Nuestra apuesta fue inversa. En lugar de agregar una UI nueva, decidimos no agregar ninguna. El CMS pasó a ser una API pura, sin frontend, con dos endpoints relevantes:

• Un endpoint REST para administración (crear API keys, revisar el audit log, lo aburrido).
• Un endpoint MCP, que expone las operaciones como herramientas que cualquier modelo de lenguaje puede invocar.

¿Y dónde está la interfaz para el editor humano? En Claude Desktop. O Claude Code. O cualquier cliente que hable el protocolo MCP.

Eso significa que cuando alguien del equipo quiere publicar un post, la conversación se parece a esto:

Persona: "Necesito escribir algo sobre por qué los data lakes
          baratos terminan costando caro."

Claude: [usa la herramienta propose_article, recibe un outline
         estructurado para la categoría correcta]
        [escribe el borrador completo en español e inglés]
        [genera el copy para LinkedIn]
        [llama a generate_image, que dispara Gemini en el server]
        "Te muestro el borrador. ¿Algo para ajustar?"

Persona: "El segundo bloque está flojo. Reescribilo más directo."

Claude: [edita] "¿Listo para publicar?"

Persona: "Dale."

Claude: [llama a publish_post con todo el payload]
        "Publicado. Va a estar online en dos minutos.
         Te paso el copy de LinkedIn para que lo postees."

El editor humano nunca toca git, nunca configura nada, nunca abre un archivo. Habla, revisa, aprueba.

Por qué MCP cambia algo, no solo el empaque

MCP (Model Context Protocol) es el estándar que Anthropic publicó para que los modelos de lenguaje puedan invocar herramientas externas de manera homogénea. Antes de MCP, cada integración entre un LLM y un sistema era plomería ad-hoc: definir el shape de la función, manejar la auth, parsear las respuestas, decidir formato de errores.

Con MCP, un servidor declara sus herramientas una vez, expone un endpoint HTTP con autenticación bearer, y cualquier cliente MCP (Claude Desktop, Claude Code, otros) puede usarlas sin código de pegamento. La persona del lado humano solo pega una línea de configuración:

{
  "mcpServers": {
    "sediment-blog": {
      "type": "http",
      "url": "https://cms-api.sedimentdata.com/mcp",
      "headers": { "Authorization": "Bearer <su-api-key>" }
    }
  }
}

Reinicia Claude Desktop, y a partir de ahí tiene las ocho herramientas del CMS disponibles dentro de su conversación habitual. Sin instalar nada. Sin aprender nada. Sin pantallas nuevas.

Cómo se ve por dentro

Tres componentes, nada más:

• El LLM cliente (Claude Desktop, en este caso). Conoce las herramientas porque el servidor MCP las declara con un esquema. Decide cuándo invocarlas según la conversación. Si decide mal, el editor humano lo corrige en el chat.
• El servidor MCP, que es una FastAPI en Python con FastMCP integrado. Vive en un container chico. Valida la API key contra una tabla SQLite, ejecuta la herramienta, escribe los archivos al filesystem, dispara el rebuild del sitio.
• Un volumen persistente donde viven los posts, las imágenes y el copy de LinkedIn. Es un volumen Docker normal, montado en el container del CMS y en el del sitio Astro.

Cuando alguien publica, el CMS escribe los archivos al volumen y le pega a un webhook para que el sitio rebuildee. El sitio lee el contenido del volumen como si fuera un directorio local. No hay base de datos para el contenido público. No hay cache que invalidar. No hay versionado de artículos en git (los posts viven en un volumen, no en el repositorio del sitio, que era exactamente lo que queríamos).

Lo que aprendimos en el camino

Tres cosas que no esperábamos cuando arrancamos:

1. El editor humano se relaja más cuando no ve una UI. Suena contraintuitivo. Pero las personas no técnicas se sienten más cómodas hablando con Claude que abriendo una pantalla de admin con quince campos de formulario. La conversación les da control sin la sensación de estar usando una herramienta nueva. La adopción fue de cero a una semana.

2. Las “preferencias de la marca” se vuelven instrucciones del sistema, no plantillas rígidas. La voz, el tono, la estructura de posts ya no viven en un manual de estilo escrito que nadie lee. Viven en el prompt del servidor MCP y en el outline que la herramienta propose_article devuelve. Lo que es coherente se vuelve fácil; lo que es disonante requiere esfuerzo. El estilo deja de ser un PDF y se vuelve código.

3. El audit log importa más de lo que pensábamos. Como cualquiera con una API key puede publicar desde su chat, hay que saber quién publicó qué y cuándo. Lo resolvimos con una tabla SQLite que registra cada acción con la huella de la API key. Quince líneas de código que ahorraron varias conversaciones incómodas del tipo “¿quién publicó esto?”.

Cuándo NO conviene hacer esto

Si tu equipo no usa LLMs en su flujo cotidiano, no hagas esto. La curva de adopción de un CMS conversacional asume que el modelo ya es parte del día. Si no lo es, te conviene un CMS visual estándar — la fricción del onboarding va a ser peor que la del CMS clásico.

Y si tu contenido es muy interactivo (calculadoras, formularios, micrositios, encuestas), tampoco. Para eso un CMS con bloques visuales sigue siendo mejor.

Pero si tu equipo ya está conversando con Claude varias horas por semana para escribir, resumir, traducir, o investigar, agregar un endpoint MCP al CMS es muy barato y muy potente. La persona que escribe nunca cambia de contexto. Lo que ya hace, ahora también publica.

Este post es la prueba: lo escribí yo (Claude), lo aprobó un humano en menos de diez minutos, y se publicó sin que nadie tocara el repo.

Capaz el próximo lo escribís vos. O mejor: capaz el próximo lo dictás vos y yo lo escribo.