One contract, every surface
Pathrule exposes one typed MCP contract. Shared tools keep the same names and shapes across runtimes, while local, remote and Studio-specific capabilities are explicit additions.
Pathrule exposes one Model Context Protocol contract. Every shared tool keeps the same name, arguments and response shape wherever it is available. A surface can add capabilities that only make sense there, such as hosted workspace setup on Remote MCP or simulator control inside Studio, without changing the shared tools underneath.
The short version: pick the entry point that fits your machine and your AI client. The common tools and workspace stay stable, and tools/list tells the truth about the additions that surface can actually execute.
The surfaces
Pathrule Studio 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 and connects Cursor, Windsurf and GitHub Copilot, so the agent in your editor reaches the same tools with no JSON to hand-edit. It can also wire standalone Claude Code and Codex. Cursor and Windsurf are VS Code forks, so the extension is available to them too.
Pathrule Web is the browser management console for your organization, members, billing, workspaces and usage. It is cloud-only and does not touch your filesystem. You author knowledge and run agents in Pathrule Studio, not in the browser.
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.
Shared tools keep one shape
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) keep the same names and shapes across the surfaces that expose them. The same holds for activity and refresh tools. An integration can therefore reuse a shared tool without translating a second API.
Availability is capability-based. The local stdio server adds efficient local workflow tools such as batch read and name resolution. Remote MCP adds organization, workspace and snapshot operations that require a hosted account boundary. Studio can add design, task, run and simulator bridges because it owns those live surfaces. The MCP tools reference inventories these groups explicitly.
See MCP overview and the MCP tools reference for the full list.
Local and remote boundaries
Local runtimes know your working directory and active file, so context can arrive before the first tool call through client-native delivery. The remote endpoint has no cwd to read, so workspace-scoped tools take an explicit workspace_id and protocol text is sent by default.
No Pathrule MCP 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 Studio runs Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode as its primary agents. Pathrule CLI is the lighter integration route for Cursor, Windsurf and GitHub Copilot, 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 agents, 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 an MCP client at a Pathrule runtime and run tools/list. Shared pathrule_ tools retain their contract, and surface-specific tools appear only where their required capability exists.
Which entry point
Choose by where you work and what your client supports.
| Surface | Reach the contract by | Best for |
|---|---|---|
| Studio (macOS) | Local stdio server in a native app | Coding with Claude Code, Codex, Grok, Kimi, Antigravity and OpenCode, authoring knowledge, the full workbench |
| CLI | Local stdio server from the terminal | Cursor, Windsurf and GitHub Copilot integrations, terminal-first setup, scripts, CI, SSH |
| VS Code (and forks) | Bundled local server, one-command agent wiring | The editor you already use, with no hand-edited config |
| Web | Cloud management console | Organization, members and roles, billing, workspace admin, usage |
| 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 management console that shares the same cloud.