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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully clarifies the scope of results (external references, including items without dedicated pages), but says nothing about pagination behavior despite limit/offset existing.

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; the core resource and its scope lead the sentence. It is appropriately sized for the tool's simplicity.

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, annotated tool with no output schema, the description is close to sufficient, but it omits how query/limit/offset shape the results and how it relates to the sibling link/asset tools. These gaps are minor given the annotation coverage but not negligible.

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 all three parameters (limit, query, offset). The description never mentions filtering or paging semantics, so it fails to compensate for the coverage gap; only the self-explanatory parameter names carry any meaning.

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 (Find) and resource (external references linked by the wiki) and enumerates the included categories (tools without pages, downloads, videos, research). It is fairly distinguishable from siblings like wiki_links and wiki_assets, though it never explicitly contrasts itself with them.

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

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

There is no when-to-use guidance and no mention of alternatives such as wiki_links, wiki_assets, or search_wiki, which an agent would plausibly confuse this with. The reader must infer the selection condition from the description 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the 180-line truncation cap and the next_line continuation mechanism, which tells the agent the result may be partial.

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 core capability and its scope limit are front-loaded, and the follow-up action comes second where it belongs.

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 full annotation coverage and no output schema, the description supplies the essentials: input forms, result size limit, and the continuation path. Minor gaps (e.g. behavior when a document is shorter than 180 lines) are not material to 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?

Schema coverage is 0% and the single parameter is only titled 'Id', so the schema alone is ambiguous. The description resolves the ambiguity by stating the id accepts either a search result ID or a URL, which is the key thing an agent needs to supply a valid argument.

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 a specific verb (read/fetch) and resource (indexed document), plus the concrete scope (first 180 source lines) and accepted inputs (search result ID or URL). It also implicitly separates itself from the sibling read_wiki_page, which it frames as the continuation path rather than the initial fetcher.

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 clear conditional routing: when the response carries a next_line, continue with read_wiki_page. That names an alternative tool and the condition selecting it. It stops short of stating when to prefer fetch over search/search_wiki for obtaining the initial ID, so no explicit exclusions are provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real payload context beyond that: the response includes capabilities, requirements, limitations, execution support and installation evidence, which tells the agent what it will actually receive.

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 lookup keys, followed by the payload contents. No filler, no repetition of the name, and every clause carries information.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so at a high level (capabilities, requirements, limitations, execution support, installation evidence). Minor gaps remain around error behavior for an unknown ID or alias, and no example of a valid identifier is given.

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 lone parameter is just titled 'Tool Id'), so the description must compensate — and it does by clarifying that tool_id accepts either a catalog ID or a unique alias, not only an ID. That is meaningful disambiguation beyond the schema, though it gives no format or example values.

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

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

States a specific verb ('Get') and resource ('a tool') plus the two lookup keys (catalog ID or unique alias), which clearly distinguishes it from the sibling list_modding_tools. It stops short of naming that sibling explicitly, so the differentiation is implied rather than stated.

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

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

The requirement of an ID or alias implies you call this when you already have a specific tool reference, which implicitly complements list_modding_tools for discovery. However, there is no explicit when-to-use/when-not guidance or named alternative, leaving the routing 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the genuinely useful detail that the hash follows Bob's GzsTool implementation, which signals output compatibility with that toolchain, but it does not disclose what the input value represents or the return format.

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

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

A single front-loaded sentence with no padding, and the most important information (it computes a hash) leads. The inline enumeration of modes makes it read awkwardly, but nothing is wasted.

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

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

For a two-parameter, read-only, no-output-schema utility the annotation coverage handles safety, and the mode values are recoverable from the description. Still missing is what 'value' should contain and what the returned hash looks like, which matters for a hashing tool with zero schema documentation.

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 mode parameter has no enum, so the schema alone is silent. The description partially compensates by enumerating the four valid mode values (filename, extension, with_extension, legacy), but the required 'value' parameter — presumably a game file path — is never explained, and no default behavior is mentioned.

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 ('Calculate') and resource (hash of a game path) and names the underlying implementation, so an agent knows this is a deterministic hashing utility. It is not confused with any sibling, all of which are wiki/repo/job tools. The phrasing is slightly garbled by listing the mode values inline, but the purpose is legible.

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

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

No guidance on when to use this tool, when another hashing approach is needed, or which mode to choose for a given task. The mode list is presented without any selection criteria, leaving the agent to guess why 'legacy' or 'with_extension' would be 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description still adds value by disclosing the exact payload returned (header bytes, size, SHA-256, candidate converters) and constraining input to configured read roots or workspace — information the agent cannot get from the annotations or the empty schema.

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

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

A single dense sentence with the action and its outputs front-loaded and no filler. Every clause (header bytes, size, SHA-256, candidate converters, scope) carries distinct information.

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

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

For a read-only inspection tool with strong annotations and no output schema, the description covers the return payload and input scope well. It omits error behavior (missing file, path outside read roots) and any size limits, which are minor gaps for this tool class.

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 'path' parameter, so the description must compensate. It partially does by indicating the path resolves against configured read roots or workspace, but it adds no format, extension, or relative-vs-absolute detail beyond that.

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 (Read) and resource (file) and enumerates exactly what is returned: header bytes, size, SHA-256, and candidate converters. That distinguishes it from siblings like read_workspace_text (text contents) and hash_game_path (game-path hashing), though it never names those alternatives 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?

"for a file in configured read roots or workspace" states scope, not when-to-use. The implied use case (probe a file's type/metadata before reading or converting it) is inferable but never stated, and no sibling such as read_workspace_text or hash_game_path is offered as an alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results carry cached coverage, revisions, and freshness metadata, which is useful context about staleness. It does not mention auth requirements, limits, or how caching is populated.

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 the verb first and no filler. The enumeration of resource types is dense but each item earns its place by informing what appears in the result.

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 an output schema, so return values need no explanation, and it takes no parameters, so there are no semantic gaps there. Annotations carry the safety profile. The only missing element is differentiation from sibling sources tools, which is minor given the low complexity.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to compensate for in the schema.

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

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

States the verb 'List' and enumerates the resource types returned: supplied repositories, author profiles, topic discovery, and linked documentation. An agent can infer this is a read/list operation over source metadata. It does not, however, distinguish itself from close siblings like repository_source or sync_additional_sources.

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

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

No when-to-use guidance, prerequisites, or exclusions are given. With siblings such as sync_additional_sources and repository_source in the same domain, the agent is left to guess which tool to pick when it wants source information.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds one piece of return context ('entries report integration level') but says nothing about paging behavior or how limit/offset interact, which would be useful given the idempotent-list nature.

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 with no filler, and the content scope is front-loaded. It is efficient rather than 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 filterable, paginated list tool with four undocumented parameters and no output schema, the description omits filtering semantics, paging rules, and the relationship to the singular get_modding_tool. An agent has to guess how to narrow or page 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% for four parameters. The enumerated categories (converters, editors, frameworks, components) plausibly map to the `kind` filter, but the link is never made explicit, and `query`, `limit`, and `offset` are entirely undocumented in 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?

The description names the resource (modding tools) and enumerates the categories it covers: converters, editors, frameworks, File Monolith/MakeBite components, and linked repositories. 'Browse' is softer than 'list', and nothing distinguishes it from siblings like list_additional_sources, but the scope of the resource is unmistakable.

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

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

No when-to-use guidance and no alternative named. The obvious pairing with get_modding_tool for detail retrieval, and the difference from search/fetch, are never mentioned, so the agent must infer that this is the enumeration entry point.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral content by disclosing that the corpus includes generated category pages and virtual entity pages. It says nothing, however, about pagination behavior despite the limit/offset parameters.

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 no filler; the scope statement leads and the qualifier follows. Efficient, though its brevity is partly under-specification rather than economy.

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

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

For a four-parameter listing tool with 0% schema coverage and no output schema, the description omits the filtering, paging, and result-shape information an agent needs. Annotations cover safety, but the calling contract is largely unexplained.

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 four parameters (kind, limit, offset, category), so the description bears the full burden and does not meet it. Only a faint gesture toward "category membership" appears; the meaning, accepted values, and defaults of kind, limit, and offset are never addressed.

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?

"Browse the complete corpus" gives a verb and a scope, and the addition of "Jekyll-generated category membership and virtual entity pages" hints at what content is included. But it never says this returns a list of wiki pages, and it does not distinguish itself from siblings like search_wiki, wiki_categories, or read_wiki_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 when-to-use guidance and no named alternative. An agent cannot tell from this text whether to call list_wiki_pages or search_wiki for a given information need; the implicit "complete corpus vs. search" contrast is left 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description adds that results are 'sourced' and how empty input behaves, but says nothing about the shape or size of the returned workflow.

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, both load-bearing: the first defines scope and valid topics, the second defines the empty-input case. Nothing is redundant and the retrieval purpose 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 read-only, single-optional-parameter retrieval tool with no output schema, the definition covers scope, valid topics and the default case adequately. A brief note on what the workflow contains (steps, source citations, format) would close the remaining gap.

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 'topic' parameter has only a default of empty string, so the description must carry the load. It does so by enumerating the nine accepted topic values and explaining the empty-string behavior, which is information found nowhere in the schema.

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

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

States a specific verb ('Get') and resource ('a sourced workflow') and enumerates the covered domains, so an agent knows it retrieves guidance rather than raw data. It doesn't explicitly contrast itself with siblings like list_modding_tools or read_wiki_page, leaving some overlap in the adjacent modding/wiki space.

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 closing clause 'Empty topic lists choices' tells the agent how to use the tool in discovery mode, which is real guidance. However, there is no statement of when to prefer this over sibling doc/tool tools or any exclusion, so 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?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent already knows this mutates state in a non-idempotent, non-destructive way. The description adds useful context with 'copy inputs into a fresh job' and 'preview a verified converter command', but says nothing about permissions, what 'fresh job' means on repeat calls, or 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 sentences, action first then the conditional constraint, with no filler. Slightly terse for a 4-parameter mutation tool, but 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 non-idempotent write tool with no output schema and 0% parameter coverage, the description covers the main action and one conditional requirement but omits the other three parameters and any detail on what the previewed command returns. Adequate but with clear gaps.

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

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

Schema coverage is 0% across 4 parameters, so the description carries the full burden. It explains input_root meaningfully in the XML repacking context, but leaves adapter, options, and input_path entirely undefined, so most parameters remain opaque.

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: copies inputs into a fresh job and previews a converter command. This is clearly a preparation step, distinguishable in spirit from run_tool_job/tool_job_status, but the description never names those siblings explicitly, so the differentiation rests on inference from the name.

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

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

It gives one conditional prerequisite (XML repacking requires input_root with all sidecars), which is genuine usage guidance. It does not state when to call this versus run_tool_job, i.e. that this is the mandatory pre-step before execution, leaving the workflow position 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description usefully adds that output carries line numbers and provenance and that pagination terminates on a null next_line, but says nothing about size limits or error behaviour.

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 two clauses, no filler. It is tight, though the same sentence is being asked to carry both purpose and pagination guidance.

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-only tool with no output schema, the description covers the pagination contract but omits any explanation of the three undocumented parameters and return-value detail beyond line numbers and provenance.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and largely fails: it never mentions 'page', 'max_lines' or 'start_line'. The pagination hint implies start_line/max_lines exist but gives no format, valid range, or default semantics.

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

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

States a clear verb ('Read') and resource ('any indexed document') plus the line-number/provenance return shape. However, it never distinguishes itself from near-neighbours like read_workspace_text, search_wiki, or fetch, and 'any indexed document' is broader than the tool's own name, leaving the exact scope fuzzy.

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

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

The only procedural guidance is 'paginate until next_line is null', which describes a loop condition rather than when to choose this tool. No mention of when to prefer it over search_wiki (discovery) or read_workspace_text (local files), and no 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's one added behavioral fact is that the SHA-256 is intended for a later checked edit, which hints at optimistic-concurrency semantics. It says nothing about truncation, pagination, or what happens at file boundaries.

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

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

A single dense sentence with the core action front-loaded and no filler. It is efficient, though the trailing 'for a later checked edit' clause is slightly compressed for the amount of meaning it carries.

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 states that the return is text plus a SHA-256 hash. But it leaves the paging behavior of start_line/max_lines and any truncation semantics entirely undocumented, which is a real gap for a 3-parameter read tool.

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

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

Schema description coverage is 0% and all three parameters (path, max_lines, start_line) have only bare titles. The description never mentions path or the line-windowing parameters, so an agent gets no help understanding that start_line/max_lines page through the file. With low coverage the description is expected to compensate and does not.

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

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

The description names a specific verb (read) and resource (local Lua/XML/code/documentation text), and adds that it returns the text plus its SHA-256. That clearly separates it from siblings like read_wiki_page or inspect_file, 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?

The phrase 'for a later checked edit' implies this is a read-before-write step paired with write_workspace_text, which is useful contextual guidance. However, there are no explicit when-to-use/when-not-to-use rules and no named alternatives, so the routing is left 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?

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: 'Resolves ref to a cited commit' and 'no execution', which tell the agent the ref semantics and that no code is run.

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 with the verbs front-loaded and zero filler. The no-execution caveat is placed right after the core purpose where it matters.

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 tool with 0% schema coverage and no output schema, the description is thin: it explains ref resolution and the read-only/no-execution nature but omits path, line-range, and tool_id semantics, leaving gaps an agent would need to fill by guessing.

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 5 parameters, so the description bears the full burden. It only clarifies the 'ref' parameter ('resolves ref to a cited commit') and says nothing about path, tool_id, max_lines, or start_line, leaving most 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 specific verbs (browse/read) and the resource (catalogued GitHub repository), scoped to 'developing new tools/code updates'. An agent can distinguish it from workspace siblings, though it doesn't explicitly name alternatives like read_workspace_text or inspect_file.

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?

'For developing new tools/code updates' implies the context of use, but there is no explicit when-to-use vs when-not guidance and no named alternatives among the many siblings. Usage must be inferred from the surrounding task.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, but the description adds real substance: 'May rewrite staged files' discloses the side-effect target, and 'Outputs need round-trip/in-game validation' flags that results are not self-verifying. It also lists the return payload (exit status, logs, changed-file hashes) despite no output schema. Only missing piece is timeout/abort behavior.

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

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

Three tight sentences, front-loaded with the action and its side effect, then the return payload, then the validation caveat. Every sentence carries distinct information 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?

With no output schema, the description usefully enumerates the return values, the mutation scope, and the verification caveat, which is what an agent needs to decide to call and how to treat results. The gap is parameter documentation, which the 0% schema coverage leaves entirely on the description.

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 neither parameter is explained in the description. 'job_id' is loosely implied by 'prepared converter', but the agent gets no guidance on valid ids nor on what timeout_seconds controls (per-run limit? kill behavior?), which matters for a destructive tool with a 120s default.

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

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

Names a specific verb+resource ('Run a prepared converter once') and implicitly distinguishes itself from the prepare/status siblings via the words 'prepared' and 'once'. It stops short of explicitly naming prepare_tool_job or tool_job_status, which would have made it a clean 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?

'Run a prepared converter' implies the prerequisite that prepare_tool_job must have run first, and 'once' plus the non-idempotent annotation warns against re-running. However, no alternatives are named and there is no explicit when-not guidance, leaving the agent to infer the pipeline position.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavior in the form of multi-source scope and per-result source citations, but says nothing about result limits, ranking, or pagination behavior.

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

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

One front-loaded sentence with no filler; the scope and the citation behavior are packed efficiently. It is under-specified for its complexity rather than verbose, but structurally sound.

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?

No output schema exists, so the description is the only signal about returns, and it only mentions citations without describing result shape, limits, or ordering. For a one-parameter search tool it is minimally adequate, but the overlap with 'search_wiki' and the bare query semantics leave real gaps.

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

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

Schema description coverage is 0% and the single parameter 'query' is undocumented; the description does not compensate with any syntax, filter, or format guidance. Only the parameter's trivially obvious name carries meaning.

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 enumerates the resources it covers (wiki, entities, resource notes, cached repo docs), plus the output trait of per-result citations. It is clear on its own, but it never distinguishes itself from the sibling 'search_wiki', which reads as a direct overlap for an agent choosing between them.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives despite an obvious sibling ('search_wiki') covering one of the listed sources. The agent must infer the routing decision on its own.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that — no pagination behavior, result ordering, or scope limits.

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 with the core action front-loaded and the enum packed into a parenthetical rather than prose. No filler, though the enum inline does make the sentence dense.

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

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

With four parameters at 0% schema coverage and no output schema, the description covers kind and category but omits limit and any statement about result shape or size. Adequate to start, but gaps remain that the schema does not fill.

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 carry parameter meaning. It partially does: it enumerates the six valid `kind` values and marks `category` as optional, and implies query accepts symbols/extensions. It says nothing about `limit` (default 12) or the defaults for `kind`/`category`.

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

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

Specific verb (search) plus the resource scope implied by the tool name, and it enumerates the six valid `kind` values, which is more than most siblings offer. It does not, however, distinguish itself from the generic sibling `search`, so an agent must infer which corpus each targets.

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 note that 'symbols and extensions work as queries' is an implicit usage hint about acceptable query forms. There is no explicit when-to-use/when-not guidance and no mention of the alternative `search` tool or when to prefer it over wiki-specific retrieval.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the inventory of what is reported, but says nothing about return format or freshness/latency of the status data.

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; every listed item (coverage, commit, versions, workspace) earns its place as a scoping statement.

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

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

With no output schema, the description should convey the shape of what comes back; it names the categories inspected but not their format or structure. Adequate for a no-arg read tool, but thin for a tool whose whole value is its 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?

Zero parameters, so the baseline is 4. Nothing to misinterpret and no parameter meaning needs explaining.

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 ('Inspect') plus the exact resources covered: wiki coverage, source commit, converter versions, workspace. This distinguishes it from read-heavy siblings like search_wiki or repository_source, though it doesn't explicitly name what 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?

No when-to-use or when-not-to-use guidance is given. An agent must infer that this is a diagnostic/status check; no alternative tool or precondition is 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?

Goes well beyond the annotations by disclosing failure behavior (prior snapshots retained), data-handling semantics (curated web references preserved with real review date, not scraped), and an explicit safety boundary (never installs or runs projects). These are exactly the traits an agent needs for a network-touching sync/mutation operation and are not derivable from readOnlyHint/idempotentHint alone.

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 short sentences, front-loaded with the action and side effect, each carrying distinct information (scope, failure retention, reference handling, safety limit). Dense but no sentence is 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 mutating, open-world, no-output-schema tool, the description covers side effects, failure behavior, and safety boundaries, which is most of what an agent needs. Missing only operational detail such as expected duration or auth/rate-limit considerations, which 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 0% and the single parameter has no description, so the description must carry the load. "One or all configured GitHub sources" maps the optional source_id to its semantics (empty = all, set = a single source) and pairs with the default "" value, adding real meaning beyond the bare schema.

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

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

States a specific verb (Refresh) and resource (configured GitHub sources) plus the side effect (rebuild search/catalog), so the agent knows exactly what the call does. It does not name a sibling to disambiguate from the similarly named list_additional_sources, but the action verb makes the distinction reasonably clear.

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?

"Refresh one or all configured GitHub sources" implies the calling condition and the one-vs-all scope, so usage is inferable. There is no explicit when-to-use/when-not-to-use guidance or reference to sibling tools, leaving the agent to infer the trigger from context.

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

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

Annotations already declare non-read-only, non-destructive, idempotent and open-world behavior, so the bar is lower. The description still adds real value beyond them: it states that configured additional sources and their cached documents are preserved, and that the existing index survives a failed rebuild — failure/atomicity semantics that annotations cannot express.

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 tightly written sentences with the primary action front-loaded and the preservation/failure guarantees following. No filler, no restating of the tool name.

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 covers the essentials: what is fetched, what is rebuilt, what is preserved, and what happens on failure. It leaves out details like expected duration or whether the results are reported anywhere, which are minor for a no-arg sync 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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify. No parameter syntax or options are needed or missing.

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?

Concrete verbs (fetch, rebuild) paired with a specific resource (official wiki documentation/search/catalog). The scoping to the 'official wiki' while explicitly preserving 'configured additional sources' cleanly separates it from the sibling sync_additional_sources, so an agent can route without opening either schema.

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

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

The mention that additional sources are preserved implies sync_additional_sources is the tool for those, but the description never states when to run this versus alternatives or what prerequisite state (e.g. network, config) is needed. Usage is only inferable from the scoping language.

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 declare readOnly=true, idempotent=true, destructive=false and closed-world, so the safety profile is covered. The description adds useful content about what is returned (manifest, outputs, log tails), with 'tails' hinting that logs are truncated, but says nothing about job lifecycle states or readiness.

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 tightly worded sentence that front-loads the verb and enumerates the returned artifacts with zero filler. It is efficient, though arguably under-specified rather than over-long.

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?

There is no output schema, and the description partially compensates by naming the three returned artifacts. However, it omits how job_id is obtained, whether the job must be finished, and any notion of job status states, leaving real gaps for a status/monitoring tool.

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

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

Schema description coverage is 0% for the single job_id parameter, so the description is expected to compensate, and it does not explain the id's format or origin. The parameter is nearly self-evident from its name, which keeps this from dropping lower.

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 converter job's manifest, outputs and log tails'), so the agent knows exactly what data it retrieves. It is distinguishable from prepare_tool_job/run_tool_job by name, but it never names or contrasts with those siblings explicitly.

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

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

The description gives no when-to-use guidance, no prerequisites (e.g., that a job_id must come from prepare_tool_job or run_tool_job), and no alternatives. Usage is only inferable from the word 'status' and the sibling naming convention.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine context beyond them: 'does not download or install anything' clarifies that assets are referenced, not fetched — a distinction readOnlyHint alone does not convey. Missing auth/rate-limit context 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?

Two sentences, front-loaded with the core action and immediately followed by the key exclusion. No filler; every clause carries information.

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

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

For a one-parameter read tool whose annotations cover the safety profile, this is roughly adequate. But with no output schema, the description should say more about what 'notes/assets' returns (format, pagination, whether asset binaries are listed), and it does not clarify the tool_id argument.

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 parameter 'tool_id' has no description in the schema. The description never mentions the parameter or explains that it should be a catalogued tool identifier, leaving the agent to infer the argument's meaning from the phrase 'catalogued repository.'

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 (official GitHub release notes/assets) scoped to a catalogued repository. The pairing of read + release assets plus the source (GitHub) makes the tool's domain identifiable, though it does not explicitly name or distinguish itself from any sibling.

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?

Implies usage through the negative constraint 'Does not download or install anything,' which steers an agent away from fetch/install-style siblings. However, it gives no positive when-to-use trigger and names no alternative tool for related release or asset operations.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered elsewhere. The description adds only that results carry source URLs, which is modest added context and no contradiction of the 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 tight sentences, front-loaded with what the tool browses and followed immediately by the alternative. No filler or redundant restatement of the name.

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 annotation-backed detail beyond safety, the description should carry pagination and filtering semantics, but the query/limit/offset behavior is left entirely unexplained. It is adequate to identify the tool but not to invoke it precisely.

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 three parameters (limit, query, offset) have no descriptions in the schema or the text. The description never explains that query filters assets or that limit/offset paginate, so it fails to compensate for the coverage gap.

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

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

The description names a specific verb (browse) and enumerates the resource types returned (images, videos, example downloads, text/code attachments) plus the useful detail that source URLs are included. It also distinguishes itself from read_wiki_page for indexed text attachments, so an agent can separate the two without opening either schema.

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

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

It gives an explicit routing rule: use read_wiki_page for indexed text attachments, implying wiki_assets covers the remaining asset types. There is no explicit when-not guidance or mention of how it relates to siblings like external_resources or wiki_links.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered elsewhere. The description adds that counts are of *indexed* documents, a useful scope qualifier, but says nothing about freshness, caching, or result ordering.

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 — the verb, the resource, and the returned payload all appear immediately.

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 an output schema present, the return shape needn't be explained, and annotations carry the safety profile; the definition is nearly complete for a no-arg listing tool. A word on data freshness would close the last small gap.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is no parameter semantics for the description to compensate for.

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

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

States a specific verb and resource ('List every wiki category') plus what each entry carries ('indexed document count'), which distinguishes it from list_wiki_pages and search_wiki by output shape. It does not, however, explicitly name any sibling it is not, so sibling differentiation is implicit.

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 conveys an enumeration use case but gives no explicit when-to-use, no mention of alternatives like list_wiki_pages or search_wiki, and no prerequisites. Usage is only implied by the listing semantics.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds the useful fact that output differs by direction, but says nothing about link format, whether titles/URLs are included, ordering, or pagination limits.

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 core action front-loaded and no filler. The trailing purpose clause is slightly vague ('related concepts') but costs little.

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 two-parameter read tool with full annotation coverage and no output schema, the description is adequate to call it correctly. The main omission is any hint of return shape or result limits, which is 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%, so the description must carry the load. It does map the two modes (outgoing links vs pages linking back), which effectively explains the 'incoming' flag, but it never mentions the parameter name, its boolean nature, or the default of false.

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

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

Specific verb+resource ('Return links from a page') with the directional scope spelled out ('or pages linking to it'). It is clearly distinct from read_wiki_page, search_wiki, and list_wiki_pages, though it never names a sibling to compare against.

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?

'to follow dependencies and related concepts' implies when to reach for it (graph traversal / discovering adjacent pages), but there is no explicit when-not or alternative named versus read_wiki_page or search_wiki. Usage is inferable rather than stated.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered structurally. The description adds value beyond that by disclosing the optimistic-concurrency requirement (current SHA-256 for existing files) and the output behavior (a reviewable diff), both of which an agent needs before invoking.

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?

Three short sentences, no filler, with the core action front-loaded and the conditional SHA requirement placed before the return-value note. Every sentence carries information.

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

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

For a three-parameter mutation tool with no output schema, the description covers the essential gaps: concurrency control, return value, and destructive nature. It is slightly thin on path conventions and failure modes, but nothing critical to correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by explaining the conditional role of the SHA-256 value, but it never names expected_sha256, and it says nothing about path semantics (workspace-relative? file creation?) or the text payload. Two of three parameters remain undocumented in 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 verb pair (create/edit) and the resource (source or manifests inside the workbench), which is clear enough for an agent to distinguish it from read_workspace_text. It stops short of explicitly naming the read counterpart or the scope boundary of what counts as a 'source or manifest'.

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 one real usage rule — existing files require the current SHA-256 — which implies when the third parameter is needed. However it offers no explicit when-to-use/when-not guidance versus alternatives, and no preconditions such as required permissions or whether new directories are created.

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