Pathrule

Pathrule Project Snapshot

pathrule_take_snapshot

Record a point-in-time inventory of the user's project under a workspace. Remote MCP cannot see the filesystem, so YOU (the AI) collect this inventory with your own Read/Glob/Grep tools before calling this. Persist it so future setup, bootstrap, drift detection, and onboarding flows have structured evidence to reason over. Required: workspace_id. Strongly recommended: project_name, file_count, file_tree (cap at ~5000 entries — summarise deeper paths), file_extensions_summary, top_level_dirs, sampled_contents for README, package.json / pyproject.toml / Cargo.toml, CLAUDE.md, AGENTS.md, main config files (truncate each to ~4KB). Optional: git_head / branch / git_log_summary if you can read them, ai_notes for free-form observations.

Input Schema

TableJSON Schema

Name	Required	Description
`branch`	No	Checked-out branch name at snapshot time.
`source`	No	Which Pathrule surface produced this snapshot. Defaults to 'mcp-remote'.
`ai_notes`	No	Your own observations about the project structure, conventions, and obvious workspace seeds.
`git_head`	No	Commit SHA that HEAD pointed at when the snapshot was taken.
`metadata`	No	Free-form additional structured data.
`file_tree`	No	Flat list of files/directories. Cap at 5000.
`root_path`	No	Absolute root path if the AI is running on the user's machine; otherwise omit.
`file_count`	No	Total number of files inventoried, before any file_tree cap is applied.
`project_name`	No	Display name of the project, usually the repository or folder name.
`workspace_id`	Yes	Workspace UUID this snapshot belongs to.
`git_remote_url`	No	Origin remote URL of the repository, or null when it has none.
`top_level_dirs`	No	Immediate child directories of the project root with their sizes, so future flows can see the shape of the tree without the full file list.
`git_log_summary`	No	Free-form summary of recent git activity if available (e.g. 'last 50 commits hot paths: src/foo.ts, src/bar.ts; bug fixes in api/').
`sampled_contents`	No	Truncated contents of up to 50 important files (README, manifest files, CLAUDE.md/AGENTS.md, primary configs). Each content field capped at ~4096 bytes.
`total_size_bytes`	No	Combined size in bytes of the inventoried files.
`file_extensions_summary`	No	e.g. {"ts": 412, "tsx": 158, "json": 33}

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	true when the call succeeded. false when it did not, in which case `error` carries the reason and the success fields are absent.
`data`	No	What was stored, including the counts after server-side trimming.
`error`	No	Present only when ok is false.
`human_message`	No	One-line summary of the result, safe to relay to the user verbatim.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed8 schema fields changedSep 5, 2026

addedInput schema / properties / branch / description

Added value: +"Checked-out branch name at snapshot time."

addedInput schema / properties / file_count / description

Added value: +"Total number of files inventoried, before any file_tree cap is applied."

addedInput schema / properties / git_head / description

Added value: +"Commit SHA that HEAD pointed at when the snapshot was taken."

addedInput schema / properties / git_remote_url / description

Added value: +"Origin remote URL of the repository, or null when it has none."

addedInput schema / properties / project_name / description

Added value: +"Display name of the project, usually the repository or folder name."

addedInput schema / properties / top_level_dirs / description

Added value: +"Immediate child directories of the project root with their sizes, so future flows can see the shape of the tree without the full file list."

addedInput schema / properties / total_size_bytes / description

Added value: +"Combined size in bytes of the inventoried files."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "What was stored, including the counts after server-side trimming.",
+      "properties": {
+        "created_at": {
+          "description": "Creation timestamp in ISO 8601.",
+          "type": "string"
+        },
+        "file_count": {
+          "description": "Recorded file count, or null.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "file_tree_entries_recorded": {
+          "description": "How many file-tree entries were stored.",
+          "type": "number"
+        },
+        "project_name": {
+          "description": "Recorded project name, or null.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "sampled_files_recorded": {
+          "description": "How many sampled file bodies were actually stored after server-side trimming.",
+          "type": "number"
+        },
+        "snapshot_id": {
+          "description": "UUID of the stored snapshot. Pass it to pathrule_read_snapshot.",
+          "type": "string"
+        },
+        "source": {
+          "description": "Pathrule surface that produced it.",
+          "type": "string"
+        },
+        "workspace_id": {
+          "description": "Workspace the snapshot belongs to.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "snapshot_id",
+        "workspace_id",
+        "source",
+        "project_name",
+        "file_count",
+        "created_at",
+        "sampled_files_recorded",
+        "file_tree_entries_recorded"
+      ],
+      "type": "object"
+    },
+    "error": {
+      "additionalProperties": true,
+      "description": "Present only when ok is false.",
+      "properties": {
+        "code": {
+          "description": "Stable machine-readable failure code, for example insufficient_scope, workspace_id_required, rate_limited, not_found, or upstream_error. Branch on this, not on message text.",
+          "type": "string"
+        },
+        "detail": {
+          "description": "Optional structured context for the failure, for example { missing_scopes: [...] } on insufficient_scope."
+        },
+        "message": {
+          "description": "Human-readable explanation of the failure.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "code",
+        "message"
+      ],
+      "type": "object"
+    },
+    "human_message": {
+      "description": "One-line summary of the result, safe to relay to the user verbatim.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "true when the call succeeded. false when it did not, in which case `error` carries the reason and the success fields are absent.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

First observedMay 27, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial context beyond the annotations: it discloses that remote MCP cannot see the filesystem, that the AI must collect data itself, that the snapshot persists for future workflows, and that file_tree is capped at ~5000 entries with deeper paths summarized and sampled contents truncated to ~4KB. These are behaviorally important details not present in the annotation block, and nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: purpose, the critical filesystem limitation, persistence rationale, and a clearly tiered parameter list. It is front-loaded with the most important behavioral constraint and uses a natural priority ordering that makes scanning easy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter nested-object tool with an output schema, the description covers the essential workflow, data-collection strategy, field priorities, and size constraints. Since an output schema exists, the description does not need to explain return values, and nothing critical for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches the schema by prioritizing parameters (required vs strongly recommended vs optional), giving concrete examples for sampled_contents (README, package.json, pyproject.toml, Cargo.toml, CLAUDE.md, AGENTS.md), and explaining caps and truncation behavior. This is exactly the kind of practical guidance an agent needs beyond property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: "Record a point-in-time inventory of the user's project under a workspace." It clearly distinguishes this tool from sibling snapshot operations (list_snapshots, read_snapshot) by emphasizing the act of recording and persisting new evidence, not retrieving it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage context: the agent is told it must gather the inventory with its own Read/Glob/Grep tools before calling, that workspace_id is required, and which fields are strongly recommended versus optional. It does not explicitly name alternatives or state when not to use the tool, but the preconditions and task framing make the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Pathrule tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation4/5

Tools are grouped by resource (memory/rule/skill/workspace/snapshot/refresh) and mostly have distinct output shapes, so agents can usually pick the right one. A few retrieval tools (get_context, get_node, get_tree, goto) overlap in purpose, but their descriptions clarify resolution mode vs full tree vs context bundle.

Naming Consistency3/5

All tools share the pathrule_ prefix and mostly follow verb_noun, but the verbs are inconsistent: create_workspace vs write_memory, get_node vs read_memory, delete_skill vs remove_pattern, plus verb-only exceptions like goto, setup, and ping. The pattern is readable but not uniform.

Tool Count2/5

32 tools is above the 25-tool threshold and feels heavy for a single server, even with a broad domain. Several context-retrieval tools and read/list variants could potentially be consolidated, though each tool does have a specific purpose.

Completeness4/5

Core CRUD is covered for memories, rules, and skills, along with workspaces, snapshots, refresh tasks, and pattern import/removal. Minor gaps include no standalone list_rules/list_skills and no snapshot update/delete, but agents can work around these via get_context, goto, and get_tree.

Resources

Need Help?