Pathrule Remote MCP is Pathrule's remote MCP server, exposing Pathrule workspace memories, rules, skills, settings, snapshots, and activity logs through the Model Context Protocol. Its public endpoint and registry manifest are provided in the repository (the URL and manifest contents are not yet given in cleartext in the materials and are not filled in here).
Purpose and Positioning Pathrule provides path-scoped project context for AI coding agents. The remote MCP server lets cloud MCP clients use the same Pathrule workspace data without installing Pathrule Desktop or a local CLI on the client host. Remote MCP is intentionally designed to be cloud-only: it can read and write Pathrule cloud records, but it cannot read local files, install hooks, render AGENTS.md / CLAUDE.md, or materialize local skills. When these local runtime features are needed, Pathrule Desktop or @pathrule/cli should be used. This repository is the public source and directory listing target for the Pathrule Remote MCP endpoint; it is not a standalone local memory database, and a usable Pathrule workspace cannot be created without a Pathrule account.
Main Capabilities (Tools) Workspaces and context: pathrule_list_workspaces, pathrule_get_context, pathrule_get_tree, pathrule_get_node, pathrule_list_memories, pathrule_read_memory, pathrule_read_rule, pathrule_read_skill. Workspace settings: pathrule_list_organizations, pathrule_create_workspace, pathrule_write_memory, pathrule_update_memory, pathrule_delete_memory, pathrule_write_rule, pathrule_update_rule, pathrule_delete_rule, pathrule_write_skill, pathrule_update_skill, pathrule_delete_skill. Snapshots, refreshes, and activity: pathrule_take_snapshot, pathrule_list_snapshots, pathrule_read_snapshot, pathrule_list_pending_refreshes, pathrule_get_refresh_brief, pathrule_resolve_refresh, pathrule_log_activity, pathrule_get_local_runtime_upgrade.
How to Use Create or sign in to a Pathrule account; create or select a Pathrule workspace in the app; connect an MCP client to the corresponding remote MCP endpoint. When the MCP client connects, it starts the OAuth flow through Pathrule Web. After approval, the client can only access Pathrule workspaces visible to that signed-in account using the approved scopes.
Permissions and Security OAuth scopes determine the available tool surface: read tools require pathrule:read; write tools require pathrule:write; refresh/activity tools require pathrule:activity. Every workspace operation is performed through the authenticated user's Supabase JWT and database RLS policies. The connector does not use Supabase admin keys to expand user access. Write tools are also subject to workspace subscription status and per-user/per-workspace rate limits. MCP event telemetry contains only metadata: tool name, user/workspace/client identifiers, status/error codes, and latency buckets; tool inputs and content bodies are not logged. The remote server never accesses the user's filesystem and never writes local companion files.
Self-Deployment (for Operators) The mcp.pathrule.io service is operated by Pathrule. The environment variables below are used by Pathrule operators to deploy the service to the Pathrule backend; these variables are not required when connecting an MCP client to Pathrule Remote MCP. The required production secrets are provided only as environment variables. Do not commit the following values (variable names are per the materials; specific values are not expanded here): SUPABASE_JWT_SECRET is used for Supabase RLS Issuing short-lived authenticated role user JWTs should be handled as production infrastructure secret material and stored only in the hosting provider's secret manager. The public pathrule/mcp repository is split out from the Pathrule monorepo and contains a packaged Node.js server, provided for transparency and deployment reproducibility. Running it yourself requires the above environment variables and a Pathrule-compatible backend, and is not the recommended user installation path. The server listens on PORT and HOST (see the repository for specific variable descriptions). Health and metadata, registry checks: the public repository contains a Dockerfile for use by MCP registry scanners such as Glama. The container sets PATHRULE_MCP_PUBLIC_INTROSPECTION=1, which exposes MCP schema introspection without a bearer token so registries can verify the server shape. This mode does not grant access to Pathrule data; tool calls still require an authenticated Pathrule context, and return an authentication error when there is no OAuth. Glama's Docker build runner starts the MCP server via stdio; use the corresponding command in Glama's Dockerfile management form (the specific command details are not provided).
MCP directory submission field: Pathrule Remote MCP server. See the repository for the security policy.
Applicable scenarios and limitations Suitable for scenarios where cloud MCP clients need to access Pathrule workspace memory, rules, skills, snapshots, and activity logs, and especially suitable for users who do not want to install a local desktop app or CLI on the controlled host. Limitations: cloud only; cannot read or write local files, cannot install hooks, cannot generate AGENTS.md / CLAUDE.md, cannot deploy local skills; cannot be used independently of a Pathrule account; write operations are subject to subscription and rate limits.
