One contract, every surface
Pathrule exposes one MCP tool contract. The same tools serve Desktop, Web, CLI, VS Code, and Remote MCP, and reach Claude Code, Cursor, Codex, Windsurf, and GitHub Copilot. Tool-agnostic, low lock-in.
Pathrule exposes one Model Context Protocol tool contract. The tool names, their arguments, and their responses are the same no matter how you connect. A surface is a way to host or reach that contract. It is not a different product with a different API.
The short version: pick the entry point that fits your machine and your AI client. The tools you call, and the workspace they read and write, do not change.
The surfaces
Pathrule Desktop and Pathrule CLI are local runtimes. They host the MCP server on your machine and your assistant talks to it over stdio. The runtime talks to the Pathrule cloud over HTTPS.
The VS Code extension is a third local entry point. It runs the same bundled CLI server, registers it with GitHub Copilot agent mode, and writes managed MCP entries for Claude Code, Cursor, Codex, and Windsurf, so the agent in your editor reaches the same tools with no JSON to hand-edit. Cursor and Windsurf are VS Code forks, so the extension is available to them too.
Pathrule Web is the browser control center. It is cloud-only and does not touch your filesystem on its own. When it needs local capability it pairs with a Pathrule CLI runtime over a scoped localhost bridge.
Pathrule Remote MCP is a hosted endpoint at https://mcp.pathrule.io/mcp. AI clients that can only reach a cloud connector authenticate with OAuth and call the cloud-safe part of the same contract over streamable-http. There is nothing to install.
The same tools, named the same way
Every surface speaks the same MCP. The read tools (pathrule_get_context, pathrule_read_memory, pathrule_read_rule, pathrule_read_skill, pathrule_get_tree, pathrule_get_node, pathrule_list_memories) and the write tools (pathrule_write_memory, pathrule_write_rule, pathrule_write_skill, and their update and delete counterparts) carry the same names and the same shapes across surfaces, so a tool you learn on one surface behaves the same on the next. pathrule_log_activity, pathrule_goto, and pathrule_ping round out the contract. Local surfaces expose the full set over stdio; the remote endpoint exposes the cloud-safe part of the same contract over OAuth.
See MCP overview and the MCP tools reference for the full list.
Local and remote, and what differs
Local surfaces and the remote endpoint differ in exactly two ways, and both are about the machine, not the tools.
First, local context. Local runtimes know your working directory and active file, so context can arrive before the first tool call through hooks. The remote endpoint has no cwd to read, so workspace-scoped tools take an explicit workspace_id and protocol text is sent by default.
Second, the filesystem boundary. No Pathrule surface has a tool that reads your source files. On local surfaces your code never leaves the machine and only team-written content is stored in the cloud. The remote endpoint is cloud-only by design: it cannot read local files or run hooks, the same boundary as Pathrule Web.
Tool-agnostic, low lock-in
Pathrule is client-agnostic. Claude Code, Cursor, Codex CLI, Windsurf, and GitHub Copilot are first-class, and any client that speaks MCP can connect by adding the Pathrule MCP command to its config. Because the contract is plain MCP, you are not committing to one editor or one vendor. Switch editors, add a teammate on a different client, or move from a local runtime to the hosted endpoint, and the tools and the workspace stay the same.
Verify it yourself: point any MCP client at a Pathrule runtime and run tools/list. The same pathrule_ tools come back on every surface.
Which entry point
Choose by where you work and what your client supports.
| Surface | Reach the contract by | Best for |
|---|---|---|
| Desktop | Local stdio server in a native app | The full UI plus local repo access in one bundle |
| CLI | Local stdio server from the terminal | Terminal-first setup, scripts, CI, SSH, Web pairing |
| VS Code (and forks) | Bundled local server, one-command agent wiring | The editor you already use, with no hand-edited config |
| Web | Cloud control center, pairs with the CLI | Account, team, billing, cloud content review |
| Remote MCP | Hosted OAuth endpoint over streamable-http | Clients that only reach a hosted connector, or a fresh machine |
Cloud content is shared across every surface and one sign-in follows you between them. Local runtime state stays scoped to the current user and machine.
What to read next
- MCP overview for how Pathrule exposes its tools and how hooks fit in.
- MCP tools reference for the full tool list and arguments.
- Pathrule Web for the browser control center that shares the same cloud.