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

With no annotations, the description carries the full burden and does well: it discloses guarded vault writers, that raw/ is never written, that log.md is append-only, and that post-apply verification is returned. It does not cover permissions, atomicity, or error behavior, but the key mutation constraints are exposed.

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

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

The description is three short sentences with no wasted language. The core action and post-condition are front-loaded, and each sentence adds distinct information. It is appropriately sized for the tool.

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 mutation tool with no annotations and no output schema, the description is largely complete: it explains side-effect constraints, return values, and parameter shape reference. It still leaves usage timing and the full change object shape to inference from a sibling. That is a minor gap rather than a fundamental omission.

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 'changes' parameter, so the description must compensate. It does so by saying the change shape matches kb_propose_changes, which gives an agent a reference point, but it does not define the shape itself. This is adequate but not self-contained.

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: committing a change set to disk, followed by re-verification. It distinguishes the operation from the sibling kb_propose_changes by contrasting commit/apply with propose. An agent can tell what this tool 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?

The description references kb_propose_changes for the change shape, which implies a relationship but stops short of explicit when-to-use guidance. It does not state conditions such as 'use after proposing changes' or exclusions for alternatives. Usage is implied rather than clearly instructed.

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 the return shape (pages with snippets plus graph neighbours), but does not state whether the operation is read-only, whether it has side effects, or any rate limits or authentication requirements. The return disclosure is valuable but safety context is missing.

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

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

Two tight sentences front-load the action and result with zero filler. Every sentence earns its place and the structure is easy for an agent to parse.

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

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

For a tool with no output schema and no annotations, the description does explain what is returned, which is essential. However, it leaves parameter semantics, safety profile, and sibling routing unaddressed, so it is only minimally complete given the information gaps in the structured fields.

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 the two parameters. It refers to 'a query' only obliquely and says nothing about the 'limit' parameter or its default of 5, leaving both parameters largely undocumented beyond their names.

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 (assemble) and resource (navigable starting set) and explains the output content: top matching pages with snippets plus immediate graph neighbours. This clearly differentiates it from plain search or page-read siblings, but it never names an alternative tool to contrast with, 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 'to decide what to read next' implies an exploratory read use case, but there is no explicit when-to-use guidance, no when-not-to-use condition, and no mention of sibling tools like kb_search or kb_read_page. 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 the full burden and does a fair job: it discloses the return structure ({ts, tool, query, limit, results}), the count field, and the ordering rule ('most recent limit entries oldest-first'). It does not explicitly state that the call is side-effect free or whether any permissions are needed, so a mutation-safety disclaimer is missing.

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, followed by return-shape detail and then the use case. Every sentence contributes, though the field list with backtick formatting is slightly denser than necessary.

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-only log tool with no output schema, the description supplies the return shape, ordering, and purpose. The remaining gaps (permissions, any paging beyond limit) are minor given the tool's simplicity.

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% for the single 'limit' parameter, so the description must compensate. It clarifies that limit bounds 'the most recent limit entries' and that ordering is oldest-first, which adds real meaning, but it never states the default (50) or any maximum bound.

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 ('Read back recorded queries') and explicitly scopes it to the kb_search / kb_build_context call log, which separates it from every sibling that writes or reads wiki content. An agent can distinguish this log-reading tool from other kb_* tools without inspecting 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?

The final sentence gives clear intent ('Use it to see what has actually been asked of the wiki'), so the agent knows the right context. However, it names no alternatives or when-not conditions, so it stops short of full routing 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 does well: it discloses ordering (oldest-first), the exact record shape {id, ts, kind, subject, topic, reason, by}, and the semantics of the count field. It does not state explicitly that the operation is read-only with no side effects, which is the remaining gap.

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

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

Two tight sentences, front-loaded with the purpose, then the return contract. Nothing is wasted and no information is repeated from structured fields.

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 one-parameter read tool with no output schema and no annotations, the description supplies the return shape, ordering, and the count field, which is what an agent needs. The default value of limit and explicit read-only assurance are the only omissions.

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% (the 'limit' property is just titled 'Limit'), so the description must compensate. 'Returns the most recent limit entries' defines what the parameter controls, though it omits the default (50) and any maximum/range.

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 ('Read back recorded research suggestions') and explicitly names the producing sibling (kb_suggest_research calls), which pins down the resource unambiguously against kb_fetch_queries and other kb_* tools.

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

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

Usage is implied: use this to retrieve suggestions previously recorded via kb_suggest_research. There is no explicit when-to-use/when-not guidance, no mention of prerequisites, and no routing to alternatives for other retrieval needs (e.g. kb_fetch_queries).

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only, side-effect-free operation, nor does it describe the shape, size, or format of the returned statistics. It only names the topic of the output.

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 single sentence-fragment is terse and front-loaded, wasting no words. However, its brevity comes at the cost of under-specification rather than genuine conciseness, capping the 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?

With no parameters and no output schema, the description is the only source of return-value information. It hints at the content (graph statistics, index.md categories) but does not explain what an agent can actually do with the result, leaving a real gap for a zero-argument inspection 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?

The tool has zero parameters, so the per-calibration baseline of 4 applies. There are no parameter semantics for the description to add or omit.

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 identifies the resource and its content ('graph statistics' and 'index.md category structure'), but it is a noun phrase with no verb, so it doesn't state the action an agent takes. It also doesn't differentiate itself from siblings such as kb_search or kb_build_context, which could plausibly return related structural information.

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

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

There is no indication of when to call this tool versus the many sibling kb_* tools. An agent must infer that this is for inspecting graph shape/category layout, with no exclusions or alternatives named.

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, and it discloses almost nothing beyond the category names. It does not state whether this is a read-only audit or mutates state, whether a scan is expensive, or what the output looks like. For a no-annotation tool this is a significant 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?

The fragment is short and wastes no words, but it is not front-loaded with an action verb or a purpose statement, so it reads as a bare topic label rather than a usable definition. Conciseness is achieved at the cost of informativeness.

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

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

With no output schema and no annotations, the description is the only source an agent has, and it does not say what the tool returns (a list of issues? counts? a pass/fail verdict?) or how to act on it. For a zero-arg diagnostic tool the definition should at minimum state that it returns hygiene findings.

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 nothing for the description to disambiguate, and it correctly does not invent parameter details.

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

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

The description names the resource scope concretely (broken links, missing-page targets, orphan pages), so an agent can infer this is a knowledge-base hygiene/diagnostics report. However, there is no verb at all – 'Broken links, missing-page targets, and orphan pages.' is a noun fragment – and nothing distinguishes it from the sibling kb_verify, which plausibly covers overlapping link-integrity territory.

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 statement of prerequisites, and no mention of the sibling kb_verify that an agent would need to disambiguate against. The reader is left to guess whether this is a scan, a report, or a repair operation.

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

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

No annotations are provided, so the description carries the full burden, and it delivers: it asserts nothing is written, spells out the return shape (unified diff, create/update/append action per op, before/after verification with warning delta), and flags the index.md rewrite cost. It does not cover permission/auth requirements or failure behavior for malformed ops, keeping it short of a 5.

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 single most decision-relevant fact ('Preview a change set without writing'), then the op grammar, then a tie-breaking preference, then the return contract. Every sentence adds information; nothing is redundant boilerplate.

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

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

With no output schema and no annotations, the description covers inputs, outputs, and the non-mutating guarantee well. The notable gap is the missing explicit handoff to kb_apply_changes (i.e., that a proposal is what you feed to the apply step), which an agent sequencing multi-step edits would benefit from.

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% and the single parameter is a free-form array of objects with additionalProperties permitted, so the schema explains nothing. The description fully compensates by enumerating the four discriminated op shapes and their required fields (page_id/text, category/entry, etc.), which is exactly the documentation 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 specific verb and resource ('Preview a change set') with an explicit scope constraint ('without writing'), which cleanly separates it from kb_apply_changes and the read-only siblings like kb_read_page and kb_verify. An agent can tell what this 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?

Gives concrete in-tool guidance: 'Prefer add_index_entry for a new page: it adds one catalog line without reading or rewriting index.md,' which steers operation selection. However, it never names kb_apply_changes as the commit counterpart or states when-not to use this tool (e.g., for trivial reads).

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 the return payload (markdown text, resolved outgoing links, backlinks), which matters given there is no output schema, but it says nothing about missing-page behavior, permissions, or whether link resolution is expensive.

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, action first, return contents second, with zero filler. Every clause carries information and the example id is embedded inline rather than in a separate note.

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

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

For a simple single-parameter read tool with no output schema, the description covers the action and the return shape well. The remaining gap is discovery of valid page ids and error handling, 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 coverage is 0% and the single required page_id is undocumented in the schema, so the description must compensate. It partially does by showing the expected id shape ('wiki/overview'), which tells the agent this is a path-like slug rather than an opaque UUID, but nothing is said about how to obtain a valid id.

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 ('Read one page by id') and gives a concrete id example ('wiki/overview'), so the agent knows exactly what the tool fetches. It does not explicitly contrast itself with siblings like kb_search or kb_build_context, which keeps it 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 when-to-use instruction, no prerequisites, and no mention of alternatives such as kb_search (find a page) or kb_build_context (assemble multi-page context). The verb 'Read' implies the direct-fetch case, but nothing routes the agent among the 11 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 provided, the description carries the full behavioral burden and mostly fails it. It implies mutation/replacement of in-memory state but does not state whether the operation is expensive, blocking, safe to call concurrently, or what happens to in-flight queries or uncommitted 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?

A single tight sentence with the action and its source front-loaded and zero wasted words. Appropriate size for a zero-argument operation.

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

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

For a zero-param operation with no output schema the core mechanic is conveyed, but the definition is missing the operational context an agent needs: when the reload should be triggered and what the cost or side effects are. 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The schema fully describes the empty argument object and there is nothing parameter-level the description could usefully 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?

The description gives a specific verb ('Rebuild') and resource ('the in-memory graph and search index from disk'), so the agent knows exactly what state is being refreshed. It is distinguishable from siblings like kb_search or kb_verify, though it never names or contrasts them 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 at all: nothing says when a reload is necessary (e.g., after external edits to the knowledge base on disk) or when it is unnecessary or harmful. No prerequisites, no alternative tool is mentioned despite eleven 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 helpfully discloses that matching is lexical (not semantic/graph based) and describes the result shape, but says nothing about query syntax, index scope/freshness, or the effect of limit, which matters for a search tool with zero annotation coverage.

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 purpose and then the return shape; no filler and nothing redundant.

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

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

Because there is no output schema, the description usefully covers return fields, and it names the searched sources. It still omits query-language guidance, limit behavior, and any behavioral constraints, leaving gaps for a tool with no annotations and no schema descriptions.

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 both parameters, so the schema offers no field-level documentation. The description does not mention `query` or `limit` at all, leaving query syntax and the meaning/default of limit entirely undocumented for the agent.

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 (lexical full-text search over index.md and wiki pages) and explicitly says it is lexical, which implicitly distinguishes it from graph/semantic siblings like kb_graph_summary and kb_build_context. It does not, however, explicitly contrast itself with kb_read_page, so an agent must infer the routing.

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: an agent can guess you call this to locate pages before reading them. There is no explicit when-to-use, no condition that selects it over kb_read_page or kb_graph_summary, and no exclusions.

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

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

With no annotations, the description carries the full load and does well: it discloses that this is a deferred, fire-and-forget submission ("Suggestions are read by a research process later; nothing is researched now"), imposes a one-suggestion-per-gap rate discipline, and adds a content restriction (no secrets or third-party personal data). It omits visibility/idempotency details such as whether duplicates are rejected, which keeps it from a 5.

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

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

Front-loaded with purpose, then trigger conditions, then parameter guidance, then caveats, then the return shape -- a logical progression with no filler sentences. It is dense but every sentence carries information; only the return-shape line could be trimmed if an output schema existed.

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 5-parameter write tool with no annotations and no output schema, the description covers purpose, triggers, per-parameter meaning, side-effect timing, content constraints, and the success/rejection return shape ({recorded, id, entry} / {recorded: false, error}). Only downstream visibility and duplicate handling are unaddressed.

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 does: it defines both `kind` values in prose (critical since no enum exists in the schema), gives phrasing instructions for the required `subject`, and names the optional `topic`, `reason`, and `by` with examples including the `by` format ("claude-code in repo X"). There is no parameter left undefined by both schema and description.

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

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

States a specific action and target: record a research suggestion for the owner's research process when the KB has a gap or a missing subject. It is clearly distinct from read-oriented siblings like kb_search and kb_read_page, though it never explicitly contrasts itself with the nearby sibling kb_propose_changes, which an agent might reasonably confuse it with.

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?

Gives two concrete trigger conditions tied to the `kind` values ("could not answer something your work needed" for gap; "a subject the owner's work keeps touching" for subject) and states that nothing is researched now. No explicit when-not-to-use or named alternative tools, so it stops short of a 5.

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 helpfully discloses what citation hygiene actually reports (uncited wiki pages, source pages with no raw evidence, broken raw/ citations), which gives real behavioral insight, but it says nothing about cost, read-only safety, permissions, or what graph stats/hygiene produce.

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 compact sentences, front-loaded with the phase and scope, then a clarifying detail. No filler or redundancy, though the abrupt second fragment could be integrated more cleanly.

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 no output schema, the description is the sole source of behavioral context, and it only covers citation hygiene in any detail. It omits what the audit returns overall and whether the operation is safe/read-only, leaving a gap for a tool whose entire purpose is producing an audit report.

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 are no parameter semantics for the description to add or omit.

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 (audit/verify) and enumerates the scope: graph stats, graph hygiene, and citation hygiene. However, it never differentiates itself from the siblings kb_graph_summary and kb_hygiene, which appear to cover overlapping ground, so an agent cannot tell which to pick from the description 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 when-to-use or when-not-to-use guidance is given. The description never mentions an alternative tool, prerequisite, or workflow phase beyond the label 'Phase-1', leaving the agent to guess how this relates to kb_graph_summary, kb_hygiene, or kb_reload.

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