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

No annotations are supplied, so the description carries the full behavioral burden. It never says whether the operation is idempotent, what happens when the page is already a favorite, whether it requires write permissions, or what errors look like on an unknown id/path. "Serializable favorite confirmation" is vague rather than informative.

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 purpose is front-loaded and the text is short, but the Google-style "Args/Returns" block is docstring residue with low value here. The Returns line restates what the output schema already provides.

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 output schema exists, so return-value detail is unnecessary, and the two parameters are addressed. For a state-mutating favorite operation with zero annotations, though, the definition stops short of the permission, idempotency, and error context an agent would need.

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 0%, so the description must compensate, and it partially does: it explains that id is the page identifier and that it takes precedence when both selectors are given, and that path is a slash-separated page path. It omits that both are optional (no required fields) and what happens if neither is supplied.

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 opening sentence states a specific verb and resource ("Favorite a page") and scopes it to the authenticated user, which is clear. It does not, however, distinguish itself from the obvious sibling remove_favorite or explain how it relates to list_favorites.

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 call this versus remove_favorite or list_favorites, nor any statement of preconditions (does the page need to exist first?). The only hint of selection logic is the preference note between id and path, which is parameter-level, not usage-level.

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?

No annotations are provided, so the description carries the full behavioral burden for a write operation. It doesn't disclose permission requirements, what happens on a slug collision (error vs. overwrite), whether creation is idempotent, or any side effects on the page tree. Only the 'parent_id empty for root' hint adds meaningful 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 purpose is front-loaded in the first sentence, followed by a clean Args block and a brief Returns note. It is appropriately sized for 7 parameters, though the Args entries are somewhat telegraphic and the Returns line is partly redundant given an output schema exists.

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 7-parameter mutation tool with no annotations, the definition documents inputs adequately and an output schema covers return values. However it leaves behavioral gaps around error handling, slug uniqueness, and permissions that an agent would want before invoking a create 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 description coverage is 0%, so the description must document all parameters, and it largely does: title, slug, parent_id (with the root-default rule), kind (page/section), content (Markdown), tags, and properties are each explained. It adds real meaning beyond bare schema types, though it omits slug uniqueness/format constraints and the shape of structured properties.

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: 'Create a page or section, optionally with content and metadata.' This clearly distinguishes it from sibling mutations like edit_page, append_to_page, and update_page_tags. It stops short of explicitly naming alternatives, but the create-vs-modify distinction is self-evident.

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 is given. The description never explains when to prefer add_page over append_to_page, edit_page, or ensure_path, nor does it mention prerequisites such as whether the parent must already exist or how it relates to suggest_slug/lookup_path. 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the mutating nature and the return shape, but says nothing about prerequisites (must the page exist?), required permissions, effect on revision history, or whether concurrent appends are safe. For a write tool with zero annotation coverage this is a meaningful 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?

Purpose is front-loaded, and the Args/Returns structure is scannable. The Returns section is somewhat wasted since an output schema already exists, but the whole thing is short and no sentence is egregiously 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?

An output schema exists, so return-value explanation is redundant rather than missing. What is missing for a mutation tool with no annotations is the operational context: permissions, page-existence behavior, and reversibility. Adequate but with clear 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 0%, so the description must compensate, and it largely does: it defines content, id, and path, and adds a genuine precedence rule ("id... preferred when both selectors are supplied") that is absent from the schema. It stops short of format details such as path normalization or empty-content behavior.

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: "Append Markdown content to a page." The verb "append" inherently distinguishes it from creation siblings like add_page and from edit_page. However, no sibling is named, so the differentiation relies on the agent inferring append-vs-replace semantics on its own.

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 named alternative. The only guidance of any kind is the parameter-level note that "id" is preferred when both selectors are supplied, which is selection between parameters, not between tools.

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?

No annotations are provided, so the description carries the full behavioral burden. "Browse" implies a read, but the description does not confirm read-only behavior, mention permissions/auth, or note any limits on tree size or pagination for a potentially large hierarchy.

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 the core action and only one short parameter note plus a return line. The Args/Returns scaffolding is slightly boilerplate given an output schema already exists, but nothing is wasted.

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 single-optional-parameter read tool with an output schema, the description is adequate but thin. Without annotations it should at least confirm the read-only nature and give some hint of when this hierarchical browse is preferred over the other navigation siblings.

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 0%, so the description must compensate, and it does explain that depth is an optional maximum tree depth. That is meaningful but minimal; it does not clarify what happens at depth 0, negative values, or whether depth counts levels or nodes.

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: "Browse the page hierarchy," which is concrete and distinguishable from write siblings like move_page or add_page. However, it offers no differentiation from read-oriented siblings such as lookup_path, get_page_links, or find_page_by_title, which also traverse page structure.

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 says the depth limit is optional but never says when to use this tool versus the many sibling navigation tools (lookup_path, get_page_links, find_page_by_title). No prerequisites, exclusions, or alternatives are given, leaving selection entirely to inference.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the operation is read-only, whether auth/permissions are needed, or what the diff contains; 'Revision comparison returned by LeafWiki' merely restates the purpose rather than disclosing 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?

Front-loaded purpose sentence followed by clearly labeled Args and Returns sections; no wasted prose. The Returns line has little informational value, which keeps it just short of a 5.

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 output schema exists, so return values need not be explained, and the parameters are covered. What is missing is positioning against the many revision/page siblings and any statement of the operation's safety profile, which no annotation supplies.

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 0%, so the description is the only source of parameter meaning, and it documents all four: base vs target revision roles, and the id-vs-path selector with an explicit precedence rule ('id preferred when both selectors are supplied'). This meaningfully exceeds the bare 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 clear verb+resource: comparing two historical page snapshots. An agent can distinguish it from get_page_revision or list_page_revisions by the comparative nature, though the description never explicitly names 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?

No when-to-use guidance, no prerequisites, and no alternatives named despite several revision-related siblings (get_page_revision, list_page_revisions). The only routing hint is 'id preferred when both selectors are supplied', which concerns parameters rather than tool 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the conversion is reversible, what happens to the page's content, tags, or links after conversion, or whether any permissions are required. 'Returns: Serializable conversion confirmation' is too vague to count as meaningful behavioral disclosure.

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 and front-loads the core purpose, with parameter notes in a compact Args block. The 'Returns' line adding little beyond the output schema is the only mild padding.

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 output schema exists, so return values need not be described, and the parameters are well covered. What is missing for a mutating operation with zero annotations is the behavioral side: reversibility, side effects on page content and links, and when conversion is the right choice versus move_page or copy_page.

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 0%, yet the description documents all three parameters: target_kind with its two allowed values, path as a slash-separated page path, and id as the preferred selector when both selectors are supplied. The id-over-path precedence rule is a genuinely useful detail not derivable from 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 and bidirectional resource transformation ('Convert a page to a section or a section to a page'), which is unambiguous about what the tool does. It does not, however, distinguish itself from adjacent siblings like move_page, copy_page, or edit_page, so an agent must infer the distinction from the operation name alone.

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 move_page or copy_page that might achieve a similar looking result. The agent is told what the tool does but not when to reach for it over its siblings.

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 are absent, so the description carries the full behavioral burden. It discloses that assets are copied along with the page, which is useful, but omits permissions, what happens if the slug already exists, whether the source is unaffected, and whether assets include subpages or child content.

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?

Uses a compact Args/Returns layout front-loaded with the one-line purpose, and each parameter line carries information. The 'Returns: JSON-compatible copied page' line is somewhat redundant given an output schema exists.

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 presence of an output schema removes the need to explain return values, and parameter coverage is decent. However, with zero annotations the description should be doing more behavioral work for a mutating tool that creates new content.

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 0%, so the description must compensate, and it largely does: it explains the id-vs-path precedence rule, defines path as a slash-separated source page path, and clarifies that an empty target_parent_id means root. It stops short of stating title/slug format or uniqueness constraints.

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 plus scope: 'Copy a page and its assets.' That is clear and distinguishable from siblings like move_page, add_page, or edit_page, though the description never explicitly contrasts itself with them.

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 guidance on when to use copy_page versus alternatives such as move_page (relocate) or add_page (create from scratch), and no prerequisites or constraints. The only routing hint is the id-vs-path precedence, which is parameter semantics rather than usage 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?

With no annotations, the description carries the full burden, and it does disclose two non-obvious behaviors: the delete is preceded by a fetch of the current version (implying a concurrency/read-before-write step) and descendant deletion is controlled by 'recursive' (default False). However, for a destructive mutation it omits whether deletion is permanent or reversible, what permissions are needed, and what happens to related links or references.

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 purpose sentence is front-loaded and the Args/Returns structure is easy to scan with no filler. It is slightly docstring-formatted, with a Returns line that duplicates a function whose output schema already exists.

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 parameter documentation is complete and the output schema means return values need not be described. But for a destructive operation with zero annotations, the description leaves out key behavioral facts (reversibility, required permissions, side effects on links/children when recursive is false), which an agent needs before invoking a delete.

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 0%, so the description must compensate, and it largely does: it explains id (preferred selector when both are given), path (slash-separated form), and recursive (meaning plus default). The id-vs-path precedence rule is genuine added meaning not present in the schema, though the recursive default also exists as a schema default.

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 ('Delete a page') and adds a notable scope detail ('after fetching its current version'). It does not explicitly contrast itself with siblings such as move_page or archive-type flows, so it falls short of 5, but an agent can identify the operation immediately.

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, nor any stated preconditions or exclusions. The only routing hint ('id: ... preferred when both selectors are supplied') concerns parameter selection within the tool, not tool selection, and is conveyed at the parameter level rather than as usage 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?

With no annotations, the description carries the full burden. It does disclose genuinely useful behavior: partial-update/merge semantics ('omitted values are preserved') and selector precedence (id preferred over path), and it states it returns the updated page. But it is silent on permissions, whether edits create revisions, concurrency/conflict behavior, and reversibility of a destructive-ish mutation.

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 core behavior is front-loaded in the first sentence, and the Args/Returns sections are tightly scoped. Given 0% schema coverage, each argument line earns its place rather than repeating schema data.

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?

Output schema exists, so the Returns line is mildly redundant, but the real gap is routing: with 30 siblings including several near-identical writers, the description never helps the agent choose this tool over them, nor does it cover mutation-specific concerns like revisions or permissions. Adequate but with clear gaps for a 7-param writer.

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 0%, so the description must compensate, and it does: all 7 params are explained, including selector precedence for id vs path, that path is slash-separated, and that each optional field is a replacement whose omission preserves the existing value. It stops short of detailing the properties key/value format beyond what the schema's type hints imply.

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 ('Edit a page') and adds the key semantic qualifier that omitted fields are preserved, which distinguishes it from a full-replace. However, it never names or contrasts with close siblings like append_to_page, update_page_tags, or update_page_properties, so an agent must infer scope from the schema alone.

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 guidance on when to use this versus the many overlapping siblings (append_to_page for adding content, update_page_tags for tags only, update_page_properties for properties only). It also omits prerequisites such as needing an existing page or required permissions. The only usage hint is the selector precedence note.

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?

With no annotations, the description carries the full burden but only says 'ensure ... exists' — it does not state whether missing intermediate path segments are created, whether existing nodes are left untouched, whether an existing page with a different title is overwritten, or what permissions are needed. For a mutation tool this is a substantial gap, though 'ensure' weakly implies idempotency.

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 one-line summary is front-loaded and the Args/Returns blocks are compact and scannable. Slightly more could have been said about behavior, but nothing is wasted.

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 output schema exists, so the return-value note is redundant rather than missing, but for a page-creating tool with zero annotation coverage the description omits idempotency and side-effect details that an agent needs before invoking it. The inclusion of 'Returns: JSON-compatible final page' is thin and does not compensate.

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 0%, so the description must compensate, and it largely does: path is documented as slash-separated, title as the title for the final node, and kind as page or section for the final node. It adds real meaning beyond the bare enum/default, though it does not say how intermediate nodes are titled.

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 specific verb+resource: ensuring a nested page path exists, and clarifies that path is slash-separated with a final node of a given kind. It is clear what the tool does, but it never distinguishes itself from siblings such as lookup_path or add_page, so an agent has no anchor for choosing between them.

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 like lookup_path (for checking existence) or add_page/edit_page. The reader must infer the use case 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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about match semantics (exact vs fuzzy, case sensitivity), whether multiple or single results are returned, or ordering. The singular name 'find_page_by_title' conflicts with the plural 'Find pages by title', leaving result cardinality ambiguous.

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 text is short and front-loads the purpose, but the 'Args:' and 'Returns:' boilerplate restates the schema and output schema without adding information. It is compact rather than under-specified, so it is adequate but not earning each line.

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 annotations and a name/description mismatch on cardinality, the definition omits what an agent most needs: match semantics and whether the result is a single page or a list. The existence of an output schema excuses explaining return fields, but not the matching behavior.

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 0% for the single required parameter, and the description only restates it as 'title: Title to match.' beyond the schema. The matching rule that 'match' implies is never defined, so the description does not 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?

The description gives a verb+resource ('Find pages by title'), which is marginally more than the tool name already conveys, but it does not distinguish this tool from siblings like search_pages or find_pages_by_property. An agent cannot tell why it would use this instead of a general search.

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 reference to any of the 29 sibling tools. The description provides no signal for choosing between find_page_by_title, search_pages, find_pages_by_property, or lookup_path.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape ('Matching page summaries') and that 'key' is required, but says nothing about permissions, volume/limits, or match semantics (exact vs partial), leaving notable gaps.

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-loads the core purpose in one sentence, then cleanly separates Args and Returns. Compact with no wasted prose, though the Args restatement mirrors the schema closely.

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 output schema exists so return values needn't be detailed, and both parameters are covered. For a simple two-parameter read tool with one required field, the definition is adequate, missing only usage/routing 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 description coverage is 0%, so the description must compensate, and it does document both parameters: 'key' as the required property key and 'value' as an optional value to match. Detail on key/value format or matching behavior is thin, keeping it from a 5.

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 ('Find pages carrying a property key and optional value'), making the scope unambiguous. However, it never distinguishes itself from close siblings like search_pages or find_page_by_title, 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?

There is no explicit when-to-use, when-not-to-use, or alternative guidance despite many plausible siblings (search_pages, list_property_keys, find_page_by_title). The purpose loosely implies usage but no routing information is offered.

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?

No annotations are provided, so the description carries the full burden. It adds only that this concerns full-text search indexing; it does not disclose whether status is global or per-space, what states are possible, whether it is cheap to poll, or whether permissions are required.

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 first sentence is tight and front-loaded, but the 'Returns:' block ('Indexing status returned by LeafWiki') restates the resource name without conveying anything new, and an output schema already exists to describe the return 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?

For a zero-parameter read tool with an output schema, the definition is minimally sufficient, but it omits useful context such as what the status values mean or when the index can be considered stale, which an agent would need to act on the result.

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 takes zero parameters, so per the rubric the baseline is 4. There is no parameter meaning for the description to add.

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: retrieving full-text search indexing status. It is clearly distinguishable from the page/file-oriented siblings, though it never explicitly contrasts itself with any of them.

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 is given: nothing about when an agent should check index status (e.g., after adding/editing pages, or before relying on search results). Usage is only weakly implied by the tool 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?

No annotations are provided, so the description carries the full burden. It does disclose the id-over-path precedence rule and that a JSON-compatible page is returned, but says nothing about behavior on a missing/nonexistent page, permissions, or how content vs metadata are distinguished.

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 one-line purpose followed by compact Args/Returns sections; every line earns its place. Slight redundancy with the input schema for the parameter names, but nothing is wasted.

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-only single-item fetch with an output schema present, the description need not explain return structure, and it correctly focuses on selectors and scoping. The main omission is behavior when the page is not found or when neither selector is supplied.

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 0% schema description coverage, the description is the only source of parameter meaning, and it delivers: id is 'Page identifier' and path is 'Slash-separated page path,' plus the precedence rule. It stops short of format examples (e.g., whether path omits leading slash) that would make it a 5.

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 (Get) and resource (page) and names both lookup selectors, so an agent immediately knows this is a single-item retrieval tool. It does not explicitly contrast itself with siblings like find_page_by_title or lookup_path, which keeps it from 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 only guidance is 'id preferred when both selectors are supplied,' which resolves parameter conflict rather than when-to-use-this-tool. There is no mention of when to prefer get_page over search_pages, find_page_by_title, or lookup_path, so tool selection is left entirely to inference.

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?

No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation and the description enumerates what is retrieved, but it says nothing about permissions, cost of computing broken links, pagination, or behavior when the page cannot be resolved. It also doesn't state what happens if neither selector is given, which matters since both parameters are optional.

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 short, front-loaded with the core action, and cleanly sectioned into Args and Returns. The Returns line ('Link information returned by LeafWiki') is a tautology that earns no place, and output schema already exists, so that line is the one wasted element.

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 output schema exists, so return values need not be explained, and both input parameters are described. However, with zero annotations and zero required parameters, the description leaves the agent without any statement of the tool's safety profile or the behavior when both selectors are empty, which is a meaningful gap for a two-selector tool.

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 0%, so the description must compensate, and it does document both parameters: id as the page identifier (explicitly preferred when both are supplied) and path as a slash-separated page path. The only gap is that it never explains the fallback when neither selector is provided.

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 ('Get') and resource ('links for a page') and enumerates the three link categories returned (backlinks, outgoing, broken), which is more informative than a generic 'get links'. It does not explicitly differentiate itself from siblings like get_page or list_page_revisions, so it falls 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?

There is no guidance on when to use this tool versus alternatives such as get_page or lookup_path, and no stated preconditions or exclusions. The only routing hint is the parameter-level note that id is preferred when both selectors are supplied, which is parameter semantics rather than usage 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?

With no annotations, the description carries the full burden, and it does disclose the stand-out behavioral gate (revisions must be enabled). It does not say what happens when revisions are disabled (error vs empty), nor confirm the read-only nature or whether the snapshot is a point-in-time immutable view, leaving meaningful gaps for an annotation-free tool.

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 one-line summary followed by tidy Args/Returns blocks; every line carries information. The Args lines largely mirror schema titles, so there is mild redundancy, but nothing is padded.

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 output schema exists, so 'Historical page snapshot' is sufficient for return values, and the description covers purpose, arguments, a prerequisite, and the return. The remaining gap is failure behavior when revisions are disabled, which is minor for this simple read tool.

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 0%, so the description must compensate and it partially does: 'revision_id' identifier, 'id' as page identifier preferred when both are supplied, and 'path' as a slash-separated page path. But it never resolves the oddity that revision_id is the only required field while id/path are described as selectors, so the interaction between the required and optional params stays ambiguous.

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+resource ('Get a page revision'), which is clearly distinct from sibling list_page_revisions, compare_page_revisions, and get_page. The singular 'a page revision' plus the required revision_id makes the single-item fetch unambiguous, though 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?

It gives one real prerequisite ('requires revisions to be enabled'), which is genuine when-to-use context. However, it never contrasts itself with list_page_revisions or compare_page_revisions, so the agent must infer when a single-revision fetch is preferred over the list/compare siblings.

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?

No annotations are provided, so the description carries the full burden. It does disclose the auth scoping ('authenticated user's') and that results are favorite page summaries, but it omits ordering, pagination, and any note that this is a read-only, side-effect-free operation. For a zero-parameter read tool the risk surface is small, but disclosure is thin.

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 short lines, front-loaded with the operation and followed by the return summary. The 'Returns:' block restates what the first sentence already implies ('summaries'), making it mildly redundant but not wasteful.

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 output schema exists, so the description need not enumerate return fields, and a no-arg read tool has little else to cover. The only real gap is that it does not clarify the scope boundary (user favorites only, not workspace-wide), which a sibling-aware reader might want.

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 takes zero parameters, so the baseline of 4 applies. There is no parameter semantics to explain and the description does not need to compensate for anything.

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?

Uses a specific verb and resource ('List the authenticated user's favorite pages'), which is immediately distinguishable from mutating siblings like add_favorite and remove_favorite. However, it never names or contrasts itself with those siblings, so the differentiation is inferred rather than 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 when-to-use guidance, no prerequisites, and no mention of the obvious alternatives (add_favorite, remove_favorite) or how this relates to them. An agent must infer the usage pattern 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?

With no annotations, the description carries the full burden. It discloses the meaningful prerequisite (revisions must be enabled) and that pagination exists, but says nothing about auth/permission requirements or what happens on a page with revisions disabled.

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 one-line purpose followed by compact Args and Returns blocks; every line maps to a parameter or the return shape. Slightly boilerplate-structured but nothing is wasted.

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-only list tool with an output schema (so return values need not be spelled out), the description covers selectors, pagination, and the enabling prerequisite. Missing only explicit sibling routing and permission 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 description coverage is 0%, so the description must compensate, and it does document all four params. The note that 'id' is preferred when both selectors are supplied is genuinely valuable precedence information that the bare schema does not convey.

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 ('List page revisions') and adds a gating condition ('requires revisions to be enabled'). This distinguishes it from get_page_revision (single) and compare_page_revisions, though it never names those siblings 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?

The prerequisite that revisions must be enabled is useful context, and usage is implied by 'list'. However there is no explicit guidance on when to choose this over get_page_revision or compare_page_revisions, so an agent must infer routing.

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?

With no annotations, the description carries the full behavioral burden, yet it only says keys are 'returned by LeafWiki.' It does not disclose ordering, pagination behavior, default scope, or that the operation is read-only. The 'list' verb implies a safe read but nothing more is confirmed.

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 Args/Returns layout is easy to scan and appropriately short. However, the Returns line ('Property-key objects returned by LeafWiki') is circular and adds no information, and an output schema already exists to cover return shape.

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?

Because an output schema exists, the description needn't explain return values, and it covers both inputs minimally. But for a listing tool with no annotations it should say more about scope, ordering, and how limit/query interact to let an agent call it 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 0%, so the description must compensate. It does name both parameters ('query: Optional property-key filter' and 'limit: Maximum number of keys'), adding meaning the bare schema lacks, but 'filter' is vague about matching semantics (prefix, substring, case).

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 ('List available property keys'), so the agent knows exactly what the tool returns. It does not differentiate from siblings like list_tags or list_favorites, which sit in the same namespace and could plausibly be confused with it.

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 among the many sibling listing tools. The agent must infer usage context entirely on its own.

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?

No annotations are provided, so the description carries the full burden; it implies a read-only listing operation and discloses that results include usage counts, which is useful. However, it omits auth requirements, pagination/limit behavior, and what 'retain' means for the selected parameter, leaving meaningful behavioral gaps.

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 main purpose is front-loaded in the first sentence, followed by clean Args/Returns sections. The Returns line is largely redundant with the existing output schema, but overall it is tight and well-organized.

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 output schema exists, so return values needn't be re-explained, and the description covers purpose and all three parameters. What is missing is behavioral context such as read-only nature and pagination behavior for the limit parameter, but for a simple list tool the coverage is largely 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 description coverage is 0%, so the description must compensate, and it does describe all three parameters (query as name filter, limit as max count, selected as tags to retain). The 'selected' explanation ('Tags LeafWiki should retain in the result set') is vague and leaves its actual semantics unclear.

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 tags and usage counts') plus the optional filter, so an agent immediately knows what the tool produces. It is clearly distinct from the only tag-related sibling (update_page_tags), though it does not explicitly name or contrast with it.

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 'optionally filtering by name' hints at one usage mode, but there is no guidance on when to use this versus update_page_tags or the page/tree tools, and no exclusions or prerequisites. Usage is only weakly implied.

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?

No annotations are provided, so the description carries the full burden. It does disclose a non-obvious behavioral trait — that the result includes both existing and missing segments — but says nothing about read-only nature, permissions, path-format validation, or error behavior for malformed paths.

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 purpose is front-loaded in the first line, and the Args/Returns sections are brief with no filler. The Args/Returns scaffolding is slightly formulaic but every line carries 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?

For a single-parameter read tool with an output schema already documenting the return shape, the description covers purpose, parameter format, and result semantics adequately. The missing piece is sibling routing against ensure_path/browse_tree.

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 0% (the only property, 'path', has just a type), so the description must compensate. It does: 'Slash-separated page path to resolve' supplies the expected format that the schema omits.

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: 'Resolve a path into tree segments', which tells an agent exactly what the tool operates on. It lacks any differentiation from near-siblings like ensure_path or browse_tree, which is the only thing keeping it from 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?

There is no when-to-use, no when-not-to-use, and no named alternative. An agent must infer from the name that this is a read-only existence check as opposed to ensure_path (which presumably creates missing segments), and the description never clarifies that relationship.

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?

With no annotations, the description must carry the full behavioral burden. It mentions that parent_id empty means root and position is zero-based, but omits permissions, reversibility, side effects, conflict handling, and error behavior for a mutation tool.

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 purpose is front-loaded, and the Args section is efficient. The Returns line is redundant because an output schema already exists, preventing a perfect score.

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 output schema handles return values, so that omission is acceptable. However, with no annotations, the description should also cover safety and permissions for a mutation operation; it covers parameters well but leaves behavioral context incomplete.

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 0%, so the description must compensate. It defines all four parameters: id as the preferred page identifier, path as a slash-separated page path, parent_id as the destination or empty for root, and position as an optional zero-based ordinal.

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: 'Move a page under a new parent.' This distinguishes the core action from most siblings, but it does not explicitly differentiate from related tools like copy_page or sort_pages.

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 guidance on when to choose move_page over alternatives such as copy_page or sort_pages. The only contextual notes are parameter-selection details, which belong under parameter semantics rather than usage guidelines.

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?

With no annotations, the description carries the full behavioral burden. It discloses the mutation semantics (a boolean toggle) and states the return value ('JSON-compatible updated page'), but says nothing about required permissions, idempotency of re-pinning, or what happens when neither selector is supplied. Adequate for a simple toggle, but not rich.

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 purpose is front-loaded in a single sentence, followed by tidy Args and Returns blocks. It is appropriately short for a simple tool, though the Args section largely restates the input schema and Returns restates the output schema, adding mild 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?

An output schema exists, so the description need not explain return values, and it covers the three parameters briefly. For a simple boolean toggle this is close to complete; the only real gaps are permission requirements and the no-selector edge case, which are minor here.

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 0%, so the description must compensate, and it does partially by documenting all three parameters: pinned (the toggle), id (preferred selector), and path. However, it omits the defaults (pinned=true, empty-string selectors) and the behavior when both selectors are blank, so the heavy burden of 0% coverage is only partly met.

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 pair and resource: 'Pin or unpin a page.' That is unambiguous and no sibling tool competes for the pinning action, so an agent can select it correctly. It does not explicitly differentiate itself from the page-mutation siblings (update_page_tags, move_page, etc.), which is the only reason it falls 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?

There is no guidance on when to pin versus unpin, no prerequisites, and no mention of alternative tools or conditions. The only usage-adjacent statement ('id preferred when both selectors are supplied') is a parameter tie-breaker, not task-level guidance. The agent is left to infer intent from the name alone.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the removal is scoped to the authenticated user's own favorites, but says nothing about idempotency, behavior when the page is not favorited, required permissions, or reversibility.

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 one-line purpose followed by tight Args entries; nothing is padded except the 'Returns: Serializable removal confirmation' line, which is redundant given an output schema exists. Efficient overall.

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?

Both optional selectors are documented and an output schema exists, so return format need not be described. The remaining gap is behavioral: error/no-op behavior when the page is not currently a favorite is not covered for a mutation tool with no 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 0%, so the description must explain both parameters and it does: id is the page identifier with an explicit precedence rule ('preferred when both selectors are supplied'), and path is described as a slash-separated page path. Both optional selectors are covered, though no format examples are given.

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 ('Remove a page from the authenticated user's favorites') with a clear scope qualifier (the authenticated user's favorites). It is unambiguously the inverse of the sibling add_favorite, so an agent can pick it without opening either 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?

There is no when-to-use, when-not-to-use, or alternative-selection guidance beyond the implicit inverse of add_favorite. The id-vs-path note is an invocation detail, not tool-selection guidance, so the dimension is left essentially unaddressed.

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?

With no annotations, the description carries the full burden and it partially delivers: it discloses that results include excerpts and tag facets and that a 'Search result object' is returned. It says nothing about permissions, result limits beyond the limit param, ordering, or error behavior, leaving notable gaps for a no-annotation tool.

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 first sentence front-loads purpose and output, followed by tight Args and Returns blocks. Every line earns its place with no filler or repetition of the schema titles.

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 output schema exists, so return values need not be re-explained, yet the description covers all four parameters and the return gist. For a no-annotation search tool with 0% schema coverage it is reasonably complete, missing only filtering/pagination nuance.

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 0%, so the description must supply meaning and it does document all four params: full-text query, optional tag filter, zero-based offset, and max result count. That is solid compensation, though it adds no format/syntax examples for the query string.

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 ('Search pages') plus the mechanism ('by text and tags') and what it yields ('excerpts and tag facets'). This clearly separates it from title- or property-based siblings, though it does not name any sibling 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 when-to-use guidance, no stated conditions for choosing this over find_page_by_title, find_pages_by_property, or browse_tree, and no exclusions. Usage is only implied by the 'search by text and tags' phrasing.

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?

No annotations are provided, so the description carries the full behavioral burden of a mutation. It says nothing about permissions, whether ordered_ids must enumerate all children or a subset, what happens to children omitted from the list, or reversibility; the only disclosure is a vague 'Serializable sort confirmation' return line.

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 one-line summary is front-loaded and the Args block is compact. The Returns line is low-value given an output schema exists, but nothing is verbose or buried.

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 output schema exists, so the return value need not be explained. For a two-param mutation with no annotations, however, the definition omits side-effect and ordering-completeness behavior an agent needs to invoke it safely.

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 0%, so the description must carry the params and it largely does: parent_id is 'Parent identifier, or empty for root' (an edge case absent from the schema) and ordered_ids is 'Child identifiers in their desired order.' It doesn't clarify whether the list must be exhaustive, which leaves one semantic 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 first line states a specific verb and resource: 'Set the child ordering under a parent page.' An agent can tell this reorders children rather than moving a page. It does not explicitly name a sibling (e.g., move_page) to sharpen the boundary, 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?

Usage is implied by the operation itself – call this when you want to reorder children under a known parent. There is no explicit when-to-use statement, no exclusion, and no routing note distinguishing it from move_page, which is the most likely confusion among siblings.

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?

With no annotations, the description carries the full burden. It discloses that availability depends on parent_id and that current_id excludes an existing page from conflict detection, which is real behavioral context, but it never states that this is a read-only suggestion with no side effects (i.e., that the slug is not reserved).

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 one-line summary followed by organized Args/Returns blocks. Slightly verbose in the docstring format but no redundant or wasted sentences.

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 output schema exists, so explaining return values in prose is generous rather than required, and purpose plus all three parameters are covered. The main gap is the missing when-to-use routing relative to the page-creation siblings.

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 0%, so the description must compensate and it largely does, giving each of the three parameters a purpose: title as the derivation source, parent_id to scope availability, current_id to exclude self-conflicts. It omits id format expectations and the meaning of the empty-string defaults.

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 ('Suggest an available slug for a title') with a clear scope, and the concept is distinct from page-mutation siblings like add_page/edit_page. It doesn't explicitly differentiate itself from siblings, but the purpose is 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?

There is no when-to-use guidance: nothing says this is a pre-flight helper for add_page/edit_page, nor when parent_id or current_id should be supplied. The Args section describes what parameters mean, not when to invoke the 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?

With no annotations, the description carries the full burden. It does disclose the crucial replace/overwrite semantic ("Complete replacement property mapping"), which tells the agent that existing properties not included are lost, and states the return is the updated page. It omits auth/permission requirements, revertability, and confirmation of destructive scope beyond the word "replace."

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 Args/Returns structure is front-loaded with the core action and each line earns its place. It is appropriately sized for a three-parameter mutation; no filler sentences. Minor verbosity in restating the parameter names, but nothing wasteful.

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 output schema exists, so the terse "Returns: JSON-compatible updated page" is acceptable and return format need not be re-explained. For a mutation tool with zero annotations, however, the description should say more about side effects (that unlisted properties are dropped), permissions, or validation behavior. It is adequate but leaves real 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 0%, so the description must compensate, and it largely does: it explains all three parameters (properties as a complete replacement mapping, id as page identifier, path as slash-separated path) and clarifies precedence with "id preferred when both selectors are supplied." The meaning gap is closed, though the string-map value type of properties is not elaborated.

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?

"Replace a page's properties" gives a specific verb (replace) and resource (page properties), which is enough to distinguish it from tag-oriented siblings like update_page_tags. However, it never explicitly contrasts itself with close alternatives such as append_to_page or edit_page, so sibling differentiation is implicit rather than 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?

The description offers no when-to-use guidance and names no alternatives. The only routing hint is "id: Page identifier, preferred when both selectors are supplied," which is parameter-selection advice, not tool-selection advice. An agent gains nothing about when this tool beats append_to_page or edit_page.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that tags are fully replaced rather than merged ("Complete replacement tag list"), which is the key mutation semantic. However, it says nothing about required permissions, error behavior, or how an empty list is treated.

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 the core action, then clean Args/Returns blocks. Efficient and scannable, with only minor boilerplate (the Returns line is somewhat redundant given an output schema exists).

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-param mutation with an output schema already documenting the return value, the description covers the replacement semantic and the id/path selector preference, which is most of what an agent needs. It stops short of permissions and edge-case handling.

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 0%, so the description must compensate, and it largely does: it defines tags as a complete replacement list, explains that id is a page identifier preferred when both selectors are supplied, and formats path as slash-separated. This adds real meaning beyond the bare typed 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 precise verb+resource ("Replace a page's tags") and the word "Replace" immediately disambiguates it from append/edit-style siblings like append_to_page or update_page_properties. An agent can tell what it does 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?

There is no explicit when-to-use guidance, no mention of prerequisites or exclusions, and no routing to alternatives (e.g., when to prefer update_page_properties or append_to_page). Usage is only implied by the name.

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