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

Annotations already declare readOnlyHint=true, so the description's 'strictly read-only' phrasing adds limited new safety information. It does add useful context about the layer being immutable, but does not disclose output format, ordering, or whether recursion/prefix behavior is applied beyond the schema.

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

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

The description is only two short sentences, front-loading the verb and resource, with the second sentence reinforcing the read-only nature. Every sentence earns its place with no filler or redundancy.

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

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

For a simple list tool with one optional parameter, this description is largely complete: it states what is listed, where, and that the operation is read-only. It does not explain what a file in RAW_ROOT looks like or what the returned list contains, but the title and schema reasonably cover the essential usage 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 100%, with the optional 'prefix' parameter fully described as 'Only files under this prefix.' The description adds no parameter-specific information, but the schema already carries this burden, so a baseline 3 is appropriate.

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

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

The description uses a specific verb ('List') and resource ('files in the immutable source layer (RAW_ROOT)'), making the tool's purpose immediately clear. The title 'List source files' reinforces this, and the RAW_ROOT distinction separates it from sibling wiki_list_pages and raw_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?

The description clearly identifies the context: listing files in the immutable, read-only source layer. It does not explicitly name alternatives or state when not to use it, but the RAW_ROOT reference and strict read-only note make the intended scope fairly unambiguous.

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

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

The readOnlyHint annotation already signals safety, and the description aligns with it by stating there is no write access. The line-range note adds slight behavioral context, but the description does not disclose error behavior, output format, or edge cases for the range parameters. No contradiction with annotations.

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

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

The description is short and front-loaded, with the core action in the first sentence. The second sentence about write access is a bit redundant given the readOnlyHint annotation, but it is not harmful and does not add bloat.

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

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

For a simple read tool, the description covers the core operation and hints at the optional line-range capability, while the schema documents the path. However, it omits line-range semantics, return/error behavior, and any guidance relative to sibling tools, leaving minor but 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?

The schema only describes the path parameter, leaving startLine and endLine undocumented, so schema coverage is 33%. The phrase 'optionally as a line range' gives basic meaning to the two integer parameters, but it does not specify inclusivity, ordering, defaults, or how they combine, only partially compensating 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 states a clear verb and resource: reading a file from RAW_ROOT, with an optional line-range behavior. It is clear enough to identify this as the raw source-file reader among the sibling tools, though it does not explicitly contrast itself with raw_list or wiki_read_page.

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 raw_read versus alternatives such as raw_list or wiki_read_page. The 'no write access' clause is a constraint rather than a usage trigger or exclusion. The description does not explain the conditions under which this tool should be selected.

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 provide no read-only or destructive signal beyond false flags, and the description clarifies that the tool mutates log.md by appending a formatted line. It doesn't discuss failure modes or idempotency, but the append behavior and target are disclosed without contradicting annotations.

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

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

Two short sentences: the first front-loads the exact action and format, the second gives the usage rule. No filler or repetition of schema details.

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

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

For a simple append operation with no output schema and full parameter coverage, the description is complete: target file, entry format, and call timing are all specified.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds the output line format ('operation | title') but doesn't add meaning beyond what the schema provides.

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

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

Names an explicit verb ('Append'), a specific target resource (log.md at wiki root), and the exact entry format. This distinguishes it from read-only siblings like wiki_read_log and write tools like wiki_write_page.

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 an explicit trigger: call after every content change (ingest, update, merge, split, delete, refactor) to keep history chronological. It doesn't state exclusions or alternatives, but for an append-only log the usage context is clear.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral detail beyond annotations by mentioning the dead-link check and framing the tool as a pre-mutation safety check. It does not describe output format or edge cases, but with annotations covering the core safety profile, this is a minor 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 sentences with no filler. The first sentence states the full functional scope; the second provides the critical usage warning. Everything earns its place and is front-loaded.

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-only tool with annotations and full schema coverage, the description is nearly complete. It explains what the tool shows (inbound, outbound, dead links) and when to call it. The absence of an output schema is partially mitigated by the explicit listing of the three output categories.

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

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

There is only one parameter, path, and its schema description ('Path relative to the wiki root.') is already complete. The tool description adds no new parameter-level semantics, so the baseline of 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb ('Show') and names the exact resource: inbound links, outbound links, and dead links for a given page. It distinguishes the tool from siblings like wiki_read_page or wiki_search by focusing specifically on link relationships.

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

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

The description gives explicit when-to-use guidance: 'Call before delete, move, or merge.' This directly tells an agent the operational context and makes the tool's purpose actionable without needing to infer from sibling tool names.

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

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

Beyond the annotations, the description explains what actually happens: the page is moved to a trash location, removed from the index, and requires an explicit confirmation flag. It also warns about checking backlinks, adding meaningful behavioral context for a destructive operation.

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

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

The description is a single, focused sentence that front-loads the primary behavior and adds the confirmation requirement and the backlink check. Every clause adds value with no redundancy.

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

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

Given the two simple parameters, complete schema coverage, rich annotations, and clear side-effect disclosure, the description is sufficient for an agent to select and invoke the tool correctly. It covers what is destroyed, the trash location pattern, the confirmation guard, and the recommended pre-check.

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

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

The schema already fully documents both parameters with 100% coverage. The description echoes the confirm=true requirement but does not add new semantic meaning beyond what the input schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: it moves a wiki page to trash and drops it from the index, clearly distinguishing deletion from siblings like wiki_move_page or wiki_update_index. The behavior is concrete and not a tautology of the tool name.

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

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

The description gives clear operational guidance: confirm=true is required and wiki_backlinks should be checked first for incoming links. It does not explicitly compare against alternative tools or state when not to use it, but the usage context and prerequisite are clear.

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

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

Annotations already establish readOnlyHint=true, and the description is consistent with that by saying 'Show' rather than any mutating verb. It adds behavioral value by specifying what the status call reveals, such as embedding model, dimension, counts, and last index time, which helps the agent anticipate the response without an output schema.

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

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

Two concise sentences, front-loaded with the core action and immediately followed by the useful output details and session advice. Every word earns its place; no redundancy.

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

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

For a zero-parameter, read-only status tool with no output schema, the description is complete. It enumerates the state fields, communicates the configuration aspects, and provides session-level context. Nothing essential is missing for an agent to decide to call it correctly.

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

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

There are zero parameters, so the baseline of 4 applies. The description correctly implies no inputs are needed and focuses entirely on the informational output.

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

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

The description uses a specific verb ('Show') with a clear resource ('index configuration and state') and enumerates exactly what is reported: root directories, embedding model/dimension, counts, and last index time. It is clearly distinct from sibling tools by substance, though it does not explicitly name a sibling or contrast itself.

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

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

'A good first call in a session' gives clear situational context for when to invoke this tool. It does not mention exclusions or alternatives, but for a zero-parameter status tool the timing guidance is sufficient.

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

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

The annotations already set readOnlyHint=true, and the description reinforces this by explicitly stating 'Nothing is changed.' It adds useful behavioral context beyond the annotations: the output is a work list, only technical limits are judged, and the tool does not modify wiki state. This is consistent with the annotations and helps an agent predict 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?

The description is three short, focused sentences with no filler. It front-loads what the tool does, immediately clarifies the read-only nature and output type, and then adds a relevant scope exclusion. Every sentence earns its place.

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

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

For a read-only audit tool with all optional, self-documented parameters, the description covers the essential context: what is checked, that nothing changes, what the result is, and what is deliberately not judged. There is no output schema, so a little more detail about the exact shape of the work list could help, but it is adequate for an agent to select and invoke the tool correctly.

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

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

The input schema already documents all three parameters with descriptions, achieving 100% coverage, so the description does not need to compensate. The description's list of audit categories roughly mirrors the checks enum but adds no parameter-specific syntax or behavioral detail beyond what the schema provides.

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

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

The description uses a specific verb ('Check') with the wiki as the resource and enumerates concrete audit categories: frontmatter errors, invalid dates, duplicate ids, dead links, unresolved sources, orphan pages, and empty folders. This clearly distinguishes it from the read/write sibling tools, though it does not explicitly name an alternative or exclusion by sibling name.

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

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

The phrase 'Nothing is changed - the result is a work list' signals the intended use as a safe, read-only audit and implies it is for gathering findings rather than searching or editing. The statement that folder layout is not judged, only technical limits, is a clear scope exclusion that helps an agent decide when this tool is appropriate.

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

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

The readOnlyHint annotation already signals a safe read, and the description's 'Show' is consistent with that. The description adds mild context by mentioning page counts per folder, but it does not disclose details like default depth behavior or whether nested page counts are included. Given the annotations, this is adequate 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 description is two sentences with no filler. The core purpose is front-loaded, followed by a useful usage note. Every word contributes.

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 tool with one optional parameter and no output schema, the description conveys the essential output (folder tree with page counts) and the main use case. It could be slightly more detailed about the exact tree structure, but nothing critical is missing for correct invocation.

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

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

The only parameter, maxDepth, has full schema description coverage. The description adds no extra parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb-resource pair: 'Show the wiki folder tree with page counts per folder.' This distinguishes it from sibling tools like wiki_list_pages and wiki_list_tags through the specific resource being listed.

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

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

The description gives explicit guidance: 'Call before creating a page so the path matches the existing structure.' It provides clear context for when to use the tool, though it does not explicitly discuss alternatives or when not to use it.

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

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

Annotations provide readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds useful behavior beyond annotations: the tool operates on 'indexed' pages and explicitly names the fields returned. It does not mention ordering, pagination defaults, or recursion behavior, but read-only annotations lower the burden.

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

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

A single well-structured sentence that front-loads the verb and resource, then lists output fields and filters. No fluff or repetition.

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

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

For a read-only list tool with seven parameters and no output schema, the description adequately explains what is returned and the main filtering dimensions. It could improve by stating pagination or recursion behavior, but the schema covers those details, and the description does not leave a confusing gap for basic invocation.

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

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

Schema coverage is only 43%, so the description needs to compensate. It names the folder, type, status, and tag filters, matching most user-facing filter parameters, but it does not explain limit, offset, or recursive. The schema already documents some of these, but the description adds no extra meaning for pagination or recursive traversal.

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'), resource ('indexed wiki pages'), and enumerates output fields (path, id, title, summary, type, status, tags, updated date). The word 'indexed' helps distinguish this from raw list tools and the filter sets give a clear identity.

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

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

The description implies usage for listing and filtering indexed pages by folder, type, status, and tag, but it never says when not to use it or names alternatives such as wiki_search or raw_list. A clear exclusion or comparison with wiki_search would have raised this.

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

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

Annotations already indicate this is a read-only operation. The description adds useful behavioral details beyond annotations: output includes counts and is sorted by count descending. This is meaningful context for an agent deciding whether the tool's output meets its needs.

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 sentence that is direct and fully informative. It front-loads the action and resource ('List all tags') followed by the key modifiers. No fluff or repetition.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers all essential information: what is listed, what accompanies it, and the ordering. Nothing an agent needs to decide whether to call it is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add. Per the baseline rule, 0 params earns a 4.

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

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

The description uses a specific verb 'List' with a clear resource 'all tags used in the wiki' and adds the key details of counts and ordering ('highest first'). This makes it easy for an agent to distinguish it from sibling tools like wiki_list_pages and wiki_list_folders.

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 context is clear: this tool is for retrieving the tag list with counts. It doesn't explicitly state exclusions or alternatives, but the resource scope and the presence of sibling tools with different resources provide sufficient contextual 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?

The destructiveHint annotation already flags mutating behavior, and the description adds meaningful behavioral detail: relative Markdown links are rewritten, id-based wikilinks remain valid, and dryRun produces no writes. This is useful transparency beyond the structured annotation and schema.

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

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

The description is two tight sentences with no filler. The core operation is front-loaded, the link-rewriting behavior is stated in the first sentence, and the dryRun capability is a useful second sentence.

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 move/rename tool with a destructive annotation and a full schema, the description covers the main behavior, link handling, and dry-run planning. It does not describe return values or error behavior, but there is no output schema to satisfy and the core invocation context is sufficiently complete.

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

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

Schema description coverage is 100%, so parameters are already well documented. The description reinforces the meaning of dryRun and provides context about link rewriting, but it does not add significant new semantic detail beyond the schema for from, to, overwrite, or updateLinks.

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 action (move or rename) on a specific resource (page or folder), and adds the key side effect of rewriting relative Markdown links while id-based wikilinks remain valid. This clearly distinguishes it from sibling write, patch, and delete tools.

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

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

The description implicitly communicates when to use this tool: when a page or folder needs to be moved or renamed, with dryRun optionally used for planning. However, it does not explicitly state when not to use it or name alternative tools for content editing or deletion, leaving usage guidance mostly 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?

The description exposes a `replace-body` mode that overwrites the entire page body, and the schema also allows `frontmatterMode: replace`, yet the annotations set destructiveHint=false. This is an annotation contradiction: an agent would be misled into thinking no destructive operation can occur. The `'updated' is always refreshed` note is helpful, but it does not resolve the contradiction.

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

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

The description is tight and well-organized: purpose, mode list with a condition, the frontmatter-only behavior, and the `updated` side effect. Every sentence earns its place and no information is repeated from the schema.

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

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

For a 6-parameter tool with a nested object and no output schema, the description covers mode selection and frontmatter-only usage but leaves important operational details unspecified, such as what happens if a section heading does not exist or how errors are surfaced. The annotation contradiction further undermines an agent's ability to accurately model the tool's side effects.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by specifying that `replace-section` and `append-section` require `section` and by clarifying that adding `frontmatter` without `mode` is a frontmatter-only update. It does not describe `frontmatterMode`, but the schema already covers it.

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 action—'Change an existing page without rewriting it'—and enumerates the supported modes, making the tool's purpose clear. It implies a contrast with a full rewrite tool but does not explicitly name a sibling, so it stops short of full differentiation.

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

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

It gives concrete usage rules: section modes require `section`, `mode` can be omitted for frontmatter-only updates, and `updated` is always refreshed. This tells an agent how to select behavior within the tool, though it does not explicitly say when to prefer a sibling tool like wiki_write_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?

Annotations already cover the read-only safety profile (readOnlyHint=true). The description adds value by disclosing the 'newest first' ordering and the specific log.md resource, but it does not mention return format, pagination behavior, or error conditions. This is adequate 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?

A single, front-loaded sentence with zero filler. The core function ('Return the latest log.md entries, newest first') comes first, followed by the usage hint. Every word earns its place.

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

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

This is a simple tool with one optional parameter, read-only annotations, and no output schema. The description covers purpose, ordering, and typical usage. A minor gap is the lack of detail on what an 'entry' contains, but the low complexity makes this acceptable.

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

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

The input schema has 100% coverage: the only parameter 'limit' is fully described with type, min/max, and default. The description does not add any parameter-specific meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Return'), a concrete resource ('log.md entries'), and an ordering guarantee ('newest first'). This clearly distinguishes it from siblings like wiki_read_page or wiki_search, which operate on different resources.

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

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

The description provides a clear usage context: 'useful at the start of a session.' However, it does not explicitly name alternatives or state when not to use this tool, stopping short of a perfect score.

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?

Description aligns with readOnlyHint=true and adds useful default-behavior context beyond the annotation: the full file including frontmatter is returned when no extra args are passed. It also clarifies inclusive line ranges and section scoping, which annotations alone would not convey.

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

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

A single compact sentence that front-loads the core action and uses a semicolon-separated list to cover all behavioral modes. Every word earns its place with no filler.

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

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

For a read-only tool with fully documented parameters, the description sufficiently covers return behaviors (full file, section, line range, frontmatter inclusion). Minor gaps remain: no stated behavior for conflicting parameters (section + startLine/endLine) or for missing headings, but these are edge cases.

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

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

Schema coverage is 100%, so parameters are already documented individually. The description adds value by explaining how parameters interact to select the output mode (full page vs section vs line range), which the static parameter descriptions do 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 ('Read') and resource ('a wiki page') and enumerates three distinct retrieval modes (full file, section, line range). It is distinguishable from siblings like wiki_read_log and raw_read by the 'wiki page' resource, though it does not explicitly name the sibling it is not.

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 mode descriptions imply when to use each argument form (no args for full content, section for a heading, startLine/endLine for ranges), but there is no explicit guidance on when to prefer this tool over wiki_search, raw_read, or wiki_read_log. No exclusions or alternatives are 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?

Annotations already cover idempotency and non-destructiveness; the description adds meaningful behavioral detail about how incremental mode processes only changed files and full mode rebuilds everything. It also notes that normal write paths already update the index, which helps the agent predict 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?

Two dense sentences front-load the core action, then give mode semantics and guidance. Every sentence earns its place and no content is redundant with the schema or annotations.

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

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

The description is sufficient for a no-required-parameter maintenance tool with annotations: it explains when to use, the two modes, and the default. It does not describe return values or performance characteristics, but no output schema exists and reindexing is a side-effect operation, so those are minor 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 coverage is 100%, so the schema already describes both parameters. The description enhances the mode parameter by explaining what each enum value actually does, though it adds no additional semantics for the paths parameter beyond what the schema provides.

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

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

States the action verb 'Refresh' with a specific resource ('the search index') and clarifies two modes, incremental vs full. However, it does not explicitly distinguish itself from the closely named sibling wiki_update_index, so an agent must infer which tool handles which indexing task.

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 usage context: usually unnecessary because write tools update the index, and needed only after filesystem changes outside the server. It does not name the alternative tools or state an explicit when-not-to-use rule, but the condition is clear enough for most routing decisions.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing the algorithm (SQLite FTS5 BM25 + local CPU vectors), the fusion method (RRF), the deduplication behavior ('best hit per page'), and the exact return fields. This is rich behavioral context with no contradiction against annotations.

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

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

Two sentences deliver the core behavior, return format, and mode guidance with no filler. The most important scoping information is front-loaded, and every clause earns its place.

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

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

For a tool with 11 parameters and no output schema, the description covers the essential context: algorithm, result granularity, and return fields. The remaining parameters are fully documented in the schema, so their omission is acceptable. It could be slightly more explicit about result ordering or overall response shape, but k and the stated return fields carry most of that burden.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining what the mode enum actually does: bm25 for exact term matching, vector for semantic paraphrases, and hybrid as the default fallback. It does not need to restate schema-documented parameters.

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 (search), a resource (the wiki), and the concrete retrieval strategy: hybrid BM25 + vector search with Reciprocal Rank Fusion. It also states the per-page output shape, making the tool clearly distinguishable from siblings like wiki_list_pages or wiki_read_page.

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

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

The description gives actionable guidance: use mode='bm25' for exact terms, mode='vector' for semantic paraphrases, and hybrid otherwise. It does not explicitly contrast this tool with sibling alternatives, such as when to prefer wiki_list_pages instead, so it stops short of full alternative 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?

The description adds meaningful behavioral context beyond annotations: it states that with no scope it writes the root index, with a scope it writes <scope>/index.md, and that entries derive from indexed titles and summaries. This aligns with the destructiveHint and idempotentHint annotations, and the 'create or refresh' phrasing conveys that existing index content may be replaced.

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

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

The description is three sentences with no filler. The first sentence states the core purpose, the second specifies the parameter-driven behavior, and the third gives a practical prerequisite. Every sentence earns its place.

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

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

For a tool with two optional parameters, annotations covering destructiveness/idempotency, and no output schema, the description is largely complete: it covers target file, scope behavior, data source, and a precondition. It could more explicitly address what happens to manual edits in an existing index.md, but 'create or refresh' covers this reasonably.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the concrete effect of the scope parameter: 'with scope it writes <scope>/index.md' and 'with no scope this is the root index,' which adds file-path semantics not present in the schema. The title parameter is not elaborated in the description, but the schema already documents it.

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+resource: 'Create or refresh an index.md catalogue,' and clarifies the root vs scoped behavior. It clearly identifies what file is written, but it does not explicitly differentiate itself from similar siblings like wiki_reindex, which could also be interpreted as an indexing operation.

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 instruction 'keep frontmatter current before calling' provides a useful prerequisite and implies the tool should be used after page metadata is updated. However, there is no explicit guidance on when to choose this tool over alternatives such as wiki_reindex or wiki_index_status.

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

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

Beyond the destructiveHint annotation, the description discloses several important behaviors: the path is deliberately not derived by the server, missing folders are auto-created, the YAML header is completed while existing fields are kept, and an existing file is replaced only with overwrite=true. This gives the agent a detailed and accurate behavioral model.

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?

Four dense sentences, each carrying distinct information: effect, path semantics, prerequisite call, YAML behavior, and overwrite caveat with sibling alternative. There is no filler and the most important caveat is front-loaded.

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

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

For a destructive, complex tool with no output schema, the description covers everything an agent needs: when to call it, how to choose the path, how to avoid clobbering existing files, what happens to YAML fields, and which sibling to use for partial edits. No critical call-blocking information is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining path semantics (user-chosen, not server-derived), automatic folder creation, and the overwrite guard. It does not need to restate parameter types since the schema already documents them.

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 'Create or fully overwrite a wiki page,' a specific verb and resource. It goes further by distinguishing itself from wiki_patch_page ('use wiki_patch_page for partial edits'), making the tool's scope unambiguous against its siblings.

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

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

The description gives explicit when-to-use guidance: call wiki_list_folders first so the path matches existing structure, set overwrite=true only when replacing an existing file, and use wiki_patch_page instead for partial edits. This is actionable and routes the agent to the right alternative.

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