WordPress Trac ya tiene servidor MCP para IA

En pocas palabras: El WordPress Trac MCP server es una herramienta pública y gratuita, lanzada el 24 de septiembre de 2026, que corre en Cloudflare Workers y conecta a Claude, ChatGPT u otros clientes MCP con Trac de WordPress.org para leer tickets, changesets e historial sin necesidad de cuenta ni API key.

WordPress.org lanzó el servidor MCP de WordPress Trac, una herramienta pública y gratuita que conecta a Claude, ChatGPT o cualquier cliente compatible con Model Context Protocol para leer tickets, changesets e historial de Trac en tiempo real. Según el anuncio oficial publicado el 24 de septiembre de 2026, no hace falta cuenta ni API key: funciona con cualquier instancia de Trac de WordPress.org.

El servidor MCP de WordPress Trac es un servidor Model Context Protocol de solo lectura que expone los datos públicos de Trac, el sistema de seguimiento de tickets de WordPress.org, a cualquier asistente de IA compatible. Corre como un Cloudflare Worker y usa los endpoints HTML, CSV, RSS y diff que Trac ya publica de forma pública, sin credenciales ni capa de autenticación propia.

¿Cómo funciona el servidor MCP de WordPress Trac?

El servidor actúa de intermediario entre un cliente MCP y Trac: recibe la consulta del asistente, la traduce a un pedido HTTP contra las páginas públicas de Trac y devuelve la respuesta en JSON estructurado. No pide cuenta ni API key porque lee información que ya es pública en el Trac de WordPress.org, y corre sobre Cloudflare Workers.

Subís la consulta, el cliente MCP la manda al servidor, el servidor la traduce a un pedido HTTP contra Trac, Trac responde con HTML o CSV, y el servidor te devuelve JSON limpio con los links a los recursos originales intactos.

• searchTickets busca por palabras clave, número de ticket o filtros estructurados como milestone o status.
• getTicket trae un ticket completo con discusión, adjuntos y pull requests vinculados.
• getChangeset devuelve un changeset puntual, con diff opcional y truncable.
• getTimeline lee la actividad reciente de Trac, con filtro por autor y rangos de fecha.
• getTracInfo lista componentes, milestones, prioridades, severidades, tipos y estados de cada instancia.

Ojo con esto: ningún tool recibe el nombre de la instancia de Trac como parámetro. El endpoint al que te conectás decide qué Trac lee cada herramienta, así que un cliente no puede terminar leyendo datos de otra instancia por error.

Ejemplo hipotético (para ilustrar el flujo, no un caso real reportado): imaginemos que un colaborador quiere saber el estado del ticket #59446 antes de una reunión de triage. En lugar de abrir Trac, buscar el número y después cruzar manualmente el pull request en GitHub, le pregunta al asistente conectado por MCP «¿qué falta en el #59446 y qué PRs siguen abiertos?». El servidor resuelve la consulta contra Trac, trae el ticket con su discusión y los pull requests vinculados con sus checks, y el asistente responde con esa información y los links originales. El ahorro real está en no saltar entre pestañas, no en obtener datos que Trac no tuviera ya.

¿Qué datos devuelve un ticket consultado con este servidor MCP?

Un ticket consultado con getTicket trae la discusión completa, los adjuntos, los changesets relacionados y los pull requests de GitHub vinculados con sus checks y reviews, según detalla la documentación técnica del repositorio. Con ese nivel de detalle, alcanza una sola consulta para entender el estado completo de un ticket sin abrir el navegador.

El anuncio oficial ejemplifica el tipo de pregunta que podés hacerle al asistente: «¿Qué falta hacer en el ticket #59446, y qué pull requests siguen abiertos?» o «Resumime el changeset r62723 y su diff». El modelo arma la consulta MCP, el servidor la resuelve contra Trac y devuelve la respuesta con los links a los recursos originales.

Los comentarios de bots o los cambios de solo «cc» (cuando alguien se suma a la copia sin comentar) no se mezclan con la discusión humana: quedan listados aparte, bajo omittedComments, con su autor y motivo. Así, un hueco en la numeración de comentarios no se confunde con contenido perdido. Para tickets con historial largo, commentLimit devuelve hasta 500 comentarios más recientes, y la respuesta indica cuántos hay en total (totalComments) contra cuántos llegaron en esa consulta (returnedComments). Cada cambio de campo que hace una persona, aparte de los comentarios, se reporta en changes con sus valores, incluyendo ediciones de keywords y de la descripción con su link al diff. Es un nivel de detalle que replica bastante bien lo que verías abriendo el ticket en el navegador.

¿Cómo conectar Claude, ChatGPT u otro cliente MCP al servidor de WordPress Trac?

Conectar Claude Code lleva un solo comando en la terminal. Otros clientes MCP remotos usan la misma URL directo, y los que no soportan transporte HTTP nativo pueden usar mcp-remote como «traductor» local, según indica el repositorio en GitHub.

El comando completo es:

claude mcp add --transport http wordpress-trac https://wordpress-trac-mcp-server-prod.a8c-aiops.workers.dev/mcp

Para ChatGPT el endpoint no es el mismo: hay que sumar un custom app apuntando al endpoint de compatibilidad search-and-fetch en /mcp/chatgpt, porque ese cliente todavía no habla el protocolo MCP estándar completo para conexiones remotas de este tipo.

Si tu cliente no soporta HTTP transport directo, mcp-remote hace de puente local. La configuración queda en el archivo mcpServers, apuntando a la misma URL de producción con npx mcp-remote como comando, y funciona igual para conectarte a otro Trac (como /mcp/meta) desde una entrada distinta.

¿Con qué Tracs de WordPress.org funciona el servidor MCP?

El servidor cubre ocho instancias de Trac de WordPress.org: Core Trac (el default, en /mcp), Meta, Themes, Plugins, bbPress, BuddyPress, GlotPress y Google Summer of Code (GSoC), cada una con su propio endpoint, según confirma el repositorio del proyecto.

Para leer el Trac de Making WordPress.org, por ejemplo, te conectás a /mcp/meta en vez del endpoint default. Cada instancia configura sus propios campos: Themes no tiene componentes, y solo algunas instancias tienen severidades. Si le pedís a getTracInfo un campo que esa instancia no configura, la respuesta dice que no está disponible en vez de tirar error.

La tabla de instancias documentada funciona como guía, no como lista cerrada: cualquier slug del tipo <slug>.trac.wordpress.org resuelve en /mcp/<slug>, así que un Trac nuevo que WordPress.org sume más adelante no necesita cambios en el servidor.

¿Quién desarrolló el servidor MCP de WordPress Trac y qué límites tiene?

El equipo de WordPress.org da crédito a varias personas en el anuncio oficial: jonsurrell dio forma a la herramienta con issues y pull requests, James LePage escribió la primera versión del código, David Newman ayudó a configurar el hosting en Cloudflare, y obenland sumó el soporte para todas las instancias de Trac además de Core.

Es de solo lectura. No guarda credenciales de Trac.

El proyecto vive en el repositorio WordPress/trac-mcp en GitHub, bajo licencia GPL-2.0-or-later, y cualquiera puede levantarlo local con Node.js 22 y pnpm 10 para contribuir. La capa de protocolo MCP usa el SDK oficial de TypeScript y responde tanto a clientes stateless con la versión 2026-07-28 como a clientes de la era de handshake, entre el 7 de octubre de 2024 y el 25 de noviembre de 2025, con JSON plano para estos últimos. Los esquemas de entrada que ve el modelo se generan desde los mismos esquemas Zod que validan cada llamada, así que lo que el cliente ve como forma válida de pedir datos es literalmente lo que el servidor acepta. Las peticiones hacia Trac quedan restringidas a *.trac.wordpress.org y al endpoint oficial de pull requests vinculados en api.wordpress.org, con el slug de instancia validado contra un patrón estricto antes de llegar a cualquier request. Los redirects hacia otra instancia nunca se siguen, porque *.trac.wordpress.org tiene DNS comodín y redirige subdominios desconocidos a Core, lo que mezclaría datos de una instancia con otra.

Como criterio propio para decidir si conviene sumarlo al flujo de trabajo: si tu uso es puntual —consultar un ticket suelto de vez en cuando— probablemente no cambie mucho respecto a abrir Trac directo. Donde sí rinde es en tareas repetitivas de cruce de información, como triage semanal de varios tickets o seguimiento de PRs vinculados a un componente. Y antes de meterlo en un flujo diario, tiene sentido probarlo primero con un ticket público de bajo riesgo: pedile el mismo dato que verías manualmente en Trac y comparalo antes de confiar en la respuesta a ciegas.

¿Qué está confirmado y qué queda por verificar del servidor MCP de WordPress Trac?

Confirmado por el anuncio oficial: el servidor es público, gratuito, de solo lectura, corre en Cloudflare Workers y cubre las ocho instancias de Trac mencionadas arriba. También está confirmado que no cachea tickets ni guarda estado durable, según el propio repositorio.

• Confirmado: conexión sin cuenta ni API key, con endpoints /mcp y /mcp/chatgpt operativos en producción.
• Confirmado: reintentos acotados ante rate limiting y challenges de bots de Trac, con fallas 403 y 404 devueltas de inmediato.
• Sin confirmar: planes de sumar escritura, es decir, crear o editar tickets desde el asistente; el anuncio no menciona ese roadmap.

Errores comunes al usar el servidor MCP de WordPress Trac

Ninguno de estos errores es grave. Pero todos son evitables.

El primero es confundir revision con rev como parámetro de getChangeset. La herramienta espera el argumento numérico revision, no rev, y si mandás el nombre equivocado el tool devuelve un error de validación de input en vez de datos.

El segundo es pedir un filtro con un campo que esa instancia de Trac no configura. Themes, por ejemplo, no tiene componentes. Si armás un query con component= contra esa instancia, searchTickets rechaza el filtro y te dice qué campos sí existen, en vez de devolver silenciosamente el set completo de resultados sin filtrar (que es lo que haría Trac directo, y que te haría creer que ese filtro sí funcionó). Ese detalle importa: sin ese rechazo explícito, un query mal armado podría pasar por un match real cuando en realidad no filtró nada.

El tercero es no reconectar el cliente después de un cambio de configuración. Si editás la URL del servidor en tu cliente MCP, hace falta reconectar o reiniciar una vez; los deploys futuros a la misma URL no piden ese paso, pero un cambio de URL sí.

El cuarto, más de fondo: tratar los mensajes de error como parte estable de la API. Los códigos (not_found, invalid_argument, rate_limited, upstream_error) son la superficie estable para programar reintentos o manejo de errores; el texto humano del mensaje puede cambiar libremente.

Preguntas Frecuentes

¿Qué es el servidor MCP de WordPress Trac?

Es un servidor Model Context Protocol de solo lectura, público y gratuito, que WordPress.org publicó para que asistentes de IA como Claude o ChatGPT lean tickets, changesets e historial de Trac sin necesitar cuenta ni API key, según el anuncio oficial del 24 de septiembre de 2026.

¿Cómo conectar Claude Code al servidor MCP de WordPress Trac?

Con el comando claude mcp add –transport http wordpress-trac ejecutado en la terminal, seguido de la URL del servidor en producción. Otros clientes MCP remotos usan la misma URL, y los que no soportan HTTP transport nativo pueden apoyarse en mcp-remote como puente local.

¿El servidor MCP de WordPress Trac requiere cuenta o API key?

No. El anuncio oficial aclara que es público y gratuito, sin necesidad de cuenta ni API key (spoiler: ni siquiera hay que pedir acceso), porque expone información que ya es pública en las páginas de Trac de WordPress.org.

¿Qué Tracs de WordPress.org admite el servidor MCP?

Admite ocho instancias: Core (el endpoint default, /mcp), Meta (/mcp/meta), Themes, Plugins, bbPress, BuddyPress, GlotPress y GSoC, cada una con su endpoint dedicado según la documentación del repositorio en GitHub.

¿Quién desarrolló el servidor MCP de WordPress Trac?

El equipo de WordPress.org acredita a jonsurrell por dar forma a la herramienta con issues y pull requests, a James LePage por escribir la primera versión, a David Newman por el hosting en Cloudflare y a obenland por sumar el soporte a todas las instancias de Trac.

Conclusión

El servidor MCP de WordPress Trac le saca de encima al desarrollador la parte más tediosa de seguir un ticket: entrar a Trac, buscar el número, cruzar el pull request de GitHub a mano. Ahora un asistente lo hace en una consulta, con los links a los recursos originales intactos.

El punto es que el proyecto sigue siendo de solo lectura, sin capacidad de crear ni editar tickets desde el asistente todavía.

Es gratis. No pide registro.

Si contribuís a Core o seguís de cerca algún plugin del repositorio oficial, probalo esta semana con un ticket de bajo riesgo antes de sumarlo a tu flujo habitual. El peor escenario es un error de validación de input, cuyo mensaje indica cómo corregir la llamada.

Fuentes

• Make WordPress Core – Anuncio oficial del servidor MCP de WordPress Trac
• WordPress/trac-mcp en GitHub – Repositorio y documentación técnica