Pathrule

Pathrule Setup

pathrule_setup

Read-only

Fetch the active Pathrule bootstrap brief and execute it. Call this ONCE when the user asks to set up / bootstrap / initialize Pathrule for a project (e.g. 'Set up Pathrule for this project', 'Bootstrap Pathrule'). The response body is a prompt you must follow immediately — it tells you how to scan the project, propose memories/rules/skills, and write the approved items via pathrule_write_memory / _rule / _skill. Do NOT call this mid-task, for already-populated workspaces, or when the user just wants context — use pathrule_get_context for routine context lookups. If no workspace exists yet, call pathrule_list_organizations + pathrule_create_workspace first.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`locale`	No	Bootstrap brief language code. Defaults to 'en'. Pass 'tr' for Turkish users.
`workspace_id`	No	Target workspace. Omit only if the user has not picked one yet — you should then call pathrule_create_workspace before continuing the bootstrap.

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	The bootstrap brief.
`error`	No	Present only when ok is false.
`human_message`	No	One-line summary of the result, safe to relay to the user verbatim.
`local_runtime`	No	Present on tools that carry the local-runtime upgrade reminder.

Schema Changelog

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

Changed1 schema field changedSep 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "The bootstrap brief.",
+      "properties": {
+        "body": {
+          "description": "The bootstrap brief to execute, step by step.",
+          "type": "string"
+        },
+        "bootstrap_v2": {
+          "anyOf": [
+            {},
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Reserved for the next bootstrap format. Currently null."
+        },
+        "locale": {
+          "description": "Locale the brief was served in.",
+          "type": "string"
+        },
+        "source": {
+          "description": "Where the brief came from: cloud for the requested locale, fallback for the English default.",
+          "type": "string"
+        },
+        "version": {
+          "description": "Bootstrap prompt version.",
+          "type": "string"
+        },
+        "workspace_id": {
+          "description": "Workspace the brief was scoped to, or null when called before a workspace exists.",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "version",
+        "locale",
+        "body",
+        "source",
+        "workspace_id"
+      ],
+      "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"
+    },
+    "local_runtime": {
+      "additionalProperties": true,
+      "description": "Present on tools that carry the local-runtime upgrade reminder.",
+      "properties": {
+        "cta": {
+          "description": "Upgrade line to surface to the user when local Pathrule (Studio or CLI) would serve them better than Remote MCP.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "cta"
+      ],
+      "type": "object"
+    },
+    "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.7/5.0

Behavior5/5

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

The readOnlyHint annotation already signals a safe read operation, and the description adds crucial behavioral context: the response body is not just data but a prompt the agent must follow immediately, and the actual writes happen via sibling tools. This aligns with readOnlyHint and gives the agent an accurate mental model of the tool's side-effect-free role.

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: trigger, behavior, response handling, exclusions, alternative, and prerequisite. Critical information is front-loaded, and no word is wasted.

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 tool with orchestration complexity, the description covers the full lifecycle: when to invoke, what the response means, what to do next, when not to use, and how to handle missing workspaces. An output schema is present, so return-value documentation is already handled elsewhere. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the workspace_id guidance from the schema ('if no workspace exists yet...') but does not add parameter meaning beyond what the schema already provides. It is adequate but not additive.

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 names a specific action ('Fetch the active Pathrule bootstrap brief and execute it') and the exact resource. It clearly distinguishes this from the sibling tool pathrule_get_context by stating the latter is for routine context lookups, so an agent can tell them apart.

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

Usage Guidelines5/5

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

It explicitly states when to call ('ONCE when the user asks to set up / bootstrap / initialize Pathrule'), when not to call (mid-task, already-populated workspaces, routine context), names the alternative (pathrule_get_context), and provides prerequisite steps (pathrule_list_organizations + pathrule_create_workspace) when no workspace exists.

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?