Saltar al contenido
Pathrule

documentación

Descripción general de MCP

Cómo el servidor MCP local de Pathrule, incluido en la CLI y la extensión de VS Code, atiende a Claude Code, Codex, Cursor, Windsurf y GitHub Copilot, y cómo Remote MCP llega al mismo espacio de trabajo.

En esta página

Pathrule habla el Model Context Protocol. Este protocolo es lo que usa tu asistente de programación con IA para llamar a herramientas externas y leer estado externo. Pathrule aparece ante el asistente como un servidor MCP normal, así que cualquier cliente compatible con MCP puede usarlo.

Hay dos formas de conectarse. El servidor local viene con Pathrule CLI y la extensión de Pathrule para VS Code: el asistente se comunica con él sobre stdio y, en un espacio de trabajo de Cloud, el runtime se comunica con Pathrule Cloud sobre HTTPS. Para los clientes que se conectan a servidores alojados, Remote MCP acepta una conexión directa sobre Streamable HTTP con inicio de sesión mediante OAuth y acceso acotado a tu espacio de trabajo. El stdio local y Remote MCP tienen catálogos de herramientas y esquemas distintos. Revisa tools/list en el servidor conectado. Pathrule no sube automáticamente el código fuente de tu repositorio; las herramientas locales de aprendizaje del proyecto pueden inspeccionar los archivos asociados a un hallazgo para validarlo.

Qué expone el servidor

La superficie MCP de Pathrule está tipada y organizada en torno al modelo de datos. Las herramientas principales que aparecen abajo cubren los flujos cotidianos de contexto, contenido y actividad; la referencia de herramientas es el inventario canónico.

El servidor local anuncia su conjunto completo, tanto lecturas como escrituras, desde el primer tools/list, así que no hay que desbloquear nada antes de la primera escritura y la lista no cambia a mitad de la sesión. Existe un modo diferido, que retiene las herramientas de escritura hasta que se necesitan, y se activa de forma opcional; consulta Control local de escritura diferida.

Herramientas de lectura

  • pathrule_get_context. El punto de entrada principal. A partir del directorio de trabajo actual y la intención del usuario, devuelve la porción adecuada de memorias, reglas y skills para esa ruta. La respuesta incluye la vista general del espacio de trabajo, las reglas y memorias que ya coinciden, y una sugerencia sobre qué leer a continuación.
  • pathrule_read_memory, pathrule_read_rule, pathrule_read_skill. Obtienen el contenido completo de un nodo concreto por su id cuando el asistente quiere citarlo o seguirlo.
  • pathrule_get_tree, pathrule_get_node. Inspeccionan la estructura del espacio de trabajo o un nodo concreto.
  • pathrule_list_memories. Enumera las memorias bajo una ruta; resulta útil para prompts de exploración.

Herramientas de escritura

  • pathrule_write_memory, pathrule_write_rule, pathrule_write_skill. Crean contenido en una ruta del espacio de trabajo. Los nodos que faltan a lo largo de la ruta se crean cuando hace falta.
  • pathrule_update_memory, pathrule_update_rule, pathrule_update_skill. Editan un registro existente. La concurrencia optimista se aplica mediante un id de versión.
  • pathrule_delete_memory, pathrule_delete_rule, pathrule_delete_skill. Eliminación lógica con un plazo de treinta días para deshacerla.

Actividad y mantenimiento

  • pathrule_log_activity. Se llama después de cualquier respuesta que modifique archivos, para que el equipo pueda ver qué hizo el asistente y dónde.
  • pathrule_goto. Cambia el nodo de trabajo del asistente cuando el usuario pide contenido de otro ámbito.
  • pathrule_ping. Una comprobación de estado que confirma que el servidor está conectado y muestra cómo ve el runtime el directorio de trabajo.

Cómo encajan los hooks

En los clientes que admiten hooks, los hooks son la forma en que Pathrule mantiene ágil al asistente. Al iniciar la sesión y alrededor de las llamadas a herramientas, el supervisor de hooks lee una porción en caché para el directorio de trabajo actual y se la entrega al agente como contexto. Así se evita una ida y vuelta síncrona a MCP en el caso habitual. El hook de inicio de sesión también entrega el propio protocolo de Pathrule, por lo que en un cliente con hooks el archivo de instrucciones de tu repositorio se queda en una nota breve.

No a todos los clientes se llega de la misma manera:

  • Claude Code y Codex tienen hooks, incluido uno al enviar el prompt, así que el conocimiento relevante llega con cada prompt, antes de que el agente actúe.
  • Cursor y GitHub Copilot tienen hooks de sesión y de herramientas, pero no un hook al enviar el prompt. El contexto llega al iniciar la sesión y alrededor de las llamadas a herramientas.
  • Windsurf no tiene hooks. Lee un archivo de reglas de Pathrule al iniciar la sesión y usa las herramientas MCP para todo lo que requiera más profundidad.

Cuando el hook basta, el asistente no necesita llamar a pathrule_get_context. Ya tiene la porción adecuada. Las herramientas MCP quedan reservadas para dos situaciones.

  1. El asistente quiere más de lo que mostró el hook. Por ejemplo, un prompt de exploración que necesita el contenido completo de una memoria, o una refactorización que toca una ruta que el hook no anticipó.
  2. Hay algo que vale la pena conservar. El asistente propone una memoria, una regla o una skill y la escribe cuando tú lo confirmas, o le pides directamente que la escriba. Las escrituras pasan por las herramientas de escritura, y cada una queda marcada como escrita por el asistente y versionada, para que puedas revisarla o deshacerla.

Consulta Cómo funcionan los hooks para conocer el mecanismo de fondo.

Integraciones con agentes

Pathrule es la capa de inteligencia; tu agente de programación sigue siendo el motor de ejecución y conserva su propio proveedor de modelos. La CLI y la extensión de VS Code conectan los agentes que ya usas al mismo espacio de trabajo mediante los hooks, archivos de instrucciones y MCP que admite cada cliente.

  • Claude Code y Codex: hooks, incluido uno al enviar el prompt, archivos de instrucciones y el servidor MCP local. Ambos también pueden conectarse a Remote MCP.
  • Cursor y GitHub Copilot: hooks de sesión y de herramientas, archivos de instrucciones y el servidor MCP local. La extensión de VS Code registra el servidor para el modo agente de Copilot.
  • Windsurf: un archivo de reglas de Pathrule y el servidor MCP local, sin hooks.
  • Cualquier otro cliente MCP: se conecta sobre stdio. Agrega el comando MCP de Pathrule a la configuración de tu cliente y verá la misma superficie de herramientas.
  • Clientes que se conectan a servidores alojados: apúntalos a Remote MCP sobre Streamable HTTP e inicia sesión con OAuth. Remote MCP no instala hooks ni escribe archivos locales.