Pathrule

Log Activity

pathrule_log_activity

Log a file-modifying response from a remote MCP client. Remote MCP requires workspace_id and stamps ai_client='cloud-connector'. task_summary should be ONE concise sentence (ideally ≤300 chars); it is NEVER rejected for length (past ~500 chars it is stored auto-shortened, not an error — do not retry).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	Yes	How far the change reached, from a single file up to the whole workspace.
`action`	Yes	What was done in this response.
`domain`	Yes	Area of the product the work belongs to.
`verbose`	No	Return the full stored activity row instead of the compact acknowledgement. Defaults to false.
`subjects`	No	Up to 5 short keywords naming what was touched, for example ["oauth", "token-refresh"].
`node_path`	No	Workspace-relative path the work happened at, for example /packages/app. Use the most specific path the change actually touched. Defaults to the workspace root.	/
`task_summary`	Yes	One concise sentence describing what this response actually changed. Never rejected for length: past the hard maximum it is stored auto-shortened, so do not retry a shorter version.
`workspace_id`	Yes	Workspace UUID from pathrule_list_workspaces.
`files_touched`	No	Which files changed. Tolerant by contract: a malformed value is dropped rather than rejected, so logging never fails on it.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	UUID of the stored activity row. Compact form only.
`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.
`error`	No	Present only when ok is false.
`activity`	No	The full stored activity row. Present only with verbose=true.
`created_at`	No	Insertion timestamp in ISO 8601. Compact form only.
`human_message`	No	One-line summary of the result, safe to relay to the user verbatim.
`task_summary_chars`	No	Length of the task_summary that was stored.
`summary_over_target`	No	True when task_summary exceeded the soft target. The row was still written, so do not retry.
`task_summary_target_chars`	No	Soft target length for task_summary.
`task_summary_hard_max_chars`	No	Length past which task_summary is stored auto-shortened. Never an error.

Schema Changelog

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

Changed11 schema fields changedSep 5, 2026

addedInput schema / properties / action / description
```
Added value: +"What was done in this response."
```

addedInput schema / properties / domain / description

Added value: +"Area of the product the work belongs to."

addedInput schema / properties / files_touched / description

Added value: +"Which files changed. Tolerant by contract: a malformed value is dropped rather than rejected, so logging never fails on it."

addedInput schema / properties / files_touched / properties / by_area / description

Added value: +"Workspace-relative file paths grouped by area, for example { \"packages/app\": [\"src/main.ts\"] }. The server normalizes and clamps these."

addedInput schema / properties / files_touched / properties / total / description
```
Added value: +"Number of files modified in this response."
```

addedInput schema / properties / node_path / description

Added value: +"Workspace-relative path the work happened at, for example /packages/app. Use the most specific path the change actually touched. Defaults to the workspace root."

addedInput schema / properties / scope / description

Added value: +"How far the change reached, from a single file up to the whole workspace."

addedInput schema / properties / subjects / description

Added value: +"Up to 5 short keywords naming what was touched, for example [\"oauth\", \"token-refresh\"]."

addedInput schema / properties / task_summary / description

Added value: +"One concise sentence describing what this response actually changed. Never rejected for length: past the hard maximum it is stored auto-shortened, so do not retry a shorter version."

addedInput schema / properties / verbose / description

Added value: +"Return the full stored activity row instead of the compact acknowledgement. Defaults to false."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "activity": {
+      "description": "The full stored activity row. Present only with verbose=true."
+    },
+    "created_at": {
+      "description": "Insertion timestamp in ISO 8601. Compact form only.",
+      "type": "string"
+    },
+    "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"
+    },
+    "id": {
+      "description": "UUID of the stored activity row. Compact form only.",
+      "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"
+    },
+    "summary_over_target": {
+      "description": "True when task_summary exceeded the soft target. The row was still written, so do not retry.",
+      "type": "boolean"
+    },
+    "task_summary_chars": {
+      "description": "Length of the task_summary that was stored.",
+      "type": "number"
+    },
+    "task_summary_hard_max_chars": {
+      "description": "Length past which task_summary is stored auto-shortened. Never an error.",
+      "type": "number"
+    },
+    "task_summary_target_chars": {
+      "description": "Soft target length for task_summary.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedAug 11, 2026

removedInput schema / properties / files_touched / required
```
Removed value: -[
-  "total",
-  "by_area"
-]
```

changedInput schema / required

Previous value: -[
-  "workspace_id",
-  "domain",
-  "action",
-  "scope",
-  "task_summary",
-  "files_touched"
-]New value: +[
+  "workspace_id",
+  "domain",
+  "action",
+  "scope",
+  "task_summary"
+]

Changed2 schema fields changedJun 21, 2026
- removedInput schema / properties / subjects / maxItems
```
Removed value: -5
```
- removedInput schema / properties / task_summary / maxLength
```
Removed value: -500
```
First observedMay 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only state readOnly=false, not idempotent, and not destructive. The description adds valuable non-obvious behavior: task_summary is never rejected for length, is auto-shortened past ~500 chars, and should not be retried. It also reveals the remote-client stamping behavior, which meaningfully affects how the agent should expect the call to behave.

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 two sentences with no wasted words. It front-loads the core action, then adds the most important operational constraint, then the key edge-case behavior. Every sentence earns its place.

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?

Given the 100% schema coverage, output schema, and annotations, the description supplies exactly the non-obvious context an agent needs: the remote MCP requirement, workspace_id necessity, and the length/no-retry behavior for task_summary. Nothing essential is missing for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by adding operational meaning for task_summary (concise one-sentence guidance, auto-shortening, no-retry rule) and workspace_id (required for remote MCP). This is useful extra semantic context beyond the structured field 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 states a specific verb and resource: log a file-modifying response from a remote MCP client. It clearly differentiates this from the memory/rule/skill/snapshot siblings, and no other sibling provides activity logging.

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 clearly indicates when to use this tool: after a file-modifying response, specifically from a remote MCP client, and it highlights the required workspace_id. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for the agent to pick it correctly.

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?