MCP tools reference

Explore Pathrule MCP tools by runtime and purpose, including local workflow tools and the narrower Cloud-native Remote MCP catalog.

On this page

Context and discovery
Memory
Rule
Skill
Patterns
Activity
Project learning
Working preferences
Runtime events
Suggestions and refresh
Local lazy-write control
Hosted Remote MCP
Conventions
What to read next

This page inventories Pathrule's MCP tools by capability. The assistant rarely needs all of them. Most sessions touch only pathrule_get_context plus one or two reads or writes. The local stdio server and hosted Remote MCP each add only the operations their runtime can actually perform.

For the underlying model, see MCP overview.

Context and discovery

Tool	Purpose
`pathrule_get_context`	The primary entry point. Resolves the current working directory to a workspace node and returns the right slice of memories, rules, and skills for the task.
`pathrule_get_tree`	Returns the workspace node tree (folders, files, contexts). Useful for discovery prompts.
`pathrule_get_node`	Fetches a single node plus its attached memories, rules, and skills.
`pathrule_resolve`	Maps a known title or name to an id, path and version handle without walking the tree. A unique match can include the body in the same call. Local stdio.
`pathrule_read`	Batch reads memory, rule and skill ids in one round trip, up to the server cap. Local stdio.
`pathrule_knowledge_map`	A read-only map of the workspace's memories, rules and skills grouped into related regions: the whole workspace at a glance, one region's items and issues, or what else relates to given items, files or a query. Useful before a quality pass or before updating knowledge.
`pathrule_ping`	Health check. Returns the runtime's view of the current working directory and a timestamp.

Most sessions start and end with pathrule_get_context. The response carries the workspace overview, the matching content ids, and a hint about which tool to call next. The assistant follows that hint rather than guessing.

Memory

Tool	Purpose
`pathrule_list_memories`	Enumerates the memories under a path with titles and short previews. The virtual MainMemory index.
`pathrule_read_memory`	Returns the full body of a memory by id, including the version token for optimistic concurrency.
`pathrule_write_memory`	Creates a memory at a node path. Missing nodes along the path auto create. Source defaults to `claude` when called over MCP.
`pathrule_update_memory`	Edits an existing memory: a full replacement, or a small targeted edit with `content_edit`. `move_to_path` re-homes it, and `restore: true` brings back a deleted memory. Pass `expected_version_id` so a concurrent edit conflicts cleanly.
`pathrule_delete_memory`	Soft deletes a memory. Restorable until permanently deleted. `hard: true` deletes it permanently and needs a workspace admin.

The default flow is get_context to find the relevant memory id, then read_memory for the body if the assistant needs to cite it, and write_memory when the user asks to capture something.

Rule

Tool	Purpose
`pathrule_read_rule`	Returns the full body of a rule by id.
`pathrule_write_rule`	Creates a rule at a node path with a scope type (`folder`, `file_type`, `project`) and a priority (`high`, `medium`, `low`). It can also propose a block pattern or a required check; a proposal is stored as a proposal, an agent cannot approve it, and nothing is enforced until a person has approved it.
`pathrule_update_rule`	Edits an existing rule with optimistic concurrency. Also moves it to another path or restores a deleted rule.
`pathrule_delete_rule`	Soft deletes a rule. Restorable until permanently deleted.

Rules are workspace level and can be attached to more than one node. Writing a rule at the same path twice should use update, not write, to avoid duplicates.

Skill

Tool	Purpose
`pathrule_read_skill`	Returns the full SKILL.md body of a skill by id. For `github_ref` skills it returns the cached snapshot.
`pathrule_write_skill`	Creates a skill at a node path. Accepts the full SKILL.md including frontmatter. Source can be `manual`, `template`, or `github_ref`.
`pathrule_update_skill`	Edits an existing skill with optimistic concurrency. Also moves it to another path or restores a deleted skill.
`pathrule_delete_skill`	Soft deletes a skill. Restorable until permanently deleted.

For the authoring flow, see Writing skills. An assistant drafts first and calls pathrule_write_skill after the user approves the body.

Patterns

Tool	Purpose
`pathrule_import_pattern`	Previews and imports a published bundle of memories, rules and skills at the chosen workspace path.
`pathrule_remove_pattern`	Removes the pieces owned by a previously imported pattern bundle.

Activity

Tool	Purpose
`pathrule_log_activity`	Logs a structured record of a file modifying response. Required after every response that creates, edits, or deletes files. Fields: domain, action, scope, subjects, files_touched, task_summary.

The activity log feeds the workspace's recent activity, which the VS Code extension shows in its Recent Activity view, and the derived learning layers. Logging one record per response (not per file) is the right granularity.

Project learning

What an agent works out from your code, kept with the files it read and shared with the workspace. See Project learning.

Tool	Purpose
`pathrule_record_learning`	Saves a finding the agent reached by reading the code, together with the files it read and what they contained. Pathrule checks those files on disk before accepting it. A finding is not a memory, rule or skill; it reaches every member's agent as advice to verify, in the context the agent requests, while its sources are unchanged in that checkout. It is never promoted to a rule automatically. Pass the id of an earlier finding to replace it with a corrected one.
`pathrule_review_learning`	Lists current, stale and conflicting findings, including the ones held back from context, and retracts a finding by id. Only the person whose agent recorded a finding can retract it, and the retraction applies to the whole workspace.
`pathrule_review_history`	Reads past review discussion on the repository's GitHub origin through your existing `gh` login, so an agent can see how the team settled a similar question before. It stores no comments and skips bot, external and dismissed reviews; without GitHub access, everything else keeps working.

Working preferences

Tool	Purpose
`pathrule_remember_preference`	Saves how you prefer to work, quoted from your own words, for User Intelligence. A preference you state as lasting is used at once; any other is used once you state it again in a second session.

Runtime events

Tool	Purpose
`pathrule_runtime_events`	Reads the error and event groups your application reported through Signals, with their verification state. Read only; everything it returns is marked as untrusted observation.
`pathrule_runtime_events_resolve`	Records that a fix for one group shipped, so Signals verifies it against later releases. Recording is a claim, not proof.

See Agent integration for how an agent uses them.

Suggestions and refresh

Tool	Purpose
`pathrule_list_pending_refreshes`	Lists the open refresh tasks: memories and rules an assistant flagged as stale.
`pathrule_get_refresh_brief`	Claims a refresh task and returns the full repair context, including the reason it was flagged and any instructions.
`pathrule_resolve_refresh`	Marks a refresh task applied or rejected.
`pathrule_request_refresh`	Flags a memory or rule that the assistant found stale, contradictory, duplicated, too narrow or unclear during normal work.

Suggestions are how Pathrule keeps the content tree from drifting. The assistant can flag a concrete issue, claim a brief, propose a fix, and resolve it, all without leaving the editor.

Local lazy-write control

The local stdio server advertises its full tool set from the first tools/list: reads, writes, updates, deletes, patterns, refresh and activity. Nothing has to be unlocked before the first write, and the list stays the same for the whole session, so a long conversation never pays for a tool list that changes halfway through.

If you would rather start each session with a smaller list, lazy mode is available as an opt-in. Set PATHRULE_MCP_TOOLS=lazy in the environment of the Pathrule MCP entry. In lazy mode the read tools and pathrule_log_activity are visible on startup, and one extra tool appears:

Tool	Purpose
`pathrule_enable_writes`	Lazy mode only. Enables the write, update, delete, pattern and refresh-mutation tools for the rest of the MCP session. The server then emits `tools/list_changed` once.

Lazy mode removes nothing; it changes when mutation tools become visible. Without the variable, or with any other value, pathrule_enable_writes does not exist because there is nothing to enable.

Hosted Remote MCP

Remote MCP has its own Cloud-native schemas. A read grant exposes seven tools: pathrule_get_context, plus list and read tools for each of memory, rule and skill. A write grant adds write, update, delete and history for each kind, for a full catalog of nineteen tools.

Operation	Remote arguments and behavior
Context, lists and reads	Scoped to the workspace approved in the OAuth grant
Write	`path`, `title` and `body`, with a stable operation id
Update	Item `id`, numeric `expectedVersion`, `title` and `body`, with a stable operation id
Delete	Soft deletion with retained history, under the write grant
History	Per-item history, under the write grant

The authorization server recognizes pathrule:read, pathrule:write, pathrule:refresh and pathrule:activity. Recognized scopes do not add tools absent from the catalog. Remote MCP does not expose organization administration, workspace setup, pattern imports, project learning, activity logging or refresh workflows. It installs no hooks and reads no local files.

Use tools/list on the connected server to see its exact schemas. Remote MCP covers authorization and the local delivery boundary.

Conventions

The conventions below apply to the local stdio surface. Remote schemas are described above.

Path first writes. Write tools take a workspace relative node_path like /apps/api or /. If the path does not exist, intermediate nodes auto create.
Optimistic concurrency. Update and delete tools accept an expected_version_id from a prior read. A mismatch returns a clear conflict response with the current version, so the assistant can re-read and merge rather than overwrite.
Duplicates are refused. A memory whose title already exists at that path, or a rule or skill whose name already exists in the workspace, is rejected with a duplicate error, so the assistant updates the existing record instead. A memory or rule can be forced through with allow_duplicate: true after the assistant has reviewed the existing one.
Compact by default. Responses are compact for the common case. On the local server, pass verbose: true when you need the full record back.
Stable ids. Tool responses carry stable id and version_id values. The assistant can reference them in follow up calls without re reading the parent.