Otto Webmaster estrena servidor MCP para gestionar webs

El Model Context Protocol no llega a los dos años de vida: Anthropic lo publicó como estándar abierto en noviembre de 2024. En ese tiempo ha pasado de ser una integración de nicho a convertirse en la forma habitual que tiene un producto de decir “esto se puede pilotar desde un agente”. El anuncio de Otto Webmaster, recogido por AiThority este lunes, va justo en esa dirección: un servidor MCP para gestionar sitios web, presentado bajo la etiqueta de AI-native website management.

La noticia en sí es pequeña. Lo interesante es el patrón, porque en los últimos meses se ha repetido la misma jugada en CMS, paneles de hosting y herramientas SEO: primero un dashboard, luego una API REST y ahora un servidor MCP encima de esa API. Cambia quién es el usuario final de la integración. Ya no es un desarrollador leyendo documentación, es un modelo leyendo descripciones de herramientas.

Qué cambia respecto a una API normal

Un servidor MCP expone tres cosas: herramientas (acciones), recursos (lectura) y prompts. La diferencia práctica con una API es que el contrato lo lee el modelo en tiempo de ejecución, así que la calidad de los nombres y de las descripciones deja de ser cosmética. Una herramienta llamada `update_page` que reescribe la página entera y otra llamada `patch_block` que toca un bloque concreto producen comportamientos muy distintos cuando quien decide es un agente con contexto parcial.

La instalación sigue el camino de siempre: `claude mcp add` en Claude Code o una entrada en `claude_desktop_config.json`, con transporte stdio para servidores locales o HTTP para los remotos. La documentación de MCP y la de Claude Code cubren ambos casos.

La etiqueta AI-native conviene cogerla con pinzas. En la mayoría de casos no significa que el producto se haya reconstruido alrededor de un modelo, sino que su superficie de operaciones ya es legible para uno. Es un cambio de interfaz, no de arquitectura, y está bien que así sea: lo que se puede auditar es precisamente la API que ya existía debajo.

Lo que revisaríamos antes de enchufarlo a producción

No hemos probado el servidor de Otto Webmaster, así que esto no es una valoración del producto sino la lista que aplicamos a cualquier MCP con permisos de escritura sobre una web viva:

1. Token con el mínimo alcance posible. Un servidor que puede publicar también puede despublicar. Si la credencial es la misma que usa el equipo para todo, el agente hereda todo.
2. Staging antes que producción. Parece obvio y casi nunca se hace, porque el atractivo del formato es precisamente arreglar cosas rápido.
3. Rollback y traza. Si una herramienta modifica contenido, hay que poder saber qué cambió, cuándo y con qué versión anterior. Muchos servidores MCP todavía no devuelven nada parecido a un diff.
4. Granularidad. Las herramientas pequeñas y explícitas fallan mejor que una herramienta genérica que acepta un objeto enorme.
5. Hooks como freno. En Claude Code, un hook `PreToolUse` puede bloquear llamadas de escritura o pedir confirmación sin depender de que el modelo se porte bien.
6. Coste de contexto. Cada herramienta ocupa tokens en cada turno. Veinte herramientas mal descritas encarecen todas las conversaciones, hablen o no de la web.

Para quién tiene sentido

Para quien gestiona muchos sitios a la vez, el formato ahorra tiempo real: cambios masivos de metadatos, revisiones de enlaces rotos, auditorías repetitivas. Para quien tiene una landing y la toca una vez al trimestre, un servidor MCP añade superficie de riesgo sin ahorrar nada. La frontera está en el volumen y en la repetición, no en lo moderno que suene.

También hay un efecto secundario que ya se nota en clientes: cuando una herramienta publica su servidor MCP, la conversación interna deja de ser qué plugin instalamos y pasa a ser qué permisos le damos al agente. Es una pregunta mejor, aunque incomode más.

Nuestra lectura es que anuncios como este valen menos por el producto concreto y más por lo que confirman: MCP se está convirtiendo en la capa de integración por defecto, y eso traslada el trabajo difícil de la conexión al diseño de permisos. Quien monte esto sin una política de escritura clara acabará aprendiendo la lección con una web en producción delante.