MCP overview

Pathrule speaks the Model Context Protocol. The protocol is what your AI coding assistant uses to call into external tools and read external state. Pathrule shows up to the assistant as a normal MCP server, so any client that can speak MCP can use it.

There are two ways to connect. The local server comes with Pathrule CLI and the Pathrule VS Code extension: the assistant talks to it over stdio, and on a Cloud workspace the runtime talks to Pathrule Cloud over HTTPS. For clients that connect to hosted servers, Remote MCP accepts a direct connection over Streamable HTTP with OAuth sign-in and scoped access to your workspace. Local stdio and Remote MCP have different tool catalogs and schemas. Inspect tools/list on the connected server. Pathrule does not automatically upload your repository source code; local project-learning tools can inspect files attached to a finding to validate it.

What the server exposes

Pathrule's MCP surface is typed and grouped around the data model. The core tools below cover everyday context, content and activity flows; the tools reference is the canonical inventory.

The local server advertises its whole set, reads and writes alike, from the first tools/list, so nothing has to be unlocked before the first write and the list does not change mid-session. A lazy mode that holds write tools back until they are needed is available as an opt-in; see Local lazy-write control.

Read tools

• pathrule_get_context. The primary entry point. Given the current working directory and the user's intent, it returns the right slice of memories, rules, and skills for that path. The response carries the workspace overview, the rules and memories that already match, and a hint about what to read next.
• pathrule_read_memory, pathrule_read_rule, pathrule_read_skill. Fetch the full body of a specific node by id when the assistant wants to cite or follow it.
• pathrule_get_tree, pathrule_get_node. Inspect the workspace structure or a specific node.
• pathrule_list_memories. Enumerate the memories under a path, useful for discovery prompts.

Write tools

• pathrule_write_memory, pathrule_write_rule, pathrule_write_skill. Create content at a workspace path. Missing nodes along the path are created on demand.
• pathrule_update_memory, pathrule_update_rule, pathrule_update_skill. Edit an existing record. Optimistic concurrency is enforced with a version id.
• pathrule_delete_memory, pathrule_delete_rule, pathrule_delete_skill. Soft delete with a thirty day undo window.

Activity and housekeeping

• pathrule_log_activity. Called after any file modifying response so the team can see what the assistant did and where.
• pathrule_goto. Move the assistant's working node when the user asks for content from a different scope.
• pathrule_ping. A health check that confirms the server is wired up and shows the runtime's view of the working directory.

How hooks fit in

On clients that support hooks, hooks are how Pathrule keeps the assistant fast. At session start and around tool calls, the hook supervisor reads a cached slice for the current working directory and hands it to the agent as context. This avoids a synchronous MCP round trip for the common case. The session-start hook also delivers the Pathrule protocol itself, so on a hook-capable client the instruction file in your repo stays a short note.

Not every client is reached the same way:

• Claude Code and Codex have hooks including a prompt-submit hook, so the relevant knowledge arrives with each prompt, before the agent acts.
• Cursor and GitHub Copilot have session and tool hooks but no prompt-submit hook. Context arrives at session start and around tool calls.
• Windsurf has no hooks. It reads a Pathrule rules file at session start and uses the MCP tools for everything deeper.

When the hook is enough, the assistant does not need to call pathrule_get_context. It already has the right slice. MCP tools are reserved for two scenarios.

1. The assistant wants more than the hook surfaced. For example, a discovery prompt that needs the full memory body, or a refactor that touches a path the hook did not anticipate.
2. Something is worth keeping. The assistant proposes a memory, rule, or skill and writes it once you confirm, or you ask it to write one directly. Writes go through the write tools, and each one is marked as written by the assistant and versioned, so you can review or undo it.

See How hooks work for the underlying mechanics.

Agent integrations

Pathrule is the intelligence layer; your coding agent stays the execution engine and keeps its own model provider. The CLI and the VS Code extension connect the agents you already use to the same workspace through each client's supported hooks, instruction files and MCP.

• Claude Code and Codex: hooks including a prompt-submit hook, instruction files and the local MCP server. Both can also connect to Remote MCP.
• Cursor and GitHub Copilot: session and tool hooks, instruction files and the local MCP server. The VS Code extension registers the server for Copilot agent mode.
• Windsurf: a Pathrule rules file and the local MCP server, with no hooks.
• Any other MCP client: connects over stdio. Add the Pathrule MCP command to your client's config and it will see the same tool surface.
• Clients that connect to hosted servers: point them at Remote MCP over Streamable HTTP and sign in with OAuth. Remote MCP installs no hooks and writes no local files.

What to read next

• How hooks work for what happens between the cache and the editor.
• Core concepts for the data model the tools operate on.
• CLI install for setting up the runtime that hosts the server.