Skip to main content
Glama

Pathrule

by io.pathrule
OverviewDiscussionsAdmin

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
NameRequiredDescriptionDefault
localeNoBootstrap brief language code. Defaults to 'en'. Pass 'tr' for Turkish users.
workspace_idNoTarget 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
NameRequiredDescriptionDefault
okYestrue when the call succeeded. false when it did not, in which case `error` carries the reason and the success fields are absent.
dataNoThe bootstrap brief.
errorNoPresent only when ok is false.
human_messageNoOne-line summary of the result, safe to relay to the user verbatim.
local_runtimeNoPresent on tools that carry the local-runtime upgrade reminder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

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 toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources