Pathrule

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds that the operation enforces current-workspace authorization and a revision check, which explains why expectedVersion is enforced, but it omits permanence/reversibility and any cascade behavior.

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 front-loaded sentence with no padding around the core action. Minor waste in "Cloud-native," which carries no technical meaning.

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?

A destructive mutation with six parameters (only three schema-described), no output schema, and no revert/confirmation semantics. For a delete tool the description should do more to explain impact and required inputs than one terse clause.

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 only 50%, and the undescribed parameters include the required id and expectedVersion plus path. The description's mention of a "revision check" is the only hint that expectedVersion is an optimistic-concurrency token, which is too thin to compensate for the coverage gap.

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?

States a clear verb+resource (delete memory) that distinguishes it from the delete_rule/delete_skill siblings by resource type. However, "Cloud-native" is marketing filler and the tool never explicitly contrasts itself with pathrule_update_memory or pathrule_read_memory, so sibling differentiation is left to the name.

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 when-to-use, when-not-to-use, or alternative (e.g., update vs delete) guidance is given. The phrase "authorization and revision checks" hints at preconditions but never states them as actionable 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 destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds useful context beyond them by flagging workspace authorization and revision checks, but omits what actually happens on a version mismatch, error/recovery behavior, and consequences of deletion.

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?

Front-loaded and very short, with no filler sentences, but it reads as an incomplete fragment rather than a deliberate one-liner, and the vagueness means the brevity costs information rather than saving it.

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?

A destructive 6-parameter delete with no output schema and 50% schema coverage needs more: what errors occur, whether the delete is recoverable, and how expectedVersion/idempotency interact are all absent. The definition leaves real gaps for an agent to call this 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 only 50%, so the description should compensate. It references workspace authorization and revision checks, which loosely map to workspace_id and expectedVersion, but says nothing about id, path, operation_id, or the legacy idempotency_key alias.

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?

States a specific verb+resource ('delete rule') and the 'rule' noun distinguishes it from the delete_memory/delete_skill siblings. However, the phrasing is a terse fragment ('Cloud-native delete rule') and never states plainly what it removes or from where.

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 when-to-use guidance, no routing to alternatives like pathrule_update_rule or the read/history siblings, and no explicit statement of when deletion is appropriate. The only implied prerequisite is the vague 'current workspace authorization and revision checks'.

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, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description does add that current workspace authorization applies and that revision checks are enforced, which is real behavioral context beyond the annotations, though it never states what is destroyed or whether deletion cascades.

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?

It is a single terse sentence with the action front-loaded, so there is no bloat. However 'cloud-native' is unearned filler and the brevity comes at the cost of substance rather than being optimally compressed.

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?

This is a destructive, non-idempotent mutation with 6 parameters at 50% description coverage and no output schema, so the description carries substantial burden. It omits what a skill deletion affects, path scoping, error/version-conflict behavior, and retry semantics, leaving key agent decisions unsupported.

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 50%: operation_id, workspace_id, and idempotency_key are documented in the schema, while id, path, and expectedVersion are not. The phrase 'revision checks' loosely maps to expectedVersion and 'workspace authorization' to workspace_id, so the description adds some meaning but does not fully compensate for the undocumented id/path semantics.

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 fragment 'delete skill' states a verb and resource, which technically distinguishes it from the delete_memory and delete_rule siblings, but the leading word 'cloud-native' is vague filler and the second clause is opaque. It reads closer to a restatement of the tool name than a specific purpose statement.

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?

There is no guidance on when to use this versus pathrule_update_skill, pathrule_delete_rule, or any other sibling. 'Current workspace authorization and revision checks' gestures at prerequisites but gives no actionable context or 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description does add useful behavioral context beyond annotations by disclosing return caps ('at most 20 per kind and 1 MiB') and the scope of what is returned vs. not. However, 'No personal intelligence' is cryptic and unexplained, and there is no note on pagination or freshness.

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?

It is a single compact sentence with little waste, but it is not front-loaded with the action being performed — a reader has to decode a noun phrase before understanding what the tool does. Compactness here reflects ambiguity as much as efficiency.

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 does carry some burden and does sketch the return shape (ancestor bodies plus a title index) and its limits. But for an aggregation tool with a 2048-char path in the schema and unclear parameter semantics, the description is not complete enough to call it confidently without further inference.

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 50%: workspace_id is documented but path has no schema description and a default of '/'. The tool description mentions 'a path' but adds no format, resolution rules, or meaning for either parameter, so it fails to compensate for the gap.

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 names a resource ('knowledge of a path and its ancestors' plus a workspace title index) but never uses an explicit verb like retrieve or get, and the phrasing is opaque ('bodies', 'No personal intelligence'). An agent can infer it is a read/aggregation tool, but the purpose is expressed vaguely rather than as a specific verb+resource, and no sibling (e.g. pathrule_read_memory or pathrule_list_rules) is named for contrast.

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?

There is no indication of when to use this tool versus the many read_/list_/history_ siblings, nor any prerequisites or exclusion conditions. Usage is left entirely to inference from the vague 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, idempotentHint, and destructiveHint=false, so the safety profile is covered without the text. The description does add some value by noting current-workspace authorization and revision checks, hinting at auth scoping and version awareness, but it never says what is destroyed/returned or how revision checks behave.

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?

It is short and front-loaded, but "Cloud-native" is filler that earns no place, and the remaining clause is too terse to be useful. Brevity here stems from under-specification rather than disciplined editing.

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 four parameters, 25% schema coverage, and no output schema, the description should carry more weight about what history is returned and how `before`/`path` scope it. Instead it offers one vague clause, leaving the agent without enough to invoke the tool confidently.

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 25%: just workspace_id is documented (and its "cannot change binding" note lives in the schema, not the description). The description leaves id, path (default "/", maxLength 2048), and especially the integer `before` unspecified, and its vague "revision checks" phrase is never tied to the `before` parameter.

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?

"Cloud-native history memory" largely restates the tool name (pathrule_history_memory) rather than stating a verb and resource precisely. It never explains what the history operation actually returns or how it differs from its closest siblings pathrule_history_rule and pathrule_history_skill beyond the entity noun.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as pathrule_read_memory or pathrule_history_rule. An agent must guess at the intended scenario entirely from the name.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a vague behavioral note about 'current workspace authorization and revision checks,' which hints at validation but does not specify what is checked or what the response contains.

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 definition is extremely short but under-specified, consisting of a sentence fragment with no clear subject or verb. Brevity here sacrifices clarity rather than enhancing it, so it does not earn its place as a helpful description.

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 four parameters (only one described), no output schema, and no explanation of what a 'history rule' returns or how revisions work, the description is far too thin for an agent to call the tool confidently. It omits the return semantics and required context that matter most without an output 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 description coverage is only 25% (just workspace_id), and the description does not mention any of the four parameters. It therefore fails to compensate for the low coverage by explaining what id, path, or before represent or how they affect the history lookup.

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 'Cloud-native history rule' is essentially a restatement of the tool name, not a specific verb+resource statement. It does not differentiate from sibling tools like pathrule_history_memory or pathrule_history_skill, and the added 'current workspace authorization and revision checks' describes prerequisites rather than what the tool actually does.

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?

There is no guidance on when to use this tool versus alternatives such as pathrule_read_rule, pathrule_list_rules, or the other history tools. No context or exclusions are provided, leaving the agent to infer usage entirely.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The phrase "current workspace authorization and revision checks" adds a hint that the call is permission-gated and revision/version aware, which annotations do not convey, but it is too cryptic to be actionable. No return shape or pagination behavior is described.

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?

It is a single short fragment with no padding, which is structurally efficient, but the brevity comes at the cost of meaning rather than from discipline—there is essentially one clause of substance.

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 4-parameter read tool with no output schema and 25% schema coverage, the description should at minimum clarify what history is returned and how id/path/before scope it. None of that is present, leaving the agent under-informed despite the annotations handling safety.

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 only 25% (just workspace_id), and the description says nothing about id, path, or before. The undocumented `before` (integer, min 1) and `path` (maxLength 2048) parameters are left entirely to inference, so the description fails to compensate for the coverage gap.

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?

"Cloud-native history skill" largely restates the tool name and adds a vague qualifier ("cloud-native") that carries no discriminating meaning. It implies retrieval of skill history, but never states what is being retrieved or how it differs from siblings like pathrule_history_memory, pathrule_history_rule, or pathrule_read_skill.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives despite three near-identical history siblings and a read_skill sibling. An agent has no basis for choosing this tool over pathrule_read_skill or pathrule_history_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?

Annotations already declare it a safe, idempotent read, so the description's job is to add the shape of the operation — and it does: a hard 100-item cap, newest-first ordering, and offset-based paging with the 'full page means there may be more' rule. It does not say whether the path is an exact prefix or recurses, which is the one behavior left undisclosed.

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 compact sentence with the cap and ordering front-loaded; the reader learns the page size before the paging instruction. 'Cloud-native' is the only phrase that fails to earn 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 3-parameter read-only list with no output schema, the essentials — page size, sort order, and how to continue — are all covered. The remaining hole is path scoping (prefix vs. exact), which an agent would need in order to filter 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?

At 67% schema coverage, offset and workspace_id are already well documented in the schema, and the description merely restates the paging behavior. The one under-documented parameter, path, gets only 'under a path' — leaving recursive-vs-flat semantics and the meaning of the default '/' unexplained. Baseline 3 fits.

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?

Specific verb+resource: enumerates 'memory items under a path', which naturally separates it from the sibling list_rules/list_skills tools. No sibling is named explicitly and 'cloud-native' is filler, so it stops short of a 5.

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 pagination trigger is stated ('pass offset for the next page'), but there is no guidance on when to choose this over read_memory or history_memory, and no stated preconditions. Usage is only implied by the resource name.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantive behavior: a hard cap of 100 items, newest-first ordering, and an offset-based continuation rule. It does not say what happens for a nonexistent path, which is the remaining gap.

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 colon-and-semicolon sentence that front-loads the resource scope, then the page limit/ordering, then the continuation instruction. Every clause carries information; nothing is redundant.

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's coverage of ordering, page size, and pagination is what an agent needs to page correctly, and annotations handle the safety profile. It is only slightly incomplete in not characterizing a rule item's identity or error behavior for a bad path.

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 67%; the offset and workspace_id parameters are already documented in the schema, and the description only restates the pagination contract. It implies that 'path' scopes the result set but adds no format or hierarchy details for that parameter, so it neither compensates for nor beats 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?

States a specific verb (list) and resource (rule items) plus the scoping key (under a path), which separates it from the list_memories and list_skills siblings by resource noun. It is clear at a glance, though it never explicitly contrasts itself with those siblings.

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 explains how to page ('pass offset for the next page') but gives no when-to-use/when-not guidance and no mention of the alternative list tools for memories or skills. Usage is implied by the resource noun rather than stated.

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 establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's real contribution is behavioral: a hard cap of 100 items, newest-first ordering, and how a full page signals more data. That is genuinely useful context an agent cannot get from the annotations alone, though output shape and workspace-binding behavior are left to the schema.

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 dense sentence that front-loads the purpose and then the pagination constraint; nothing is wasted structurally. Only the leading 'Cloud-native' phrase is dead weight.

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 paginated read-only list with no output schema, the critical facts an agent needs — result cap, ordering, and how to page — are all present, and annotations cover safety. It stops short of explaining path semantics or the workspace binding, but nothing essential to invoking the tool correctly 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?

Schema description coverage is 67%: offset and workspace_id are documented in the schema itself, and the description only restates offset's paging semantics. The path parameter has no schema description at all, and the description does not explain its format (hierarchical key, prefix match, or exact folder), leaving a real gap. Baseline 3 given the mostly self-documenting 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?

States a specific verb and resource ('list of skill items') plus a scope ('under a path'), which is enough to distinguish it from the read/delete/history siblings in the pathrule_* family. The adjective 'Cloud-native' is vague filler that adds no discriminating power, and no sibling is named explicitly.

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?

Pagination guidance ('pass offset for the next page') implies the iterative-list workflow, but there is no explicit when-to-use guidance and no comparison against alternatives such as read_skill for a single item or history_skill for changes. Usage is inferrable from the verb rather than stated.

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?

Goes well beyond the thin annotations (readOnly=false, idempotent=false, destructive=false): it discloses truncation-with-warning behavior, the no-retry rule, caps on stored data (60 file paths, 5 subjects), and the crucial limitation that the server cannot see the agent's files. That is exactly the kind of operational context annotations cannot carry.

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?

Front-loaded with purpose, then usage timing, then constraints. Three sentences, each carrying distinct actionable information with no padding 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 an 11-parameter tool with a nested object and no output schema, the description covers the high-risk behaviors an agent needs (timing, granularity, truncation, path handling, data caps). Return-value semantics are covered by the schema (verbose), but permission/auth expectations are not mentioned.

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 55%, so the description must compensate, and it does for the two most ambiguous parameters: task_summary (one sentence, ~300 chars, truncated not rejected) and files_touched.by_area (workspace-relative, max 60 kept). The enum and scalar params are largely self-documenting via schema, so the remaining gap is small.

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?

States a specific verb and resource: logging a file-modifying response, scoped by structured taxonomy and file paths. This is clearly distinguishable from the sibling family (memory/rule/skill CRUD), so an agent can route correctly without opening the schema.

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 states when to call it ('AFTER every response where you created, edited, or deleted files') and the granularity ('one call per response, not per file'). No alternatives or when-not conditions are named, but the sibling tools are an unrelated family, so the gap is minor.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a hint that workspace authorization and revision state are checked during the read, which is genuine context beyond the annotations, but it is so terse and ambiguous that it does not really explain what those checks mean for the caller.

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?

It is a single short sentence fragment, so it is not bloated, but roughly half its content ("Cloud-native") carries no information. Brevity here reflects under-specification rather than disciplined concision.

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 read tool with no output schema, the description should clarify what a "memory" is, how `id` and `path` relate, and what the revision check implies for the returned data. None of that is present, leaving the agent without enough context to use the tool confidently despite annotations covering safety.

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 33% — only workspace_id is documented in the schema, and the description supplies no meaning for the required `id` or for `path` (default "/", maxLength 2048). With low coverage, the description was expected to compensate and it does not mention any parameter at all.

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 phrase "read memory" gives a verb and resource, so the basic action is identifiable and the resource distinguishes it from read_rule/read_skill. However, "Cloud-native" is filler jargon and the second clause ("current workspace authorization and revision checks") reads as a fragment whose meaning is unclear, so the purpose is only vaguely stated.

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?

There is no statement of when to use this tool versus pathrule_history_memory (version history), pathrule_list_memories (enumeration), or pathrule_get_context. No prerequisites, no exclusions, no alternative named — the agent must infer selection entirely from the name.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description's mention of authorization and revision checks adds a little context about server-side validation, but it is too vague to tell the agent what is actually verified or what errors to expect.

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?

Very short and front-loaded, but the brevity comes at the cost of under-specification rather than efficient information density. 'Cloud-native' is a filler adjective that occupies space without earning it.

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 3-parameter read tool with no output schema, the description should clarify what 'id' identifies, what 'path' scopes, and when to prefer this over list/history siblings. None of that is present, leaving the agent to guess at invocation 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 only 33%: 'id' and 'path' have no descriptions, and only 'workspace_id' is documented. The description adds zero parameter meaning (no id format, no path semantics, no revision identifier), so it fails to compensate for the coverage gap.

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?

States a specific verb+resource ('read rule'), which cleanly separates it from the write/delete/list/history siblings. 'Cloud-native' is filler jargon that adds no discriminating information, and it doesn't distinguish read_rule from list_rules or history_rule explicitly.

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?

There is no statement of when to use this tool versus pathrule_list_rules, pathrule_history_rule, or pathrule_get_context. The phrase 'current workspace authorization and revision checks' hints at a precondition but never tells the agent what triggers this tool or when it would fail.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that workspace authorization and revision checks occur, which is genuine behavioral context beyond the annotations, but it never says what happens on authorization failure or what the revision check guards.

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?

It is a single short sentence, but 'Cloud-native' does not earn its place and the sentence is under-specified rather than efficiently informative. Brevity here is closer to thinness than to tight structure.

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 read tool with three parameters, no output schema, and low schema description coverage, the description omits what is returned (skill content? metadata?), the scope of 'revision', and the meaning of the id/path parameters. It is not sufficient to invoke the tool confidently.

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 only 33%, and the description supplies no parameter information at all — the 'id' and 'path' parameters are essentially undocumented. With coverage this low, the description should compensate but does not.

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?

States a specific verb (read) and resource (skill), which distinguishes it from the sibling read_memory and read_rule tools. However, the prefix 'Cloud-native' is jargon that adds no discriminating meaning, and the trailing clause is vague.

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?

There is no statement of when to use this versus the sibling read_memory/read_rule tools, nor any prerequisite or exclusion. The phrase 'current workspace authorization and revision checks' hints at conditions but never tells the agent when to select this tool.

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 declare this is a non-read-only, non-idempotent, non-destructive mutation, so safety is partly covered structurally. The description adds genuinely useful context beyond that: it signals an authorization requirement and an optimistic-concurrency revision check, which explains the required expectedVersion. It stops short of saying what happens on a version conflict or whether the body is replaced wholesale.

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?

It is a single clause with no padding sentences, which is structurally clean, but "Cloud-native" is dead weight and the overall size is too small to carry the needed meaning. Brevity here reads as under-specification rather than economy.

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 an 8-parameter mutation with no output schema and only 50% schema coverage, the description leaves too much unsaid: which fields it mutates, the semantics of a failed revision check, and the retry/idempotency behavior the schema hints at. An agent could call it, but not confidently.

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 50%, so half the parameters (id, title, path) are documented nowhere. The description does add meaning for two of them implicitly — revision checks map to expectedVersion and workspace authorization maps to workspace_id — but it ignores the required title/body/id and the operation_id/idempotency_key retry pair.

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?

"Update memory" restates the tool name rather than expanding on it, and the leading qualifier "Cloud-native" is undefined jargon that conveys no actionable meaning. It does establish verb+resource, but nothing distinguishes it from the many update_* siblings beyond the word "memory" already present in the name.

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 phrase "current workspace authorization and revision checks" gestures at prerequisites, but it never states when to choose this over pathrule_write_memory, pathrule_update_rule, or pathrule_update_skill, nor what happens when a revision check fails. No exclusions or alternatives are given.

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=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail – that a revision check occurs – which implies optimistic-concurrency failure modes via expectedVersion, but it omits what happens on version conflict, error behavior, or what is mutated.

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?

It is short, but this is under-specification rather than conciseness – a single sentence fragment that is not front-loaded with any actionable information. The brevity costs clarity without saving the reader anything.

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 non-idempotent, non-read mutation with 8 parameters, no output schema, and half its parameters undocumented, the description is far too thin. An agent cannot determine expectedVersion semantics, workspace binding behavior, or retry expectations from this alone.

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 8 parameters and only 50% schema description coverage, the description is expected to compensate but does not. It never mentions id, title, body, path, workspace_id, or the operation_id/idempotency_key duality; only "revision checks" loosely gestures at expectedVersion.

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?

"Cloud-native update rule" essentially restates the tool name, with "cloud-native" adding no discriminating meaning. It never distinguishes this from sibling mutation tools such as pathrule_write_rule or pathrule_update_skill, so an agent learns nothing beyond the name itself.

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 phrase "current workspace authorization and revision checks" hints at prerequisites (auth is required, a revision must match), but there is no explicit when-to-use guidance and no routing between update vs. write vs. read siblings. Usage must be entirely inferred.

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=false, idempotentHint=false, and destructiveHint=false. The description adds useful context beyond them by flagging that authorization and revision checks are enforced (i.e., workspace binding and expectedVersion conflicts matter), which the annotations do not convey. However it says nothing about the update being a full-field replacement or about what happens on version conflict.

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?

It is a single short fragment with no padding, so nothing wastes space, but it is under-specified rather than concise — there is only one clause of real content. Front-loading works only because there is so little to load.

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?

An 8-parameter mutation tool with 4 required fields, no output schema, and full-replacement implications needs more than a fragment: agents are not told that id/title/body are wholesale replacements, how expectedVersion failures surface, or how operation_id/idempotency_key interact with idempotentHint=false. Annotations cover the safety profile, but the update semantics remain undocumented.

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 50%. The schema itself documents body, operation_id, workspace_id, and idempotency_key, but id, title, path, and expectedVersion carry no descriptions. The phrase 'revision checks' loosely implies expectedVersion is an optimistic-concurrency token, but the description does not compensate for the missing parameter documentation.

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 fragment 'Cloud-native update skill' names the verb (update) and the resource (skill), which does distinguish it from pathrule_update_memory and pathrule_update_rule, but 'Cloud-native' is filler and the phrase never states what an update actually does to the skill (full replacement of title/body vs. partial patch). It reads closer to a restated name than a real statement of 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?

There is no when-to-use guidance and no mention of the obvious alternative, pathrule_write_skill, or when an update is preferred over a write. 'Current workspace authorization and revision checks' implies prerequisites but never says under what conditions an agent should pick this tool.

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=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered externally. The description's only added behavioral claim is vague ("authorization and revision checks") and it omits whether writes overwrite existing memories, what happens on revision conflict, or how authorization failures surface.

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?

It is a single short sentence, so it is not bloated, but it is under-specified rather than concise: "Cloud-native" earns no place while essential routing and precondition information is absent.

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 6-parameter mutation tool with no output schema and a crowded sibling set, the description leaves too much unstated. An agent cannot tell how this write relates to update_memory, what it may overwrite, or how the revision/authorization checks affect a call.

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 67%, below the point where the schema alone carries the parameters, and the description supplies nothing about title, body, path, or workspace_id. It also gives no guidance on the operation_id vs. idempotency_key duality, which is the most confusing part of the parameter set.

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 phrase "write memory" restates the tool name rather than describing the operation in its own terms; there is no detail on what a memory write actually creates or how it differs from pathrule_update_memory. "Cloud-native" is filler that adds no selection signal. The purpose is inferable but vague.

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?

There is no statement of when to use this versus pathrule_update_memory, pathrule_write_rule, or pathrule_write_skill. The clause about "workspace authorization and revision checks" hints at preconditions but never says what an agent should verify first or when to prefer an alternative.

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=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely new context by noting workspace authorization and revision checks are performed, but it never says what those checks reject or how they interact with the idempotency/operation_id retry mechanism in the schema.

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 short but under-specified rather than economical — it is a sentence fragment with no subject or clear structure. Brevity here comes at the cost of meaning, so it does not earn its place as concise communication.

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 six-parameter mutation tool with no output schema, this description is far too thin: it omits what happens on write, revision-conflict behavior, idempotency semantics, and any return expectations. The annotations and schema carry most of the load, but the description leaves critical 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?

Schema description coverage is only 67%, so the description needs to compensate and it does not. It never explains body, title, path, or the distinction between operation_id and the legacy idempotency_key alias, all of which an agent must get right to call this correctly.

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?

"Cloud-native write rule" names a verb (write) and resource (rule), which loosely distinguishes it from pathrule_write_memory and pathrule_write_skill. However, "cloud-native" is filler and the sentence gives no sense of what a rule actually is or what writing one entails, so the purpose is only vaguely conveyed.

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?

There is no guidance on when to use this tool versus pathrule_update_rule, pathrule_write_memory, or pathrule_write_skill. The fragment about "authorization and revision checks" hints at preconditions but says nothing about tool selection or context.

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 establish the write/non-readonly, non-idempotent, non-destructive profile. The description adds some behavioral context by noting workspace authorization and revision checks, but does not explain what revision checks do, what happens on conflict, or whether an existing skill is overwritten.

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?

It is very short, front-loaded, and free of sprawling prose. However, 'Cloud-native' is filler jargon and the second clause is cryptic enough that the concision shades into under-specification.

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 six-parameter write tool with many siblings and no output schema, the description omits critical context: create-vs-update semantics, conflict behavior from revision checks, and return expectations. The annotations cover safety, but the description leaves too much unspecified.

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 description provides no parameter-level information, leaving the agent to rely entirely on the schema. With only 67% schema description coverage, the undocumented path and title parameters are not compensated for by the 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 fragment identifies a verb (write) and resource (skill), but 'Cloud-native' adds no discriminating meaning. It also fails to distinguish write_skill from the sibling update_skill, leaving create-vs-overwrite ambiguous.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as update_skill, write_rule, or write_memory. The description merely states that the tool exists rather than when it should be selected.

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