Un desarrollador construyó un plugin MCP para PhpStorm que expone el debugger nativo del IDE como herramientas consumibles por un agente de IA. El plugin MCP PhpStorm debugger usa el Model Context Protocol para que un cliente como Claude Desktop o Cursor controle breakpoints, inspeccioné variables y recorra el call stack sin intervención manual.

En 30 segundos

  • MCP (Model Context Protocol) es un estándar abierto que conecta agentes de IA con herramientas externas mediante tools, resources y prompts con schemas tipados.
  • El plugin convierte el debugger de PhpStorm en un servidor MCP: el agente puede establecer breakpoints, ejecutar step-over/step-into, evaluar expresiones y leer el call stack en tiempo real.
  • MCP es distinto a ACP (Agent Client Protocol), co-desarrollado por JetBrains y Zed Industries en 2026 para conectar agentes como Cursor a IDEs JetBrains.
  • Los clientes compatibles incluyen Claude Desktop, Cursor y VS Code con GitHub Copilot Business/Enterprise (con la política «MCP servers in Copilot» habilitada).
  • El riesgo principal es que el agente modifique estado del debugger sin supervisión: la configuración en modo read-only por defecto y aprobación manual para acciones destructivas son esenciales.

Qué es MCP y por qué importa para el debugging en PhpStorm

MCP (Model Context Protocol) es un estándar abierto que define cómo un agente de IA se conecta con herramientas externas. El protocolo organiza la comunicación en tres componentes: tools (acciones que el agente puede ejecutar), resources (datos que puede leer) y prompts predefinidos que guían el comportamiento del agente. La idea es que cualquier herramienta, desde una base de datos hasta un debugger de IDE, pueda exponerse como un servidor MCP y ser consumida por cualquier cliente compatible.

Eso está bien en abstracto. Lo interesante es que alguien se tomó el trabajo de aplicarlo al debugger de PhpStorm, que históricamente fue una de esas herramientas que solo sabés usar vos, en tu máquina, mirando la pantalla. Ahora un agente puede manejarlo.

Para entender el contexto: MCP no es lo mismo que ACP. El Agent Client Protocol (ACP) lo co-desarrollaron JetBrains y Zed Industries para que agentes como Cursor se conecten directamente a IDEs JetBrains (IntelliJ, PyCharm, WebStorm). MCP es más amplio y horizontal: conecta IA con cualquier herramienta externa. El plugin de debugging usa MCP, no ACP. Son capas distintas y en 2026 conviven sin reemplazarse.

Cómo funciona el plugin MCP en PhpStorm

La arquitectura es directa. El plugin corre dentro de PhpStorm como un servidor MCP local y expone las capacidades del debugger nativo como tools consumibles por cualquier cliente MCP. El transporte puede ser STDIO o HTTP, dependiendo de cómo lo configurés.

El agente de IA manda un comando al servidor MCP, el servidor lo traduce a una acción del debugger de PhpStorm, el debugger ejecuta y devuelve el estado, y el servidor MCP empaqueta esa respuesta en el schema que el agente espera. Todo con validación de inputs y outputs tipados. Eso es lo que diferencia esto de una integración artesanal a pura API: el schema forzado reduce la superficie de errores de interpretación del agente (que no es poca fuente de problemas en estos flujos).

Podés conectar clientes distintos al mismo servidor. Claude Desktop, Cursor, o VS Code con GitHub Copilot. Para Copilot, la documentación oficial de GitHub aclara que necesitás habilitar la política «MCP servers in Copilot» en tu organización, disponible para planes Business y Enterprise.

El debugger como herramienta MCP: qué puede hacer el agente

Ponele que tenés un bug en producción que no podés reproducir de forma determinista. Normalmente abrís PhpStorm, ponés un breakpoint, recargás la request, esperás que entre, mirás variables, hacés step-over cuatro veces, te distraés, perdés el estado. Con el plugin, le describís el problema al agente y él hace ese ciclo por vos, leyendo los valores y reportándote qué encontró. Tema relacionado: protege tu entorno de desarrollo.

Las acciones concretas que el plugin expone como tools MCP:

  • Establecer y eliminar breakpoints en archivos y líneas específicas
  • Ejecutar step-over, step-into y step-out
  • Evaluar expresiones en runtime (como hacés desde el panel «Evaluate Expression» de PhpStorm)
  • Inspeccionar variables locales y globales en el frame actual
  • Leer el call stack completo
  • Continuar la ejecución hasta el próximo breakpoint o hasta el final

Comparado con el debugging manual tradicional, la diferencia no es solo comodidad. El agente puede iterar sobre múltiples hipótesis en segundos, establecer breakpoints condicionales y evaluar expresiones encadenadas sin que vos toques el teclado. Lo que antes llevaba 20 minutos de ir y volver puede resolverse en un ciclo automatizado.

Configuración del plugin MCP en PhpStorm paso a paso

Los prerrequisitos son simples: PhpStorm actualizado a una versión reciente de 2026, el plugin instalado desde el marketplace de JetBrains, y un cliente MCP configurado (Claude Desktop, Cursor, o VS Code con Copilot habilitado para MCP).

Instalación y configuración básica

Instalás el plugin desde Settings > Plugins en PhpStorm. Una vez activo, el plugin levanta un servidor MCP local. Elegís el transporte: STDIO si tu cliente corre en la misma máquina (más simple, menos overhead), HTTP si necesitás conectarte desde otra máquina o proceso.

La configuración del cliente se hace con un JSON. Un ejemplo típico para STDIO:

{
 "mcpServers": {
 "phpstorm-debugger": {
 "command": "phpstorm",
 "args": ["mcp-server"],
 "transport": "stdio"
 }
 }
}

Para HTTP, apuntás a localhost con el puerto que configuraste en el plugin. El cliente descubre automáticamente las tools disponibles haciendo un request de capabilities al servidor (eso es parte del handshake MCP estándar).

Control de permisos desde el arranque

Aca viene lo bueno: el plugin te deja definir qué tools están disponibles para el agente. Podés arrancar con un subset read-only (leer variables, leer call stack, leer breakpoints existentes) y agregar las acciones destructivas (modificar estado, evaluar expresiones que tienen side effects) solo cuando las necesitás. El permission_callback en cada tool es el punto de control. Si no lo configurás, el agente tiene acceso a todo. Y eso es un problema.

Diferencias entre MCP y ACP en el ecosistema JetBrains

La confusión entre los dos protocolos es entendible porque ambos aparecen juntos cuando hablás de IA y JetBrains IDEs en 2026. Más contexto en comparativa de plugins gratuitos.

CaracterísticaMCP (Model Context Protocol)ACP (Agent Client Protocol)
Desarrollado porAnthropic (estándar abierto)JetBrains + Zed Industries
PropósitoConectar IA con herramientas externas (APIs, plugins, servicios)Conectar agentes con IDEs JetBrains directamente
ScopeUniversal: cualquier herramienta puede ser un servidor MCPEspecífico para el ecosistema JetBrains
TransporteSTDIO, HTTPPropio del protocolo ACP
Ejemplo de usoPlugin de debugger PhpStorm, GitHub MCP Server, WordPress MCP AdapterCursor conectándose a IntelliJ, PyCharm, WebStorm
Interfaces interactivasCursor 2.6 con MCP Apps (charts, diagramas, whiteboards)No orientado a UI interactiva
plugin mcp phpstorm debugger diagrama explicativo

Cursor 2.6, según el análisis de donweb.news sobre ACP y MCP Apps, usa MCP Apps para renderizar interfaces interactivas dentro del chat: gráficos de Amplitude, diagramas de Figma, whiteboards con tldraw. Eso es MCP del lado de Cursor. El plugin de debugging de PhpStorm es MCP del lado del IDE. Dos usos distintos del mismo protocolo.

Comparación con otras integraciones MCP en el ecosistema

Para dimensionar qué hace único a este plugin, vale compararlo con otras implementaciones MCP que están activas en 2026.

El GitHub MCP Server está disponible para todos los usuarios de GitHub. Las tools que expone heredan los permisos de las features correspondientes de tu cuenta: si no tenés acceso a un repo, el agente tampoco lo tiene a través del servidor MCP. El scope es gestión de código, issues, PRs.

El WordPress MCP Adapter traduce la Abilities API de WordPress a componentes MCP: tools, resources y prompts. Los agentes pueden publicar posts, leer contenido, modificar configuraciones. WordPress abrió su plataforma a agentes de IA con esta capa de abstracción. Es una integración de plataforma web.

El plugin de debugging de PhpStorm es diferente en un punto clave: expone el estado interno de ejecución de un proceso en tiempo real, no datos persistidos en una plataforma. Eso lo hace más dinámico y también más delicado de manejar.

Limitaciones y consideraciones de seguridad

Ojo con esto: un agente que controla el debugger tiene acceso al estado de ejecución de tu aplicación. En un entorno de desarrollo local eso puede parecer inocuo. Pero si el entorno tiene conexiones a bases de datos reales, credenciales en variables de entorno, o acceso a servicios externos, la superficie de riesgo sube.

El problema más obvio es un agente que evalúa una expresión con side effects sin que vos lo aprobés. «Evaluar» en runtime puede significar ejecutar código arbitrario dentro del contexto del proceso que estás depurando. Eso no es una vulnerabilidad del plugin en sí, es la naturaleza del debugging. Pero cuando el agente lo hace autónomamente, el riesgo de que ejecute algo que no querías es real.

Te llega un contexto de bug complicado, el agente empieza a explorar, establece 15 breakpoints, evalúa expresiones en cadena, modifica una variable «para probar», y de repente el estado de tu sesión de debug está completamente alterado y no sabés en qué punto el agente introdujo el cambio. (Sí, suena exagerado. Pero cualquiera que haya debuggeado con un junior ansioso al teclado sabe exactamente a qué me refiero.) Relacionado: mantén estable tu infraestructura.

Las mejores prácticas concretas:

  • Modo read-only por defecto: habilitá solo las tools de lectura para el agente en primera instancia
  • Aprobación manual para acciones que modifican estado: step-into, evaluar expresiones con side effects, modificar variables
  • Nunca uses el plugin en un entorno conectado a producción
  • Revisá los logs del servidor MCP regularmente para auditar qué tools ejecutó el agente

El futuro del debugging asistido por IA en IDEs JetBrains

La dirección es clara: agentes que detectan bugs, proponen fixes y los validan usando el debugger en un ciclo autónomo. El plugin que analizamos es un paso concreto en esa dirección, pero todavía requiere supervisión activa.

JetBrains apuesta por ACP como estándar propio para la integración de agentes con sus IDEs. MCP complementa eso al permitir integraciones granulares como esta, donde un plugin específico expone capacidades que ACP no cubre por defecto. La convergencia posible es que JetBrains adopte MCP como capa de extensibilidad sobre ACP, o que los agentes usen ACP para conectarse al IDE y MCP para consumir plugins especializados dentro de él.

Para equipos de QA, el impacto potencial es grande: un agente que puede reproducir un bug reportado, recorrer el call stack, identificar el punto de falla y proponer un fix, todo antes de que el desarrollador abra el IDE. Habría que ver cuánto de eso es marketing y cuánto es realidad operativa en flujos reales de 2026. Por ahora, el plugin demuestra que la plomería técnica está.

Errores comunes al configurar MCP en entornos de desarrollo

Dejar todas las tools habilitadas desde el primer día

El error más frecuente es conectar el cliente MCP con acceso completo al servidor y olvidarse. Si el agente tiene acceso a evaluar expresiones y modificar estado sin restricciones, cualquier alucinación o interpretación errónea del contexto puede alterar el entorno de debug de formas difíciles de rastrear. Arrancá con read-only y agregá permisos gradualmente.

Confundir MCP con ACP y usar el cliente equivocado

Si instalás el plugin MCP y tratás de conectarte usando únicamente ACP (por ejemplo, asumiendo que Cursor lo maneja automáticamente por la integración JetBrains), vas a tener problemas de handshake. El plugin es un servidor MCP, no ACP. Necesitás un cliente MCP explícito: Claude Desktop con la config JSON, Cursor en modo MCP, o VS Code con la extensión de Copilot configurada para MCP servers.

Usar transporte HTTP sin autenticación en redes compartidas

Si configurás el servidor MCP con transporte HTTP y lo dejás escuchando en 0.0.0.0 en vez de 127.0.0.1, cualquier proceso en la misma red puede enviarle comandos. En una oficina o coworking, eso es un problema serio. STDIO es la opción correcta para uso local. Si necesitás HTTP, restringí el binding a localhost y agregá autenticación básica como mínimo. Te puede servir nuestra cobertura de vulnerabilidades en pipelines CI/CD.

Asumir que el agente entiende el contexto del proyecto sin darle información

MCP te deja definir prompts predefinidos que guían al agente. Si no los configurás, el agente arranca el debugging sin contexto: no sabe qué módulo estás depurando, cuál es el comportamiento esperado, ni qué variables son relevantes. El resultado son ciclos de exploración largos y poco enfocados. Dedicá 10 minutos a escribir un prompt base con el contexto del proyecto antes de largar al agente.

Preguntas Frecuentes

¿Qué es un plugin MCP para PhpStorm?

Un plugin MCP para PhpStorm es un servidor MCP que corre dentro del IDE y expone las capacidades del debugger nativo como tools consumibles por agentes de IA. Cualquier cliente compatible con el Model Context Protocol puede conectarse y controlar breakpoints, inspeccionar variables y navegar el call stack sin intervención manual.

¿Necesito Cursor para usar MCP en PhpStorm?

No. Cursor es uno de los clientes MCP posibles, pero podés usar Claude Desktop o VS Code con GitHub Copilot Business/Enterprise (habilitando la política «MCP servers in Copilot» en tu organización). El plugin es agnóstico al cliente: cualquier implementación del protocolo MCP estándar puede conectarse.

¿Cuál es la diferencia entre MCP y ACP en JetBrains?

ACP (Agent Client Protocol) es el protocolo co-desarrollado por JetBrains y Zed Industries específicamente para conectar agentes como Cursor con IDEs JetBrains. MCP es un estándar abierto más amplio para conectar IA con cualquier herramienta externa. El plugin de debugging usa MCP porque expone capacidades de una herramienta específica (el debugger), no la integración general con el IDE.

¿Es seguro dejar que un agente de IA controle el debugger de PhpStorm?

En entornos de desarrollo local aislados, el riesgo es manejable si configurás permisos correctamente. El punto crítico es no usarlo conectado a entornos con credenciales reales o acceso a producción, y arrancar siempre en modo read-only. El agente puede evaluar expresiones con side effects si le das acceso completo, lo que puede alterar el estado de tu sesión de debug de formas difíciles de revertir.

Conclusión

El plugin MCP PhpStorm debugger es un caso concreto de algo que se viene hablando en abstracto hace meses: agentes de IA integrados al flujo real de desarrollo, no solo generando código sino interactuando con el estado de ejecución. Que alguien se haya tomado el trabajo de construirlo y publicarlo en 2026 confirma que la plomería del protocolo MCP ya es lo suficientemente madura para proyectos serios.

Dicho esto, la adopción responsable requiere configuración explícita de permisos desde el arranque. No es una herramienta para largar y olvidar. El valor está en los ciclos de debugging asistido donde vos definís el contexto y el agente hace el trabajo iterativo. El control sigue siendo tuyo.

Si trabajás con PHP y usás PhpStorm regularmente, vale la pena instalarlo en un entorno de desarrollo aislado y probar un ciclo completo. El tiempo que ahorrás en debugging manual es real. Si necesitás un entorno de hosting confiable para tus proyectos PHP donde probar estas integraciones, donweb.com tiene opciones de VPS con soporte para entornos de desarrollo modernos.

Fuentes

Categorizado en: