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 useful traits: the note lands in an unreviewed state (downstream review needed) and source_ref is provenance rather than authenticated identity (a trust caveat). It omits permissions/auth requirements, dedup or overwrite behavior, and what is returned on success.

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

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

One sentence, front-loaded with the action, and the second clause earns its place by disambiguating the riskiest parameter. Dense but not 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?

For a 4-parameter write tool with no annotations and no output schema and 0% schema coverage, the description is thin: no auth/permission requirements, no statement of what gets created or returned (note ID/path), and no guidance on related_note's expected format.

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 meaningfully clarifies the most ambiguous parameter (source_ref as provenance, not identity), but says nothing about related_note, leaving an unexplained fourth 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?

"Save user feedback as an unreviewed inbox note" states a specific verb (save), a resource (user feedback), and a destination with a state qualifier (unreviewed inbox). It never names a sibling (e.g. wiki_propose vs wiki_capture) to sharpen the boundary, 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?

The phrase "user feedback" implicitly scopes when this tool applies, and "unreviewed inbox note" hints at the capture-vs-review split with wiki_review_queue and wiki_propose. But there is no explicit "use this when / not when", no alternative named, and no stated prerequisites.

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 add real behavioral context by clarifying the return is a list of changed notes rather than diffs, but it says nothing about ordering, pagination behavior, or whether results are capped by the limit default.

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 sentences with no filler, and the core purpose is front-loaded. It is arguably terse to the point of under-specification, 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 return values need not be described. However, for a two-parameter feed tool with zero schema description coverage, the description omits limit semantics and result ordering, which an agent needs to paginate 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 0%, so the description must compensate. It usefully defines since_ms as a Unix millisecond timestamp, adding units and epoch semantics the schema lacks, but the limit parameter is never mentioned, leaving half the parameters undocumented.

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 (notes) plus the filter condition (updated since a Unix millisecond timestamp). The negative clause 'Not a semantic diff' clarifies what kind of result it is not, but no sibling tool is named, so differentiation from wiki_search or wiki_review_queue is left to inference.

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?

'Not a semantic diff' implies a usage boundary (use this for a change feed, not for content comparison), but no alternative tool is named and no when-to-use condition against wiki_search is stated. Usage is only 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?

With no annotations, the description carries full burden, but it does disclose a key behavioral trait: it returns bounded excerpts and 'the host composes the answer', meaning this tool does not synthesize a final answer. That is useful context, but the description omits return format, size-limit behavior, and other operational details.

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 sentences, front-loaded with the core action and followed by the key division of labor. Every sentence adds meaningful information with no waste.

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

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

Given no annotations, no output schema, and 0% parameter coverage, the description is too sparse. It should explain how query and max_chars behave, what the excerpts look like, and how this tool differs from wiki_search or wiki_read.

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 for both parameters. 'For a question' loosely maps to query and 'bounded' hints at max_chars, but neither parameter is explained clearly, leaving the agent with only vague clues about the input contract.

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 specific verb and resource (gather bounded source excerpts) with the context of answering a question, which distinguishes it from a plain search or read tool. It doesn't explicitly name siblings, but the retrieval-for-composition framing is clear enough to select it over wiki_search or wiki_read.

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?

Only the phrase 'for a question' implies usage context. There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as wiki_search or wiki_read, leaving the agent to infer when this tool is preferred.

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 two key traits: the target is not overwritten, and the current target should be read first. It still omits important behavior such as review-queue placement, permission requirements, stale-base handling, and response shape.

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

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

The description is two short sentences with no filler, and the non-overwrite constraint is front-loaded. It is appropriately sized for a terse tool summary, though the missing detail must be scored under completeness rather than conciseness.

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

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

The tool has five required parameters, no annotations, no output schema, and 0% schema description coverage. The description provides only the core non-destructive concept and is not complete enough to guide correct parameter usage or explain the surrounding review workflow.

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% across five required parameters. The description only vaguely maps 'target' and 'replacement' to the operation, leaving title, rationale, and especially base_sha256 unexplained despite their importance for correct invocation.

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: create a separate proposed replacement. The phrase 'Never overwrites it' clarifies that this is not a direct edit, but it does not name the wiki page explicitly or distinguish the tool from sibling workflows like wiki_read or wiki_review_queue.

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 'after reading the current target' implies a prerequisite workflow and safe-use context. However, it does not explicitly name wiki_read as the required prior step, nor does it state when to use this instead of other wiki tools or what happens after the proposal is created.

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 disclosure burden. It does useful work by declaring the returned payload (body, metadata, hash, links, parents, backlinks), which stands in for the absent output schema. However it says nothing about pagination behavior despite line-range parameters, nothing about permissions or failure on a missing slug, and nothing about whether reads have side effects.

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 that enumerates the returned artifacts with no filler. It is appropriately terse for a read tool, though it leaves no room for the usage and pagination guidance that are missing elsewhere.

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 annotations and no output schema, the description does cover the return shape well, which is the biggest gap it could have filled. It is still incomplete on input semantics (what a slug is, what the line range does) and on how this tool relates to wiki_search and wiki_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 is responsible for explaining all three parameters and it explains none of them. 'Body lines' faintly hints that reading is line-oriented, implicitly relating to start_line and max_lines, but the slug format, the meaning of the line window, and the default of 120 lines are all undocumented anywhere.

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 (a note) and enumerates exactly what comes back: body lines, metadata, hash, links, parents, backlinks. That is far more specific than a label restatement. It does not name or contrast with siblings like wiki_search or wiki_context, 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 statement of when to use this tool, when not to, or which sibling to choose instead. An agent can infer from the name that this fetches a note by slug while wiki_search finds notes, but that routing decision 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 exist, so the description carries the full load. It does disclose the ranking mechanism ('transparent heuristic of impact, uncertainty and time'), which is real behavioral value, but it never states that the operation is read-only, what constitutes an 'open question', or how ties/ordering are handled.

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

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

One sentence, front-loaded with the verb and the ranking criteria, with no filler. It is efficient, though the terse jargon leaves too much implicit rather than being genuinely concise.

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 with only one optional parameter the surface is small. Still, the absence of annotations plus an undocumented limit and undefined 'open questions' leaves the definition thinner than a triage tool warrants.

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% and the single 'limit' parameter is never mentioned in the description, so its meaning (max items returned? max questions scanned?) and default of 5 are undocumented outside the schema. The description adds no parameter meaning 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 description pairs a specific verb (rank) with a specific resource (open questions) and names the ranking criteria, which no sibling (search/read/changes/capture/propose/context) does. It stops short of explicitly differentiating itself from siblings such as wiki_propose, and 'open questions' is left undefined.

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 reach for this queue versus wiki_search, wiki_changes, or wiki_propose, and no prerequisites or exclusions. An agent must infer that this is a triage/prioritization surface from the phrase 'review queue' 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?

With no annotations, the description carries the full burden; it does disclose that results are ranked excerpts with a status, implying a non-destructive read. It does not state whether search is read-only, how ranking works, or how limit interacts with ranking, leaving meaningful gaps for a zero-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?

A single front-loaded sentence with no filler and the return behavior placed second. It is efficient, though arguably terse enough that it omits needed detail rather than wasting space.

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 spelled out, but for a 4-parameter search tool with zero schema descriptions and no annotations, the description is too thin. An agent cannot tell what prefix does or whether status filters results.

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 explain all four parameters, and it does not. 'Titles and content' hints at query scope, but limit, prefix, and the status filter are entirely unexplained — and 'status' in the description most likely refers to a returned value, which conflicts confusingly with the status input 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?

States a specific verb (search) and resource (note titles and content) plus what it returns (ranked excerpts and status). It is clearly a search tool versus siblings like wiki_read or wiki_capture, though it never names an alternative 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?

Usage is only implied: 'search' naturally precedes 'wiki_read', but the description never says when to search versus read directly, nor when to use wiki_context or wiki_review_queue. No exclusions or prerequisites are given.

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