Pathrule

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

Annotations already mark readOnly=false, but the description adds valuable behavioral context: it writes through the user's JWT with RLS enforcement, and it discloses side effects and non-effects (not attaching to local folder, not rendering files). This goes beyond annotations without contradicting them.

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

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

The description is three sentences, front-loaded with the main action, followed by key exclusions and a follow-up step. No fluff or redundancy; every sentence earns its place.

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

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

Despite lacking an output schema, the description states that the tool returns a workspace_id, which is the critical output. It covers purpose, exclusions, authentication, and next steps, making the tool fully understandable in context.

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

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

Schema coverage is 100% with each parameter described, so the baseline is 3. The description mentions 'returned workspace_id' but does not add extra meaning to the parameters themselves; it relies on the schema for parameter details.

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

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

The description begins with 'Create a new Pathrule workspace inside an organization,' using a specific verb and resource. It distinguishes itself from siblings by clarifying cloud-only scope and explicitly stating what it does NOT do (attach to local folder, install AI client config, render companion files). This is a clear, unambiguous purpose.

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

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

The description provides explicit when-to-use context: 'Cloud-only' and the JWT/RLS note indicate it is the cloud creation path. It explains exclusions—'Does NOT attach... does NOT install... does NOT render'—and directs the next step: 'call pathrule_setup with the returned workspace_id.' This effectively differentiates from alternatives like pathrule_setup and Studio/CLI.

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

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

The description adds significant behavioral details beyond what annotations provide: the default soft-delete semantics, the workspace_admin requirement for permanent deletion, and the cloud-only restriction. This clarifies the nature and impact of the destructive operation. No contradiction with annotations.

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

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

Three short sentences (19 words) that are front-loaded with the key behavior. Every sentence adds necessary value: soft-delete default, hard-delete option with admin requirement, and cloud-only constraint. No redundancy.

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

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

The description covers the two deletion modes, admin rights, and deployment scope, which is sufficient for understanding this destructive tool. It does not discuss expected_version_id or return values, but those are already covered by the schema, so the description is adequately complete.

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

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

Schema description coverage is 100%, with each parameter already described. The description's mention of hard:true only reinforces the schema's own description, and 'Cloud-only' does not add parameter-specific meaning. Thus it does not surpass the schema baseline.

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

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

The description clearly states the tool deletes a memory, distinguishes it from sibling delete tools (delete_rule, delete_skill) by specifying 'memory'. It also clarifies the default soft-delete behavior and the hard-delete option, making the purpose precise.

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

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

The description provides clear context on how to use the tool, explaining the soft vs hard modes and the admin requirement for hard delete. However, it does not explicitly mention when to use this tool over alternatives (e.g., update_memory for edits, delete_rule for rules), so it lacks explicit exclusion/alternative guidance.

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

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

While annotations already mark destructiveHint=true, the description adds that deletion is soft by default and that hard:true is a permanent, permission-gated action. The cloud-only restriction further clarifies where the operation is valid. This goes beyond the structured annotation by describing the two delete modes and an authorization prerequisite.

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

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

The description is three short clauses, each conveying a distinct piece of information: the default behavior, the hard-delete requirement, and the cloud-only constraint. It is front-loaded with the primary action and contains no redundant phrasing.

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

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

For a mutating delete tool, the description covers the core behavior, the permanent vs. soft distinction, an admin requirement, and a platform limitation. Combined with the complete parameter descriptions in the schema, this is adequate. It does not mention the expected_version_id concurrency token or return values, but the schema describes the token and no output schema is defined, so the omission is acceptable.

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

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

Schema coverage is 100% for all parameters, so the baseline is 3. The description adds semantic value for the 'hard' parameter by linking it to the default soft behavior and the workspace_admin permission, which is not fully captured in the schema description. Other parameters are well-covered by the schema, so this addition raises the score.

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

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

The description clearly states the tool deletes a rule, specifies the default mode as 'soft-delete', and mentions the hard-delete alternative with a permission requirement. It explicitly names the target resource ('rule'), distinguishing it from sibling delete tools for memories and skills.

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

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

The description provides clear context on usage: soft-delete by default, hard delete requires workspace_admin, and it is cloud-only. It does not explicitly name alternative tools (e.g., update_rule for reversible changes) or state when-not-to-use, but the mode guidance is sufficient for a straightforward delete operation.

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

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

Annotations already indicate destructiveness, but the description adds valuable nuance: the default is a non-destructive soft delete, while hard:true makes it permanent and requires admin privileges. This goes beyond the annotation's binary destructiveHint.

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

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

One sentence, no filler. Front-loads the key behavior (soft delete), followed by the critical exception (hard delete) and environment restriction. Every word earns its place.

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

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

For a delete operation, the description covers the main behavioral nuance (soft vs hard), the permission requirement, and deployment scope. There's no output schema, but return format is less critical for a delete. The expected_version_id param is already explained in the schema.

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

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

Schema coverage is 100%, with each parameter fully described (e.g., hard, expected_version_id). The description does not repeat parameter details, and the baseline of 3 applies since the schema carries the semantic weight.

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

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

The description states a specific verb and resource: 'Soft-delete a skill by default.' It clearly distinguishes this from sibling delete tools (delete_memory, delete_rule) by targeting 'skill.' The mention of hard delete adds precision.

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

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

Provides clear context: soft-delete is the default, hard delete requires workspace_admin, and the tool is Cloud-only. It doesn't explicitly name alternatives or say when not to use, but the constraints effectively guide usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that no cwd or local_root_path is used and instructs to surface the `local_runtime.cta` line when relevant, providing behavioral and output-handling context beyond annotations.

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

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

Three focused sentences: purpose, prerequisite/usage, and output handling. No filler.

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

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

Given no output schema, the description lists the response components (memories, rules, skills, subtree index, next_required_action hint) and the special local_runtime.cta line, enough for an agent to know what it returns. It lacks error behavior details but covers the key information.

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

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

Schema covers all four parameters with descriptions (100%). The description adds context that workspace_id is required for remote clients and that node_path is workspace-relative (no local cwd), which supplements the schema's parameter descriptions.

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

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

The description uses a specific verb 'Return' and names the resource 'Pathrule context for a workspace path', listing the contained elements (memories, rules, skills, subtree index, next_required_action hint). This clearly differentiates it from siblings like pathrule_get_node and pathrule_get_tree.

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

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

The description states 'Remote clients must pass workspace_id; call pathrule_list_workspaces first when unsure' and clarifies that no cwd or local_root_path is used, giving clear context for when and how to invoke it. However, it does not explicitly list alternative tools for narrower queries.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: the tool explains a pitch, splits by audience (CLI vs GUI), and covers the token-savings angle of hooks versus manual MCP. This goes beyond the annotations by describing the content and purpose of the response, helping the agent set expectations.

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

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

The description is two sentences, tightly written, and front-loaded with the action. The first sentence states what the tool does; the second gives usage triggers and content specifics. Every phrase earns its place, with no fluff or repetition.

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

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

Given that the tool has no parameters, no output schema, and read-only annotations, the description is fully complete. It explains the tool's purpose, when to use it, what the response covers (audiences, token-savings angle), and how it relates to Remote MCP. There is no missing information for an agent to invoke and understand the tool correctly.

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

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

There are zero parameters, so the schema is trivially 100% covered. The description does not need to explain any parameters, and the baseline for zero-parameter tools is 4. It correctly omits parameter details, as none exist.

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

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

The description clearly states the tool's function: 'Explain what Pathrule CLI and Pathrule Studio unlock beyond Remote MCP.' It uses a specific verb ('explain') and resource ('Pathrule CLI/Studio'), and distinguishes it from sibling tools which are CRUD operations for paths, memories, and rules. The description also specifies target audiences and key concepts, making the purpose unmistakable.

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

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

The description provides explicit usage triggers: 'Call this when the user asks "is there a better way?", "why do I need to install something?", wants hook-level automation, or wants to compare surfaces.' This clearly tells an agent when to invoke this tool versus alternatives, and the 'beyond Remote MCP' context frames the comparison.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds context by specifying the workspace_id requirement for cross-workspace ambiguity prevention and the inclusion of attached memory/rule/skill IDs. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the primary action and result, and includes a critical requirement without unnecessary verbosity. Every word earns its place.

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

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

For a simple 2-parameter read-only tool with annotations covering safety and a schema covering parameters, the description sufficiently describes the return value (node plus attached IDs) and the workspace requirement. No output schema exists, but the description clearly states what is returned.

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

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

The schema provides 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds semantic value by explaining why workspace_id is required (to prevent cross-workspace ambiguity), which is not present in the schema description.

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

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

The description clearly states the tool returns a single node plus IDs for attached memories, rules, and skills. It distinguishes itself from siblings like get_tree by specifying 'single node' and lists the exact components returned.

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

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

The description implies usage for retrieving one node's detail due to the 'single node' phrase, and it mentions requiring workspace_id to avoid ambiguity. However, it does not explicitly state when to use this over alternatives like get_tree or get_context, nor does it name exclusions.

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

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

The description says 'Claim one refresh task,' which implies a state change (the task is claimed), but the annotations set readOnlyHint to true, indicating no state modification. This is a direct contradiction. The description does not disclose any side effects such as marking the task as claimed, nor does it reconcile the read-only claim with the claim action.

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

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

Three sentences, each serving a distinct purpose: purpose, prerequisite, and environmental caution. No redundant language, information is front-loaded, and the text is well-structured.

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

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

The description lists what the tool returns (subject, stale-signal evidence, AI instructions, proposed patch), which is essential given no output schema. It also covers prerequisites and environment constraints. However, the lack of disclosure about side effects of claiming, especially given the annotation contradiction, leaves some incompleteness.

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

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

The schema fully describes the only parameter, refresh_id, as a UUID from pathrule_list_pending_refreshes (100% coverage). The description adds contextual usage advice but does not add new parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Claim one refresh task and return the subject, stale-signal evidence, AI instructions, and any proposed patch.' It clearly distinguishes this from sibling tools by requiring a prior call to pathrule_list_pending_refreshes and by focusing on returning the refresh brief.

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

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

The description explicitly instructs to call pathrule_list_pending_refreshes first to choose a refresh_id, and notes the environmental limitation that remote MCP can only inspect cloud records, advising use of Desktop/CLI for local source code verification. This provides clear context and prerequisites, though it does not explicitly mention when not to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds the 'full' scope of the returned tree, but does not disclose potential performance implications, return format, or error behavior. With annotations carrying the safety aspect, a 3 is appropriate; the description adds some value but lacks richer behavioral context.

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

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

The description is a single, front-loaded sentence that conveys purpose without any filler. Every word earns its place, and it is appropriately brief for a simple read-only operation.

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

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

For a tool with one required parameter and a read-only annotation, this description is largely complete. It tells the agent what the tool does and what input is needed. However, without an output schema, it would have been helpful to clarify the structure or contents of the 'node tree'; nevertheless, the simplicity of the operation and the annotations make it adequate.

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

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

Schema coverage is 100%, and the only parameter workspace_id already has a description in the schema ('Workspace UUID from pathrule_list_workspaces'). The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Return') and clearly identifies the resource ('full Pathrule node tree') and scope ('for a workspace'). This distinguishes it from siblings like get_node (presumably single node) and get_context by emphasizing 'full tree'.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention any preconditions (e.g., workspace must exist), nor does it contrast with get_node or other related tools. Usage context is only implied by the name and description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying the output (full node content and a compact subtree memory index). However, it does not disclose edge-case behavior such as ambiguous matches or resolution priority, so it only partially enhances transparency beyond annotations.

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

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

A single, well-structured sentence that front-loads the primary verb and describes both action and result with no extraneous detail.

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

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

The description adequately covers the tool's core behavior and return value despite lacking an output schema. It could be improved by clarifying how fuzzy resolution is disambiguated, but as is, it provides sufficient context for an agent to invoke the tool correctly.

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

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

The schema already documents 'target' and 'workspace_id' with descriptions; the tool description adds little beyond echoing the path/name/fuzzy semantics. The 'subtree_limit' parameter lacks a description in the schema, and the description does not compensate by explaining its purpose, so the description adds moderate value beyond schema.

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

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

The description uses a specific verb ('resolve') and specifies the resource (path/name/fuzzy target) and the return (full content plus subtree memory index), distinguishing it from sibling tools like pathrule_get_node and pathrule_get_tree.

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

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

The description implies the intended use case (resolving a target by path/name/fuzzy match) but does not explicitly mention when to use it over alternatives such as pathrule_get_node. No exclusions or alternative guidance are provided.

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

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

The description explicitly claims 'idempotent', but the annotations set idempotentHint to false. This is a direct contradiction between the description and the structured metadata. While the description otherwise adds useful behavioral detail (dry_run behavior, tagging, response contents), the contradiction forces a score of 1 per the scoring rules.

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

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

The description is long but appropriately structured with a numbered workflow. Every sentence carries meaningful information: the trigger, the steps, the undo reference, and the explicit non-skill warning. It is front-loaded with purpose and remains concise for the tool's complexity.

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

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

For a complex tool with 5 parameters and no output schema, the description is remarkably complete. It covers the full workflow, provides decision points (fit check), explains what the response includes (created ids, human_message), and clarifies re-rooting behavior. No critical gaps are apparent.

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

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

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds strategic semantics beyond the schema: it explains that dry_run should be used first to preview, and node_path should be chosen to re-root the pattern's paths. This operational guidance enriches the parameter understanding.

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

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

The description clearly states the tool's purpose: importing an official Pathrule pattern when a user pastes a `::pathrule:package:<slug>` token. It uses specific verbs (import, dry_run, write) and identifies the resource (pattern bundle). It also distinguishes from sibling tools like pathrule_remove_pattern and explicitly says it is not a skill import.

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

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

The description provides an explicit, sequential workflow: first dry_run, evaluate fit, choose node_path, then write. It also gives clear conditions for when to stop and ask the user (if the pattern does not fit), names an alternative for undo (pathrule_remove_pattern), and warns against running the find-skills protocol. This is strong when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns compact previews only, which is valuable behavioral context beyond the safety profile. No contradiction with annotations.

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

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

Two sentences, front-loaded with the main purpose, and every clause adds useful information. Zero wasted words.

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

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

For a simple single-parameter list tool with strong annotations, the description fully covers what it returns (previews), how to get more detail, and the prerequisite discovery step. No output schema needed to explain return values.

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

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

Schema coverage is 100% and the node_id parameter is already well-documented in the schema. The description repeats the origin of the node_id but adds no extra semantic detail beyond the schema, so baseline 3 is appropriate.

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

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

The description states 'List active memories attached to a specific Pathrule tree node', using a specific verb and resource. It clearly distinguishes from siblings like pathrule_read_memory (which reads full memories) and write operations.

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

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

Explicitly instructs to use pathrule_get_context, pathrule_goto, or pathrule_get_node first to discover the node_id, and directs users to pathrule_read_memory for full memory bodies. This provides clear when-to-use and alternative guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by disclosing that results are scoped to the authenticated user and listing the exact return fields (id, name, slug, plan, subscription_status, user role), which goes beyond 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.

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

The description is three sentences, each serving a distinct purpose: stating the action, providing usage context, and listing return fields. There is no redundant or filler content.

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

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

Given the simple nature of the tool (no parameters), the description is complete: it explains what it returns, the user scoping, and when to use it. No output schema exists, but the return fields are specified, covering any gaps.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the empty schema is trivially covered by the description's statement that it lists organizations for the authenticated user.

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

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

The description clearly states the tool lists organizations the authenticated user belongs to, with a specific verb and resource. It also distinguishes itself from the sibling tool pathrule_create_workspace by noting its use before creating a workspace.

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

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

The description explicitly says to use this before pathrule_create_workspace when needing to ask the user which organization to use, providing clear context and a named alternative. It does not explicitly mention when not to use it, but the guidance is concrete and helpful.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds context about refresh tasks being cloud suggestions, but does not disclose additional behaviors like response structure, pagination, or rate limits. Minimal extra value beyond annotations.

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

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

Three sentences with no filler: defines the action, clarifies the domain concept, and gives workflow direction. Each sentence earns its place and is front-loaded with the primary purpose.

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

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

For a list tool with no output schema, the description adequately explains what tasks are, the workspace scope, and the next step. It implicitly conveys that a refresh_id will be returned, but does not explicitly state the response format or pagination limits, slightly reducing completeness.

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

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

Schema coverage is 100% with both parameters (workspace_id, include_in_progress) described in the schema. The description only reinforces workspace scoping ('for a workspace') without adding new parameter-level meaning, so baseline 3 applies.

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

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

The description clearly states the tool 'List pending Pathrule refresh tasks for a workspace,' using a specific verb and resource. It distinguishes itself from sibling listing tools by explaining refresh tasks are cloud suggestions for stale memories/rules and referencing the follow-up workflow.

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

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

Explicitly says 'Use this first, then call pathrule_get_refresh_brief with a returned refresh_id before deciding whether to reject or resolve the task,' providing clear sequencing and the decision context. It implies this tool is the starting point for managing refresh tasks.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about return content ('compact metadata only — no file_tree, no sampled_contents') and pagination/ordering ('Up to 25 per call, ordered newest first'), going beyond 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.

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

Two sentences, front-loaded with the primary action and scope. Every clause adds value: the metadata-only clarification, the use case, and the limits/ordering. No redundant text.

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

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

Given no output schema, the description tells the agent what to expect (compact metadata, up to 25, newest first) and the tool's purpose. It doesn't enumerate exact return fields, but for a simple list tool with annotations present, this is reasonably complete. It could benefit from naming the snapshot fields (e.g., id, timestamp), but the current level suffices.

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

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

Schema description coverage is 67%, so not all parameters are described. The description adds context for workspace_id by mentioning 'for a workspace' but doesn't explain source or deepen limit semantics (schema already says 'Default 10, max 25'). The 'ordered newest first' note relates to output ordering, not parameter usage. This is adequate but not exceptional.

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

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

The description uses a specific verb+resource ('List the most recent project snapshots') and clearly scopes to 'for a workspace'. It also distinguishes from siblings by stating 'compact metadata only — no file_tree, no sampled_contents', which differentiates it from pathrule_read_snapshot.

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

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

The description explicitly states when to use the tool: 'Use to find which snapshot to read in full.' This implies the alternative is reading the full snapshot, though it doesn't name the sibling tool directly. No exclusions are provided, but the context is clear enough for agent selection.

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

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

Annotations already indicate a safe read-only operation. The description adds meaningful behavioral context beyond that: the listing is filtered by cloud RLS, it never exposes local filesystem paths, and the response includes a `local_runtime.cta` reminder. This gives the agent useful expectations about the output's content and inherent constraints.

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

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

The description is two sentences, front-loaded with the core purpose, and every clause adds value: RLS scope, remote-tool suitability, privacy guarantee, and the response reminder. No fluff or repetition.

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

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

For a zero-parameter list tool, the description covers the essential aspects: what it lists, under what visibility (RLS), what it returns (workspace ids), what it avoids (local paths), and a notable response element (CTA reminder). It lacks exact response formatting or pagination details, but with no output schema and a simple action, this is adequate.

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

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

There are zero parameters, so the schema carries no burden. The baseline for 0 params is 4, and the description adds no parameter-specific information (nor is any needed). It does not need to explain missing parameters, as there are none.

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

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

The description explicitly states the action ('List'), the resource ('Pathrule workspaces'), and the scope ('visible to the authenticated user through cloud RLS'). It distinguishes this tool from sibling list tools by focusing on workspaces rather than memories, rules, or snapshots, and clarifies it is for remote tools, not local paths.

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

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

The description provides clear context for when to use the tool: 'Returns workspace ids for remote tools' and 'never exposes local filesystem paths' imply it is for remote workspace listing, not local file operations. It gives a specific follow-up action ('mention Pathrule Studio/CLI when the user is doing local code work') but does not explicitly name alternative tools or state when not to use it.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral details: task_summary is never rejected for length, is auto-shortened past ~500 chars, and should not trigger a retry. It also discloses the ai_client='cloud-connector' stamp for remote MCP, going beyond the annotations to prevent futile retries.

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

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

The description is three sentences, front-loaded with the primary purpose, and includes the critical retry-avoidance guidance. It is concise without fluff, every sentence adds value.

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

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

With 9 parameters, a nested files_touched object, no output schema, and minimal annotations, the description covers only the task_summary length edge case and remote MCP context. It omits expected return values, behavior for unspecified parameters, and general usage scope, leaving substantial gaps for an agent to invoke correctly.

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

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

Schema description coverage is only 11%, with only workspace_id described in the schema. The description adds important context for workspace_id (required for remote MCP) and task_summary (length handling), but the other seven parameters (domain, action, scope, subjects, node_path, verbose, files_touched) receive no explanation beyond enums and types. This is insufficient compensation for a tool with nested objects.

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

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

The description clearly states the tool logs a file-modifying response from a remote MCP client, using a specific verb and resource. It distinguishes itself from sibling tools like pathrule_write_memory or pathrule_take_snapshot by focusing on activity logging, though the term 'file-modifying response' could be more explicit about the exact domain.

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

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

The description provides clear context for when to use this tool: it requires workspace_id and is meant for remote MCP clients, with the ai_client stamp behavior. It does not explicitly exclude local usage or name alternative tools, but the context is specific enough to guide an agent.

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

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

Descriptions adds value beyond annotations by disclosing cloud-safety (no local cwd) and the presence of a `local_runtime.cta` line in the response. Annotations already cover read-only/destructive hints, so this additional context is meaningful.

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

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

Two concise sentences: the first states the core purpose, the second adds safety and response detail. No unnecessary words or redundancy.

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

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

The tool is simple (no required parameters, no output schema). The description covers purpose, safety, and a key response element, making it contextually complete for an agent.

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

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

The single optional parameter 'message' is fully documented in the schema (100% coverage: 'Optional message to echo back'). The description adds no extra parameter semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('sanity check that Pathrule Remote MCP is reachable'), clearly distinguishing this connectivity check from the sibling tools, which all perform create, read, delete, or update operations.

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

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

The description implies usage for verifying connectivity with 'Sanity check' and adds safety context via 'Cloud-safe: returns no local cwd.' It does not explicitly name alternatives or when-not-to-use, but for a simple ping tool this is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the data source (cloud only, no local filesystem inspection) and what is returned ('full body and metadata'). This is useful beyond the structured annotations.

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

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

Two tight sentences, front-loaded with the core purpose. Every sentence adds value: one explains what it does, the other clarifies when to use it and what it does not do. No wasted words.

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

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

For a simple single-parameter read tool with no output schema, this description is complete. It covers the resource type, trigger condition, return content, and a key limitation. The annotations cover safety, so nothing crucial is missing.

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

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

The only parameter, memory_id, has 100% schema description coverage explaining its origin. The tool description doesn't add additional parameter details, so the score stays at the baseline of 3.

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

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

The description clearly states 'Read the full body and metadata for one Pathrule memory' – a specific verb, resource, and scope. It distinguishes from sibling tools like pathrule_read_rule and pathrule_read_skill by targeting Pathrule memories specifically.

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

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

Provides explicit usage context: 'Use this after pathrule_get_context, pathrule_goto, or pathrule_list_memories returns a memory_id.' It also explains a limitation ('reads cloud data only and does not inspect the user's local filesystem'), which serves as a when-not-to-use. It doesn't name alternative tools directly, so I deduct one point.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is already known. The description adds useful context by noting it reads the 'cloud rule record' and explains what a rule is, but this does not significantly expand behavioral disclosure beyond the annotations. No contradiction exists.

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

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

The description is three sentences, front-loaded with the core action, followed by when-to-use context and a brief domain explanation. Every sentence adds value, with no fluff or repetition.

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

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

Given the tool's simplicity (one parameter, no output schema, clear annotations), the description satisfactorily covers what it reads, when to use it, and that it is read-only. It does not detail return format or error conditions, but those are less critical for a straightforward read operation.

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

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

The input schema has 100% parameter coverage, describing rule_id as a UUID returned by specific tools. The description repeats this same information in the usage note, adding no extra semantic detail beyond what the schema already provides.

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

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

The description clearly states 'Read the full body and metadata for one Pathrule rule,' using a specific verb and resource. It distinguishes from siblings like pathrule_write_rule and pathrule_delete_rule by explicitly noting it does not modify anything, and from read_skill/read_memory/read_snapshot by specifying the target as a rule.

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

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

The description gives explicit when-to-use guidance: 'Use this after pathrule_get_context, pathrule_goto, or pathrule_get_node returns a rule_id.' It does not explicitly name alternatives or when-not-to-use scenarios, but the read-only note implies it is not for modification, making the usage context reasonably clear.

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

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

While annotations already indicate readOnlyHint=true and destructiveHint=false, the description adds value by explaining that it returns cloud SKILL.md content and does not install files locally. This is useful behavioral context beyond the annotations, though it doesn't cover error conditions or permission requirements.

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

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

The description is two sentences, front-loaded with purpose and followed by usage and behavioral caveats. Every clause earns its place with no redundancy or filler.

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

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

For a simple read tool with one well-documented parameter and clear annotations, the description covers the purpose, trigger conditions, and a key behavioral nuance (not installing files). It is complete enough for an agent to select and invoke this tool correctly.

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

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

The single parameter skill_id is fully described in the input schema with 100% coverage, and the description repeats the same source (returned by pathrule_get_context, pathrule_goto, or pathrule_get_node). This reinforces but does not add new semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Read') and the subject ('the approved snapshot for one Pathrule skill'), which is specific and distinct from sibling read tools like pathrule_read_memory or pathrule_read_rule. It also explicitly names the skill resource, leaving no ambiguity.

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

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

Provides explicit usage guidance: 'Use this after pathrule_get_context, pathrule_goto, or pathrule_get_node returns a skill_id.' It also clarifies what the tool does not do ('does not install or materialize files locally'), helping the agent avoid misuse.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description focuses on additional behavior: defaults include file_tree and sampled_contents, and how to disable them for a compact response. This adds useful context beyond the annotations without contradiction.

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

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

A single, efficient sentence that front-loads the purpose and then provides actionable parameter guidance. No filler or redundant information.

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

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

Given no output schema, the description partially covers return behavior by naming the default components (file_tree, sampled_contents) and mentioning 'metadata'. It does not fully specify the response structure, but for a read operation with clear settings, it is adequately complete.

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

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

Schema has no parameter descriptions, but the description explains the two boolean parameters (include_file_tree, include_sampled_contents) and their defaults. It does not explain workspace_id and snapshot_id, but these are self-evident from naming conventions and context.

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

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

The description clearly identifies the action ('Load') and the specific resource ('a single project snapshot'), and notes it can be 'full or partial form'. This distinguishes it from sibling tools like pathrule_list_snapshots (listing) and pathrule_take_snapshot (creating).

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

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

It provides clear context for when to use the tool (to load a snapshot) and gives guidance on using flags to request compact responses when only metadata is needed. However, it does not explicitly mention alternatives or when not to use this tool, so it misses the top tier.

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

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

Annotation Contradiction: The description claims the tool is idempotent and deletes memories/rules/skills, but annotations set idempotentHint=false and destructiveHint=false. These direct contradictions make the behavioral disclosure unreliable, so the description fails to provide transparent information beyond the contradictory annotations.

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

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

The description is three concise sentences that front-load the core purpose and then add essential operational details about node_path, idempotency, and output handling. Every sentence earns its place with no redundancy or filler.

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

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

For a destructive removal tool with no output schema, the description covers the deletion mechanism, idempotency behavior, and instructs to relay the human_message. It lacks explicit return format details, but the instruction mitigates this. Overall it is quite complete, though the annotation contradiction undermines the full contextual picture.

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

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

Schema coverage is 100%, so all parameters are already documented. The description adds value by clarifying that node_path must match the import base and may be omitted when pattern-own paths were used, which is not explicitly covered in the schema. This is a useful enhancement over the baseline.

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

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

The description clearly states the tool removes a previously-imported Pathrule pattern bundle, using the verb 'remove' and identifying the resource as a pattern bundle. It explicitly positions itself as the reverse of pathrule_import_pattern, making its purpose specific and distinguishable from sibling tools.

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

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

The description provides clear usage context by naming pathrule_import_pattern as the counterpart and instructing the agent to pass the same node_path base used at import. It implies the advantage of batch removal over individual deletes but does not explicitly enumerate alternatives such as pathrule_delete_memory/rule/skill.

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

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

Annotations already declare destructiveHint=true, and the description adds context by explaining that remote MCP may refuse status='applied' because it cannot verify local source files. It also discloses that 'rejected' is for stale or non-actionable signals. This extra context about refusal and local verification exceeds the annotation baseline without contradicting it.

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

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

The description is two sentences, front-loaded with the primary action and then giving essential flow and caveats. Every clause adds value—no redundant or vague wording. It is highly efficient for an AI agent to parse.

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

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

Given no output schema and moderate complexity, the description sufficiently covers the essential context: the sequence of calls, the status choices, and the local/remote verification caveat. It does not explain return values, but for a close/resolution operation this is not critical. The description is complete enough for correct tool selection and invocation.

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

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

Schema description coverage is 100% and each parameter already has a thorough description, including status enum semantics and refresh_id sourcing. The description repeats the status guidance found in the schema, so it adds no new parameter-level meaning. It provides flow guidance, but that is already covered under usage guidelines.

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

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

Description clearly states the tool's function: 'Close a Pathrule refresh task after reviewing its brief.' This distinguishes it from sibling tools like pathrule_list_pending_refreshes and pathrule_get_refresh_brief, defining it as the terminal action in the refresh workflow. The verb 'close' and resource 'refresh task' are specific and unambiguous.

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

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

Explicitly describes the normal remote flow: 'call pathrule_list_pending_refreshes, then pathrule_get_refresh_brief, then use this tool with status='rejected' when the signal is stale or not actionable.' It also provides an exclusion: when 'applied' is needed, remote MCP may refuse and Pathrule Studio/CLI should be used instead. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, which sets expectations for safety. The description adds meaningful behavioral context: the response body is a prompt that must be followed immediately, and it describes the downstream actions (scanning, proposing, writing via other tools). This goes beyond the annotations and explains the tool's execution flow, though it doesn't detail every possible behavior. No contradiction with annotations.

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

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

The description is well-structured with a clear opening action, followed by usage scenarios, exclusions, and prerequisites. While longer than typical, every sentence carries valuable information—the when-to-use, when-not-to-use, alternative tool, response handling, and workspace prerequisite. The content is front-loaded and no words are wasted, making the length justified.

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

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

For a setup tool with no output schema, the description is remarkably complete. It explains the tool's purpose, the bootstrap trigger, the response handling (the body is a prompt to follow), the exact actions to take after the response (write via specific tools), and what to do if no workspace exists. It also provides clear exclusion criteria. Given the tool's complexity and lack of output schema, the description fully equips an agent to use it correctly.

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

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

The input schema covers both parameters fully with descriptions (locale and workspace_id), including locale defaults and the workspace_id omission condition. The description adds minimal extra meaning—'Pass tr for Turkish users' is already in the schema, and the workspace_id condition is also stated in the schema. Since schema coverage is 100%, the baseline of 3 applies; the description does not significantly enrich parameter understanding beyond the schema.

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

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

The description clearly states the primary function: 'Fetch the active Pathrule bootstrap brief and execute it.' It identifies the specific resource (bootstrap brief) and action (fetch and execute), and distinguishes it from sibling tools like pathrule_get_context, which is for routine context lookups. This is a specific verb+resource definition with clear differentiation.

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

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

The description provides explicit usage guidance: 'Call this ONCE when the user asks to set up / bootstrap / initialize Pathrule' and includes direct exclusions: '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.' It also specifies prerequisites for missing workspace, naming pathrule_list_organizations and pathrule_create_workspace. This is a model of when-to-use and when-not-to-use instructions.

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

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

Annotations already indicate this is not read-only (readOnlyHint=false), so the description need not restate that. It adds valuable context about the remote MCP filesystem limitation and the AI's responsibility to gather data. However, it does not disclose potential side effects such as whether repeated calls overwrite prior snapshots or create duplicates, nor does it mention error conditions. No contradiction with annotations.

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

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

The description is a single dense paragraph that front-loads the purpose, then explains the workflow, then lists parameter priorities. Every sentence carries useful information without fluff or repetition of schema details.

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

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

For a tool with 16 parameters and nested objects, the description is highly complete: it explains the preconditions, parameter priorities, size caps, and intended use cases. Since there is no output schema, it could briefly mention what the tool returns (e.g., snapshot ID), but this is a minor gap given the richness of the rest.

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

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

Schema description coverage is 56%, and the description compensates well by specifying which parameters are required, strongly recommended, and optional, along with concrete guidance (e.g., cap file_tree at ~5000 entries, truncate sampled_contents to ~4KB, focus on README and manifest files). This adds meaning beyond the raw schema.

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

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

The description clearly states the tool's function: "Record a point-in-time inventory of the user's project under a workspace." This is a specific verb+resource combination that unambiguously distinguishes it from sibling tools like pathrule_list_snapshots or pathrule_read_snapshot.

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

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

The description gives explicit context on when to use this tool, emphasizing that the AI must first collect the inventory using Read/Glob/Grep because remote MCP cannot see the filesystem. It also mentions downstream use cases (setup, bootstrap, drift detection, onboarding). However, it does not explicitly name alternatives or when-not-to-use conditions, though this is a write counterpart to read/list snapshots.

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

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

Annotations already mark destructiveHint=true, and description adds useful context: optimistic concurrency via expected_version_id and cloud-only limitation. However, it does not disclose that omitting expected_version_id may overwrite newer edits, nor side effects like moving paths clearing links, which would be valuable beyond annotations.

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

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

Two sentences, front-loaded with purpose, followed by key behavioral caveat. No filler or redundant restating of the title.

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

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

Adequate for an 8-parameter tool with fully described schema and annotations, but missing usage alternatives and behavior on conflict when expected_version_id is omitted. Given no output schema, the description could mention success/failure semantics.

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

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

Schema coverage is 100%, so description adds little beyond what parameter descriptions already provide. It references expected_version_id and the option to move, but does not enrich parameter meaning beyond the schema's own explanations.

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

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

The description states a specific verb ('Update') and resource ('a memory'), with clear scope: 'content or title, optionally moving it.' This distinguishes it from sibling update tools for rules/skills and from creation tools like write_memory, even if not explicitly naming alternatives.

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

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

No explicit guidance on when to use this tool versus alternatives such as pathrule_write_memory or pathrule_delete_memory. The description implies updating an existing memory but does not state prerequisites, exclusions, or recommended scenarios.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate those. It adds valuable behavioral context about optimistic concurrency via expected_version_id and the cloud-only restriction, which helps the agent understand update semantics and avoid overwriting newer edits.

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

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

The description is extremely concise: one sentence plus two short fragments. Every word adds value, and the primary action is front-loaded. No redundant information or filler.

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

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

For a moderate-complexity update tool with no output schema, the description covers the core action (fields and/or path), concurrency behavior, and environment constraint (cloud-only). It doesn't mention return values or prerequisites, but these are not critical given the rich input schema and annotations.

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

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

Schema coverage is high (83%), so parameters are already well described. The description adds little beyond the schema except emphasizing 'optimistic concurrency via expected_version_id,' which is already covered in the parameter description. It meets the baseline but doesn't significantly enhance parameter understanding.

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

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

The description uses a specific verb 'Update' with a clear resource 'a rule's fields and/or path,' distinguishing it from sibling tools like delete_rule or list_workspaces. It also highlights unique features (optimistic concurrency, cloud-only) that set it apart from related update tools.

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

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

The description implies when to use the tool (updating an existing rule's fields or path) and gives the constraint 'Cloud-only,' but it does not explicitly state when not to use it or mention alternative tools like write_rule. The usage context is clear but lacks explicit exclusion/alternative guidance.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description details side effects: writes the cloud skill record, may replace fields present in patch, may move the skill, may fail on version conflict, and explicitly states what it does NOT do (never installs files into .codex/skills, .claude/skills, or editor folders). This is rich behavioral disclosure that goes well beyond structured metadata.

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

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

Although the description is several sentences long, it is well-structured and front-loaded with the core purpose. Every sentence adds value: usage conditions, alternatives, prerequisites, side effects, and exclusions. No fluff or redundancy.

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

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

The description covers purpose, when to use, alternatives, prerequisites, detailed side effects, and what it does not do. Given the tool's complexity (nested patch object, optional move_to_path, version conflict handling) and the lack of an output schema, this description is fully sufficient for an agent to select and invoke the tool correctly.

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

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 that it is a partial update and mentions move_to_path and version conflict side effects, but these are already explained in the schema properties. It does not add significant parameter-level meaning beyond what the schema provides.

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

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

The description clearly states 'Partially update an existing Pathrule skill record' with a specific verb and resource, and enumerates exactly what can be changed (metadata, SKILL.md content, source/github_url, tags, workspace path). It also distinguishes itself from sibling tools by explicitly naming pathrule_write_skill, pathrule_read_skill, and pathrule_delete_skill as alternatives.

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

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

Provides explicit usage guidance: 'Use pathrule_update_skill only when you already have a skill_id and want to change...' and names alternatives for create, read, and delete operations. It also specifies prerequisites (authenticated connector token with pathrule:write, active workspace subscription), giving clear context for when this tool is appropriate.

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

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

Beyond the annotations, the description discloses the auto-creation of missing nodes, the duplicate-title block (unless allow_duplicate), and the cloud-only constraint. This provides meaningful behavioral context for a write operation that annotations alone don't convey.

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

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

Three dense sentences front-load the core action, then add key behaviors and a pointer to companion tooling. No redundant words; each sentence earns its place.

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

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

For a write tool, the description covers creation semantics, duplicate handling, cloud-only scope, and an optional path to deeper integration. Minor gaps remain around return value and error cases, but the tool is easy to select and invoke.

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

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

With only 43% schema coverage, the description compensates by explaining allow_duplicate's role and node_path's workspace-relative nature. However, it leaves source and related_paths meaning to schema defaults, and title/content length limits are not mentioned.

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

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

The description uses the exact verb 'Create' and clearly identifies the resource as a new memory at a workspace path. It also notes auto-creation of missing nodes and duplicate-title blocking, distinguishing it from update_memory and other write tools.

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

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

The description provides context that this is cloud-only and won't touch a local filesystem, which helps in selecting it over local alternatives. It also points to Studio/CLI for automatic CLAUDE.md sync, though it doesn't explicitly contrast with update_memory or write_rule.

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

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

The description discloses critical behavioral traits beyond the sparse annotations: 'Missing nodes auto-create' and 'Cloud-only — Pathrule Studio/CLI also renders the rule into the user's CLAUDE.md/AGENTS.md and editor companion files automatically.' These side effects are non-obvious and important for the agent to know. The annotations (readOnlyHint=false) are consistent with a create operation, so no contradiction.

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

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

The description is three sentences, front-loaded with the main purpose, then adding critical behavior and usage advice. Each sentence provides distinct information with no redundancy, making it highly efficient.

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

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

For a create tool with 7 parameters and no output schema, the description covers the primary purpose, key side effects (auto-creating nodes and rendering to CLAUDE.md), and parameter usage guidance. It lacks explicit mention of return value or error handling, but given the rich schema and behavioral disclosures, it is largely complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with descriptions for all 7 parameters, providing a strong baseline. The description adds value by giving ethical guidance on scope_type and priority, explaining when 'high' is appropriate, which enriches the enum semantics beyond the schema's simple definitions.

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

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

The description clearly states 'Create a new rule at a workspace path' with a specific verb and resource. It distinguishes from siblings like update_rule and delete_rule by the word 'new' and creation semantics. The added 'Missing nodes auto-create' further clarifies the tool's scope.

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

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

The description offers guidance on honest use of scope_type/priority, stating high priority only for real bugs or regressions, and notes the tool is cloud-only. However, it does not explicitly mention when to use this tool instead of alternatives like update_rule or read_rule, so it lacks exclusions.

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

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

The description adds significant behavioral context beyond the annotations, particularly the cloud-only nature and the explicit statement that it does NOT materialize the skill into local directories like .codex/skills or .claude/skills. This is a non-obvious side effect that the annotations (readOnlyHint=false, destructiveHint=false) do not convey. It does not discuss auth requirements or response behavior, but the bar is lower because annotations exist.

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

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

The description is three sentences long, front-loaded with the primary purpose, and every sentence contributes essential information: the creation action, content format, github_ref handling, and the crucial cloud-only materialization caveat. There is no fluff or redundancy.

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

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

With no output schema, the description appropriately omits return values, but it covers the key operational context: creation, content expectations, github_ref usage, and the non-materialization limitation. Given the 8-parameter complexity, the description is sufficient for an agent to understand the tool's behavior, though it could briefly mention prerequisites like obtaining workspace_id via pathrule_list_workspaces (already noted in the schema). Overall, it is complete for a write operation.

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

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

Schema coverage is 100%, so the schema already documents all parameters, earning a baseline of 3. The description adds value by clarifying the relationship between parameters: 'content' must be the full SKILL.md body, and 'source'/'github_url' are linked for github_ref skills. It also emphasizes that the skill is created at a workspace path, reinforcing the node_path and workspace_id semantics. This exceeds the baseline but doesn't fully detail every parameter interaction.

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

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

The description clearly states the specific action ('Create a new skill at a workspace path') and resource (skill), differentiating it from sibling tools like pathrule_update_skill, pathrule_read_skill, and pathrule_delete_skill. It also defines the content format ('full SKILL.md body (frontmatter + markdown)'), leaving no ambiguity about the tool's function.

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

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

The description provides clear context for when to use the tool—creating a new skill—and gives explicit guidance for the github_ref source type ('set source='github_ref' and github_url'). It also includes an important usage limitation: the skill is not materialized to local directories, requiring Pathrule Studio or CLI. However, it does not explicitly state exclusions or alternatives (e.g., 'use pathrule_update_skill for existing skills'), so it misses the top score.

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