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

Annotations declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the blast radius is already flagged structurally. The description usefully adds that preview defaults to true (edit not saved), that authentication with a bot password is required, and that undo instructions are returned — meaningful context beyond the annotations, though it doesn't discuss idempotency or repeated-run 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?

Well front-loaded with a label-per-section layout that is easy to scan. Slightly redundant in restating 'Set preview=false to apply' in both PARAMETERS and RETURNS, but every block earns its place overall.

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

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

For a destructive, open-world mutation tool it covers auth requirements, the safe preview default, and apply semantics; an output schema exists, so return details are largely covered elsewhere. The only incompleteness is the missing 'rationale' and 'nowiki' mentions relative to the schema.

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, but the description goes further by spelling out the literal markup each format value produces (~~text~~, '''text''', etc.), which the schema's enum-free list does not convey. It omits the schema's 'nowiki' format and the required 'rationale' parameter, a minor gap that keeps this from a 5.

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

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

States a specific verb + resource ('adding formatting markup to specific text') and immediately distinguishes itself from the nearest sibling with a 'NOT FOR' clause pointing at mediawiki_find_replace. An agent can route between 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?

Provides explicit USE WHEN triggers with user-phrasing examples ('strike out X', 'make X bold') and an explicit NOT FOR case with the named alternative. Both the when and the when-not are covered.

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, openWorldHint and idempotentHint=false, so safety and mutability are covered. The description adds two genuinely useful behavioral notes: that the 'external' check is slow, and that the response contains a health score plus per-check results and recommendations. It undercuts itself with inaccurate defaults ('default all' vs. the schema's 'all except external', and 'max items per check' vs. the schema's 'max pages to audit'), and never explains the non-idempotent behaviour the annotation flags.

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

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

Front-loaded with the one-line purpose, then cleanly sectioned into USE WHEN / PARAMETERS / RETURNS, and every line is scannable. Some redundancy with the schema (restating checks and limit) and a couple of imprecise sentences keep it from a 5.

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

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

With an output schema present, the RETURNS line is a bonus rather than a requirement, and the trigger phrases and check list are adequate. The notable gap is scoping: 'pages' and 'category' let an agent audit a subset, yet the description never mentions either, so an agent may launch a full-wiki audit when a targeted one was intended.

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 and the schema carries the detail for all five parameters. The description enumerates the meaning of each check value (a helpful gloss on an enum-less string array) but mischaracterizes 'limit' as items-per-check rather than pages-to-audit, omits the 'max 50' cap, and says nothing about 'pages', 'category' or 'rationale'.

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 ('Run comprehensive wiki health audit') plus the multi-check scope, so the aggregate nature of the tool is clear. It does not, however, explicitly differentiate itself from the many single-check siblings (mediawiki_check_links, mediawiki_check_terminology, mediawiki_find_broken_internal_links, mediawiki_find_orphaned_pages), which is precisely the distinction an agent needs.

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 'USE WHEN' section gives three concrete user phrasings ('run health check', 'audit the wiki', 'check wiki quality') that map cleanly to invocation contexts. It stops short of naming alternatives or exclusions, e.g. 'for a single check, call mediawiki_check_links instead', which would make routing between this tool and the per-check siblings 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context beyond them: the batch limit of 50, and the important return contract that missing pages are reported as status rather than raised as errors. It does not, however, discuss rate limits or partial-failure semantics for a large batch.

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

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

Front-loaded one-line summary followed by clearly labeled USE WHEN / NOT FOR / PARAMETERS / RETURNS sections. Every sentence carries selection or invocation value 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 batch read tool with an output schema present, the description covers the essentials: when to choose it, the alternatives, the batch cap, and the missing-page behavior. Nothing an agent needs to invoke it correctly is absent.

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%, and the description's parameter block essentially restates the schema (titles array, max 50, format wikitext/html). It adds no format syntax, title normalization, or ordering semantics beyond what the schema already documents, so the baseline 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?

States a specific verb and resource ('Retrieve content from MULTIPLE pages') and scopes it to a single API call, which distinguishes it immediately from the per-page sibling mediawiki_get_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?

Explicit USE WHEN (2+ pages, faster than individual calls) and NOT FOR clauses route the agent to mediawiki_get_page for single pages and mediawiki_batch_get_pages_info for metadata-only requests. Both alternatives are named with their selecting conditions.

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/openWorldHint, so the safety profile is covered. The description adds real behavioral detail beyond them: the 50-item batch ceiling and the exists=false convention for missing pages, which the agent cannot infer from the schema. It does not explain why idempotentHint is false for a read call, but that is a minor omission.

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

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

Front-loaded with the core purpose, then clearly delimited USE WHEN / NOT FOR / PARAMETERS / RETURNS blocks. Every line 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?

Covers purpose, selection criteria, the batch limit, and the missing-page behavior, and an output schema exists to carry return shape. An agent has everything needed to decide and invoke correctly; the RETURNS line is a helpful summary rather than a redundancy.

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 titles and rationale are already documented; the description only echoes the 'max 50' constraint on titles and says nothing about the rationale audit parameter. Baseline 3 is appropriate when the schema carries the parameter burden.

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), resource (metadata/pages info), and scope (MULTIPLE pages in a single API call), which immediately distinguishes it from the singular sibling. The parenthetical field list (last edit, size, categories) pins down exactly what 'metadata' means.

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?

Explicit USE WHEN ('info for 2+ pages without their content') and NOT FOR clauses, each naming the correct alternative (mediawiki_get_page_info for single pages, mediawiki_batch_get_pages for content). This is textbook routing guidance.

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

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

Goes well beyond the annotations (destructiveHint, idempotentHint=false, openWorldHint) by disclosing that preview defaults to true and must be run before applying, that applying requires bot-password authentication (anonymous sessions cannot edit), and that results include revision ID, diff URL and undo instructions. This is exactly the operational context annotations cannot 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?

Front-loaded purpose, then clearly labelled USE WHEN / NOT FOR / PARAMETERS / WARNING / RETURNS sections that scan well. Slightly bloated by re-enumerating parameters already fully described in 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?

An output schema exists so return values need not be spelled out, yet the description still summarises them plus the authentication prerequisite and the mandatory preview workflow. For a destructive, non-idempotent bulk tool, nothing essential for 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 coverage is 100%, so the parameter list largely restates the schema. It does clarify preview semantics and that pages/category are alternatives, but it omits the required 'rationale' parameter entirely and states 'limit default 50' while the schema says 'default 10, max 50' — a misleading discrepancy. Baseline 3, not higher.

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?

Starts with a specific verb+resource+scope: 'Update text across MULTIPLE pages at once.' The uppercase MULTIPLE immediately distinguishes it from the single-page sibling mediawiki_find_replace, which is named explicitly.

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

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

Contains both a USE WHEN section with example user phrasings ('update everywhere', 'change brand name across docs') and an explicit NOT FOR routing to mediawiki_find_replace for single-page work. The when/when-not/alternative triad is fully present.

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 and openWorldHint=true, so the agent knows this is a safe, network-touching read. The description adds the HTTP-request mechanism and the 20-URL cap, but does not explain the idempotentHint=false behavior (results can vary between calls), rate limits, or failure handling for unreachable hosts. Some added value, but not rich against the annotation baseline.

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

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

Front-loaded with the core action, then clearly sectioned into USE WHEN / NOT FOR / PARAMETERS / RETURNS. Slight redundancy: the RETURNS block partially duplicates the existing output schema, but the structure is otherwise efficient.

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 annotations covering the safety profile and an output schema covering return values, the description covers routing, limits, and timeout semantics well. The only real gap is the idempotency/timeout-behavior nuance, which is minor 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 100%, so both urls and timeout are already documented in the schema, including the max-20 and max-30 limits. The description restates the url/timeout semantics without adding format guidance (e.g., whether URLs must be absolute, handling of duplicates), and omits the rationale parameter entirely. 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?

States a specific verb+resource ('Verify external URL accessibility via HTTP requests') and explicitly names the sibling it must not be confused with (mediawiki_find_broken_internal_links). An agent can distinguish it from the many other mediawiki_* tools without opening the schema.

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

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

Provides explicit USE WHEN triggers quoting likely user phrasings ('check if these links work', 'find broken URLs') plus a NOT FOR clause routing to the correct alternative. Nothing 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=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds the glossary-driven scope and the exclude_code_blocks rationale ('avoid false positives on code paths'), but omits anything about the default-limit cap interaction or what happens when neither pages nor category is supplied. 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?

Front-loaded purpose sentence followed by tight USE WHEN, PARAMETERS, and RETURNS blocks — no filler. Minor deduction: the RETURNS line duplicates what the existing output schema already conveys, and the parameter block re-lists schema facts.

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 six optional parameters, an output schema, and read-only annotations, the agent has most of what it needs: trigger phrases, defaults, and a return-shape sketch. The gap is that no parameters are required and the description never states the behavior when both pages and category are empty or when they conflict.

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 schema already documents all six parameters including defaults, the max-50 limit, and the code-block exclusion rationale. The description's PARAMETERS list largely restates that schema content, adding only the glossary page default value, so baseline 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?

States a specific verb and resource ('Scan pages for terminology violations against a glossary') that is immediately distinguishable from siblings like mediawiki_check_links, mediawiki_check_translations, and mediawiki_find_replace. An agent can tell what this tool does without opening the schema.

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

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

The 'USE WHEN' block gives three explicit user-intent triggers ('check brand terminology', 'find incorrect terms', 'verify consistent naming'), which is strong positive routing. It stops short of naming alternatives or stating when not to use it (e.g. vs. bulk_replace or find_replace for actually fixing terms).

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, openWorldHint=true, and idempotentHint=false, so the safety profile is largely covered. The description adds that results are missing translations grouped by language, but it does not discuss live-wiki behavior, idempotency in practice, or rate/performance characteristics beyond what annotations provide.

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 front-loaded with the core purpose and organized into USE WHEN, PARAMETERS, and RETURNS sections. It is easy to scan, though the parameter list is somewhat redundant given the 100%-covered input schema and the RETURNS note overlaps with the available output 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?

Given the moderate complexity, rich input schema, and available output schema, the description covers the essential calling context: what the tool does, when to use it, key inputs, and the shape of results. The limit default inconsistency is a small completeness gap, but otherwise an agent has enough to invoke 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?

Schema description coverage is 100%, so the schema already documents the parameters in detail. The description's parameter list largely repeats that schema, but it states a default of 50 for limit while the schema says default 20, and it pluralizes pattern values ('subpages', 'suffixes', 'prefixes') differently from the schema ('subpage', 'suffix', 'prefix'). Those inconsistencies reduce rather than add value.

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

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

The description states a specific verb and resource: find pages missing translations in specified languages. This is readily distinguishable from sibling tools like mediawiki_check_links or mediawiki_check_terminology, which check different properties. No ambiguity about what the tool does.

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 USE WHEN section gives clear example prompts, such as asking which pages need German translation or checking language coverage. It does not name alternatives or state when not to use this tool, so it falls short of the explicit when/when-not/alternatives standard.

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/openWorldHint, so the safety profile is covered. The description adds value beyond them by disclosing the return format (HTML diff with green additions/red deletions) and the OR-based revision/title resolution, but it doesn't mention the rationale audit-trail behavior or any rate/limit context.

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

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

Header-labeled blocks (USE WHEN, NOT FOR, PARAMETERS, RETURNS) front-load the purpose and the routing decision. Every sentence carries information; 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 an output schema present, the return format need not be spelled out, yet the description still summarizes it briefly. Combined with full schema coverage and annotations, an agent has everything needed 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?

Schema description coverage is 100%, so the baseline is 3. The description adds the OR-combinatorics between from_rev/from_title and to_rev/to_title, which the flat schema does not express as a constraint, giving the agent the either/or selection model not obvious from additionalProperties=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?

States a specific verb+resource+output: 'Compare two revisions and show the diff.' The NOT FOR clause explicitly distinguishes it from mediawiki_get_revisions and mediawiki_compare_topic, so an agent can route without opening any schema.

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

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

Gives explicit USE WHEN phrases ('what changed between versions', 'show the diff') and NOT FOR exclusions that name the correct alternative tools for both near-miss cases (listing revisions, cross-page topic comparison). Nothing 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 declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false, so the safety and idempotency profile is already covered. The description adds useful behavioral context by explaining that it returns page mentions with context, detected value mismatches, and inconsistencies. It does not mention rate limits or permission requirements, so it is strong but not fully exhaustive.

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 front-loaded with the core purpose and then uses clear headings for USE WHEN, NOT FOR, PARAMETERS, and RETURNS. Every section earns its place by helping the agent decide whether and how to call the tool.

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

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

The tool has an output schema, and the description still summarizes the return shape as page mentions, value mismatches, and inconsistencies. Combined with explicit usage guidance, an alternative-tool exclusion, and annotation coverage, the definition gives the agent everything needed 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?

Schema description coverage is 100%, and the schema itself documents all four parameters including the optional rationale field. The description repeats the topic, category, and limit parameters with basic meanings but omits rationale entirely, adding little beyond the structured schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Compare how a topic is described across multiple pages.' It also explicitly distinguishes this tool from mediawiki_compare_revisions, so an agent can route correctly 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 USE WHEN section gives concrete user-intent examples such as 'how is X described on different pages' and 'find inconsistencies about timeout.' The NOT FOR section names the exact alternative tool for revision comparison, making the usage boundary 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavioral detail the annotations don't: what each OPTION does to the output (add_css styling block, reverse_changelog ordering, prettify_checks emoji substitution) and how themes change rendered colors. It does not address the non-idempotent hint, but that 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?

Content is front-loaded with the one-line purpose and organized under labeled sections, and the input/output example earns its space. It is somewhat repetitive, restating the OPTIONS bullets that the schema already documents, which keeps it just short of a 5.

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

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

With an output schema present, return values need no prose, and readOnlyHint carries the safety profile. Purpose, triggers, option semantics, theme meanings, and a worked example together give an agent everything needed 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?

Schema coverage is 100%, so the baseline is 3, but the description genuinely extends it: themes are annotated with brand specifics ('Hero Blue #021e57 headings, yellow code highlights') and defaults are called out ('neutral ... default'), beyond the schema's terse enum-like wording. The EXAMPLE also clarifies the expected shape of the required markdown input and the produced markup.

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

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

States a precise verb+resource pair ('Convert Markdown text to MediaWiki markup') and immediately scopes it against siblings by saying it runs 'before creating or editing wiki pages', separating it from mediawiki_edit_page and mediawiki_apply_formatting. An agent can identify the tool's role without opening the schema.

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

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

A dedicated WHEN TO USE block names four concrete trigger scenarios (Markdown content for the wiki, GitHub/GitLab docs, README files, release notes) and implies the alternative workflow (edit/create after conversion). Nothing about when to reach for this tool 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 declare the write/destructive/openWorld profile, and the description adds substantially beyond it: authentication (bot password) required, anonymous sessions cannot edit, preview defaults to true and consumes no token, base_timestamp triggers an 'editconflict' failure rather than silent overwrite, and a recovery loop (re-read with mediawiki_get_page and reapply). Overwrite scope is also flagged in the WARNING.

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?

Well front-loaded and sectioned (USE WHEN / NOT FOR / PARAMETERS / RETURNS / NOTE / WARNING), so an agent can skim. There is mild repetition: preview is explained in PARAMETERS, again in RETURNS, and implied in the WARNING, and base_timestamp is stated twice in near-identical wording.

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?

Covers the full lifecycle an agent needs for a destructive write: prerequisites (auth), safe default (preview), concurrency protection (base_timestamp), failure recovery, and the shape of both preview and applied responses. Output schema exists but the extra prose about diffs and undo instructions is still useful 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 coverage is 100%, so the baseline is 3; the description nevertheless adds real meaning, notably the preview null-vs-false semantics and the conflict-avoidance workflow for base_timestamp. It does not, however, cover captcha_id/captcha_word or the 'new'/numeric section convention, so it stops short of fully complementing 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 (create/rewrite) and resource (page content), and explicitly names the two sibling tools it is not for (mediawiki_find_replace, mediawiki_apply_formatting). An agent can distinguish this from every other mutating sibling without opening a 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?

Uses explicit USE WHEN triggers ('create a new page', 'rewrite the entire About page') and NOT FOR exclusions that route simple edits and formatting to the correct alternatives. Both the affirmative and negative cases are covered.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful scoping context (what counts as broken, default 20 pages) and return structure, though it doesn't address the idempotentHint=false nuance or scanning cost. Solid but not rich beyond 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?

Uses labeled sections (USE WHEN, NOT FOR, PARAMETERS, RETURNS) with a front-loaded purpose sentence. Every line is scannable and 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?

An output schema exists, so return-value detail is redundant but harmless. The description fully covers purpose, selection criteria, exclusions, and parameter roles for a read-only scan tool. Nothing needed to call it correctly 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 schema already documents all parameters including the max-100 limit and the rationale field. The description's PARAMETERS block largely restates the schema and omits the rationale audit parameter, adding little beyond it. Baseline 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?

States a specific verb (Find) and resource (internal wiki [[links]] pointing to non-existent pages), which precisely names the operation. It explicitly distinguishes itself from the sibling mediawiki_check_links, so an agent can differentiate without opening schemas.

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?

Provides explicit USE WHEN triggers with quoted user phrasings, plus a NOT FOR exclusion that names the alternative tool (mediawiki_check_links) for external URLs. This is exactly the when/when-not/alternative structure an agent needs.

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, openWorldHint=true, and idempotentHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that, and notably does not explain the non-idempotent hint or any scan cost/rate consideration; with annotations doing the heavy lifting, 3 is appropriate.

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?

Well-structured and front-loaded: purpose first, then USE WHEN, PARAMETERS, RETURNS. The RETURNS line is redundant given a dedicated output schema exists, which is the only meaningful waste in an otherwise tight block.

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-purpose lookup with 100% schema coverage and an output schema, the description carries enough to call correctly. What is present is sufficient; remaining gaps (scan scope, cost) are minor and partly mitigated by annotations.

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

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

Schema description coverage is 100%, so all four parameters (including rationale) are already documented in the schema. The description's PARAMETERS block largely restates schema text (namespace default 0, limit default 50) without adding format, syntax, or edge-case meaning, so the baseline 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?

States a specific verb and resource with the defining constraint ('pages with no incoming links from other pages'). This cleanly separates it from siblings like mediawiki_find_broken_internal_links and mediawiki_get_backlinks, so an agent can disambiguate without opening schemas.

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 'USE WHEN' block gives concrete user phrasings that select this tool, which is clear context for invocation. It stops short of naming an alternative tool or a when-not condition (e.g., distinguishing from stale/broken-link discovery), so it earns a 4 rather than 5.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description adds context annotations cannot carry: the safe-by-default preview behavior (omitted preview = no save), the requirement of bot-password authentication, and that anonymous sessions cannot apply edits. It also notes undo instructions and revision IDs on return, which is meaningful for a destructive mutation.

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

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

Front-loaded with the routing decision and broken into scannable USE WHEN / NOT FOR / PARAMETERS / RETURNS / NOTE blocks with no filler prose. Minor redundancy: 'Set preview=false to apply' appears in both the parameter entry and the RETURNS line.

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

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

Covers the routing, the destructive-edit safety model, and the auth prerequisite, and an output schema exists so return details need not be repeated. Slightly incomplete in that its parameter enumeration skips two schema parameters including the required 'rationale', but the 100% schema coverage compensates.

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 every parameter is already documented in the schema; the description's parameter list largely restates it (e.g., 'all: Replace all occurrences (default false = first only)') and adds no syntax or format detail beyond the schema. It also omits the required 'rationale' and the 'minor' flag from its own parameter list. Baseline 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?

Opens with a specific verb+resource plus scope: 'simple text changes on a single page,' and labels itself PREFERRED. It explicitly distinguishes itself from mediawiki_edit_page, mediawiki_bulk_replace, and mediawiki_apply_formatting, so an agent can route without opening any 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?

Provides both a USE WHEN block with concrete trigger phrases ('replace X with Y', 'fix the typo') and a NOT FOR block naming the correct sibling for each excluded case. This is explicit when/when-not/alternative guidance with nothing 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=true, openWorldHint=true, and idempotentHint=false, covering the safety and determinism profile. The description adds the return shape and parameter defaults but discloses no behavioral traits beyond that, such as computational cost, permissions, or why results are non-idempotent. 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?

Header-delimited sections (USE WHEN, NOT FOR, PARAMETERS, RETURNS) make it skimmable, and the core purpose plus the key sibling distinction are front-loaded in the first two lines. No filler sentences.

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

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

With an output schema present, return values need not be spelled out, yet the description summarizes them anyway. Combined with clear use-case routing, exclusions, and parameter listing, it is nearly complete; only the undocumented rationale parameter is left to the schema alone.

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 restates four of the five parameters with their defaults (page, category, min_score, limit), which duplicates rather than extends the schema; it omits the schema's rationale parameter entirely and adds no new semantics such as what 'similarity' is measured against.

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

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

States a specific verb+resource ('Find pages with similar content') and immediately scopes it with '(potential duplicates or overlaps)'. Explicitly distinguishes itself from the confounding sibling mediawiki_get_related, so an agent can disambiguate without opening the schema.

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

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

Provides a USE WHEN section with concrete user phrasings ('find similar pages', 'are there duplicates', 'what pages overlap with X') and a NOT FOR section naming the alternative tool mediawiki_get_related with its distinguishing condition (link-based relatedness vs content similarity). Both routing conditions are explicit.

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, openWorldHint, and idempotentHint=false, so safety is covered. The description adds useful behavioral context: the directionality of the result set, the default limit of 50, and that redirects are excluded by default, which help an agent predict output scope without opening 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?

Front-loaded with the core purpose, then cleanly sectioned into USE WHEN / NOT FOR / PARAMETERS / RETURNS. Slightly redundant in re-listing parameters and return values that the schema and output schema already carry, but the structure is efficient and scannable.

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 annotations covering the safety profile and an output schema covering return shape, the description supplies everything else an agent needs: purpose, direction, triggers, exclusions, and defaults. Nothing required to invoke it correctly 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 100%, so all five parameters (including rationale) are already documented in the schema. The description's parameter list largely restates the schema's names, required flags, and defaults, adding no format details or semantic nuance beyond it; 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?

States a specific verb and resource ('Get pages that link TO a specific page') and disambiguates direction with the canonical 'What links here' phrasing. It also names the distinguishing sibling concept (incoming vs outgoing links), so an agent can tell it apart from mediawiki_get_external_links immediately.

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

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

Provides explicit USE WHEN triggers with concrete user phrasings ('what links to X', 'which pages reference the API') and a NOT FOR clause that routes the agent to mediawiki_get_external_links for the opposite direction. Both when-to-use and when-not-to-use are covered.

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, openWorldHint=true, idempotentHint=false, covering the safety profile. The description adds the pagination token concept and a default limit, but says nothing about rate limits, auth requirements, or the fact that results are capped. With annotations carrying the safety burden, 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?

Sectioned and front-loaded: purpose, then USE WHEN, NOT FOR, parameters, returns. Efficient, though the PARAMETERS and RETURNS blocks partially duplicate the schema and output schema respectively.

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 an output schema exists, the description need not explain return shapes, and it correctly keeps RETURNS to a single line. Usage routing, param constraints, and scoping are all present for a read-only listing 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 100%, so all five params are documented structurally; the description's PARAMETERS list largely restates them. It adds the 'without Category: prefix' guidance, which actually conflicts slightly with the schema's 'with or without prefix' wording, so there is no net value gain over the schema baseline.

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

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

The first sentence states a specific verb and resource ('Get all pages that belong to a specific category') and is immediately distinguishable from mediawiki_list_categories and mediawiki_get_page. The NOT FOR line explicitly names the sibling it should not be confused with.

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

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

Provides a USE WHEN block with three concrete user-phrasing examples plus an explicit NOT FOR clause naming the alternative tool. An agent has everything needed to route correctly without 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=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered by structured data. The description adds only a restated return summary and no behavioral context such as pagination limits, caching, or why a read operation is marked non-idempotent. With annotations doing the heavy lifting, this is adequate but not additive.

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?

Roughly five short lines, front-loaded with the action, then USE WHEN, NOT FOR, PARAMETERS, and RETURNS in labeled blocks. Every sentence serves routing or scoping; nothing is padding.

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

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

An output schema exists, so the RETURN summary is a bonus rather than a necessity, and the tool is simple with one required parameter. Purpose, triggers, and exclusions are all covered. It falls short of 5 only by omitting the batch variant sibling and any statement about how many links are returned or whether results are truncated.

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 both the title and rationale parameters are already documented in the schema itself. The description's 'title: Page name (required)' adds no format, naming-convention, or alternate-identifier semantics beyond that. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

The first sentence states a specific verb and resource ('Get all external URLs from a wiki page') with clear scope. The NOT FOR block explicitly separates it from mediawiki_get_backlinks (incoming links) and mediawiki_check_links (link validation). An agent can distinguish it from siblings without opening any schema.

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

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

The description gives explicit trigger phrasings ('what external links are on X', 'show outgoing URLs') plus two named alternatives with the conditions that select them. This is exactly the when/when-not/alternatives structure the dimension asks for; the only omission is the batch sibling mediawiki_get_external_links_batch, which is minor.

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 carry the safety profile (readOnlyHint=true, openWorldHint=true, idempotentHint=false), lowering the bar. The description adds useful framing: it explains the batch efficiency trade-off and that results are grouped by source page, which matters for interpreting a multi-page read. It does not explain the idempotentHint=false nuance, so it is strong but not complete.

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

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

Front-loaded with a single summary line, then clearly labeled USE WHEN / NOT FOR / PARAMETERS / RETURNS sections. Each sentence earns its place, with only trivial repetition of the max-10 constraint already in 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 bounded batch-read tool, the definition covers purpose, routing, the key constraint (max 10), and return grouping. With an output schema present and annotations covering safety, nothing an agent needs to invoke this correctly 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 both parameters are already documented, and the description only restates titles (required, max 10) without adding syntax or format guidance. Baseline 3 is correct when the schema does the heavy lifting; the description adds no meaning beyond 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?

States a specific verb and resource ("Batch retrieve external URLs from multiple pages") with explicit scope (multiple pages at once). It immediately distinguishes itself from the single-page sibling mediawiki_get_external_links, 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?

Provides explicit USE WHEN triggers ("get links from these 5 pages") and an explicit NOT FOR exclusion that names the alternative tool for the single-page case. Nothing about when to pick this vs. the sibling 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=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds only a RETURNS summary, which is largely redundant given an output schema exists, and says nothing about pagination or the practical effect of the limit cap. Adequate but not additive.

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

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

Purpose is front-loaded in one line, followed by tightly labeled USE WHEN, PARAMETERS and RETURNS blocks. Every sentence carries information and the sectioning makes it scannable without padding.

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

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

For a read-only, single-resource fetch with an output schema and full annotation coverage, the description supplies purpose, trigger conditions, parameter recap and return summary. Nothing an agent needs to call it correctly 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 100%, so the baseline is 3. The description restates 'title: Page name (required)' and 'limit: Max images (default 50)', both of which are already fully specified in the schema, and it omits the 'max 500' bound and the rationale parameter entirely. No meaning is added beyond 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?

The first line states a specific verb and resource with scope: 'Get all images and files used on a wiki page.' An agent immediately knows what it retrieves. It stops short of a 5 because it never contrasts itself with a sibling (e.g., get_external_links or get_page), so sibling disambiguation is left to the agent.

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 'USE WHEN' block gives three concrete user phrasings ('what images are on X', 'show files used in the article', 'list media on this page'), which clearly anchors the trigger context. It provides no exclusions or named alternatives, so it is clear but not fully 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's added value is the 25KB truncation limit and the format-dependent return behavior, both genuinely useful operational facts. It does not explain the non-obvious idempotentHint=false on what looks like a pure read, nor auth/rate behavior, so it stops short of a 5.

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

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

Roughly five short lines with a labeled USE WHEN / NOT FOR / RETURNS structure; the core action and scope are front-loaded and every sentence carries routing or constraint information. Minor duplication of the format enum against the schema is the only overhead.

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 description need not restate return values, and it still covers the truncation caveat that the output schema alone would not reveal. Routing to resolve_title closes the main failure mode for a title-keyed lookup.

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's PARAMETERS block largely restates the schema (title, format with wikitext default) rather than adding syntax, casing rules, or naming-convention detail for ambiguous titles beyond a pointer to resolve_title.

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?

Opens with a specific verb+resource ('Retrieve full wiki page content') and immediately distinguishes itself from four siblings by name. An agent can route between get_page, get_sections, get_page_info, and search_in_page without opening any 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?

Provides explicit USE WHEN trigger phrasings, explicit NOT FOR exclusions each mapped to the correct alternative, and a failure-path instruction (use mediawiki_resolve_title on title-not-found). This is the full when/when-not/fallback triad.

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/openWorldHint, so the safety profile is covered; the description adds genuinely new context by naming the returned fields and stressing that page content is deliberately excluded (a payload/size consideration). It does not address the unusual idempotentHint=false on a read-only metadata call, which an agent might want explained.

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, front-loaded blocks (purpose, USE WHEN, NOT FOR, RETURNS) with zero filler. Every line earns its place and the most decision-relevant information leads.

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

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

For a simple single-parameter lookup with an output schema, the description covers purpose, exclusions, alternatives, and the shape of the result. An agent has everything needed to select and invoke it correctly without opening the schema.

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 both parameters are already documented in the schema and the baseline is 3. The description restates 'title: Page name (required)' but adds no format, disambiguation, or naming-convention guidance, and it never mentions the optional 'rationale' parameter.

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

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

States a specific verb+resource (get page metadata) and immediately constrains scope with 'without content', which is the key differentiator from mediawiki_get_page. Sibling routing is made explicit by naming mediawiki_get_page and mediawiki_get_revisions in the exclusion clause.

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?

Explicit USE WHEN triggers are given as quoted user phrasings ('when was X last edited', 'who created the FAQ'), and NOT FOR clauses redirect to the correct alternatives with the condition that selects each. Nothing 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=true and openWorldHint=true, covering the safety profile. The description adds useful context beyond that: it is a lighter-weight read that avoids loading the full page, and it enumerates what comes back. The only omission is that idempotentHint=false isn't explained, but that is minor for a read tool.

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

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

Front-loaded one-line purpose followed by clearly labeled USE WHEN, NOT FOR, PARAMETERS, and RETURNS blocks. Every sentence earns its place and the routing constraint precedes the detail.

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 annotations and an output schema present, the description covers purpose, routing, inputs, and expected return content. An agent has everything needed to select and invoke it correctly; the RETURNS summary is a helpful convenience even if the output schema is authoritative.

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% and both parameters are documented there, so the schema carries the semantic load. The description restates the required 'title' parameter but adds no format, disambiguation, or title-resolution guidance beyond the schema, and it never mentions the optional 'rationale' parameter.

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

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

States a specific verb+resource ('Get lead section + key metadata') and immediately scopes it ('without loading the full page'). It explicitly distinguishes itself from siblings mediawiki_get_page and mediawiki_get_sections, so an agent can disambiguate without opening a 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?

Dedicated USE WHEN and NOT FOR sections give explicit triggers ('what is X about', 'quick overview') and name the correct alternatives for the excluded cases (full content → get_page, specific sections → get_sections with section param). Nothing 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: aggregate_by changes the return type to counts instead of raw changes, and the RETURNS section describes the shape (timestamps, users, summaries). It stops short of auth, rate-limit or pagination-behavior disclosure, hence a 4 rather than 5.

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

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

Front-loaded with the purpose, then structured USE WHEN / NOT FOR / PARAMETERS / RETURNS sections. Every sentence earns its place and the routing information comes before the parameter recap.

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 an 8-parameter read tool with an output schema present, all the agent needs is here: purpose, triggers, alternatives and filter semantics. Return values are additionally summarized even though the output schema already carries them.

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 every parameter is already documented in the schema, including defaults, ISO 8601 format and the aggregate_by recommendation. The description largely restates those same parameters without adding syntax or constraints beyond the schema, so baseline 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?

States a specific verb and resource ('Get recent changes across the entire wiki') with explicit scope. It names the sibling tools it is NOT for (mediawiki_get_revisions, mediawiki_get_user_contributions), so an agent can disambiguate without opening any 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?

Provides explicit USE WHEN triggers ('what's been changed recently', 'wiki activity', 'who's been editing') and a NOT FOR section routing to the two correct alternatives. Nothing about when to select this tool 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=true and openWorldHint=true; the description adds genuinely new context beyond them: the method options, defaults, and the shape of the return ('related page titles with relationship type'). It does not explain the idempotentHint=false nuance or result volatility, so it falls short of a 5.

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

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

Front-loaded purpose sentence followed by tight USE WHEN / NOT FOR / PARAMETERS / RETURNS blocks. Every line carries routing or parameter information; 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?

An output schema exists, so return values need not be spelled out, though a brief RETURNS line is provided anyway. Combined with explicit routing guidance, defaults, and method options, an agent has everything needed 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?

Schema description coverage is 100%, so every parameter is already documented in the schema, including the limit max of 50. The description restates title/method/limit defaults but omits the optional 'rationale' audit parameter entirely, adding little beyond the structured fields. Baseline 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?

States a specific verb and resource ('Find pages related to a given page') plus the mechanism ('via links and categories'). This clearly distinguishes it from siblings like mediawiki_get_backlinks or mediawiki_find_similar_pages without opening any 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?

Explicit USE WHEN section with quoted user phrasings, plus an explicit NOT FOR clause naming the alternative (mediawiki_find_similar_pages) and the condition that selects it. Nothing 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=true, openWorldHint=true, and idempotentHint=false, so safety and side-effect profile are covered. The description adds the return payload shape (timestamps, users, sizes, edit summaries), which is useful but duplicated by the output schema, and it says nothing about pagination behavior or the query cost of wide time ranges. Adequate but not rich beyond the structured fields.

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

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

Front-loaded one-line purpose followed by tight USE WHEN / NOT FOR / PARAMETERS / RETURNS blocks. Every line earns its place and the routing rules appear before the parameter list.

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

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

Output schema exists (so return values needn't be re-explained), all six parameters are schema-documented, the sole required parameter is clear, and the when/when-not routing is explicit. An agent has everything needed to select and call this 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?

Schema description coverage is 100%, so the baseline would be 3, but the description actively contradicts the schema: it states 'limit: Max revisions (default 50)' while the schema says default 20, max 100. Misstating a default can cause an agent to size requests incorrectly, which is worse than saying nothing.

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

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

States a specific verb + resource + scope: 'Get revision history for a specific page.' It explicitly names the siblings it must not be confused with (mediawiki_get_recent_changes, mediawiki_compare_revisions), so an agent can discriminate without opening any 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?

Provides concrete trigger phrases under USE WHEN ('who edited the FAQ', 'show edit history of X', 'when was this page last changed') and explicit exclusions under NOT FOR with the correct alternative tool for each case. Nothing 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=true and openWorldHint=true, so the safety profile is carried structurally; the description adds only a RETURNS line. It leaves the idempotentHint=false unexplained (a read that is flagged non-idempotent is worth a note), and says nothing about pagination or size limits. Modest added value over 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?

Front-loaded purpose, then labeled USE WHEN / NOT FOR / PARAMETERS / RETURNS blocks. Every line earns its place with no redundant prose.

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 and annotations covering read-only/open-world behavior, the description need not explain return values, and it correctly focuses on routing. The only gap is the unremarked non-idempotent flag and absent mention of the rationale audit parameter.

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 restates title, section, and format without adding syntax or semantics the schema lacks – the '0 = intro, 1+ = sections' indexing detail lives in the schema, not the description. The rationale param is not mentioned at all, though the schema 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?

States a specific verb and resource ('Get page section structure (TOC) or specific section content') with two clearly delineated modes. It explicitly names the sibling it is not (mediawiki_get_page for full content), so an agent can distinguish it without opening either schema.

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

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

An explicit USE WHEN block gives concrete user phrasings ('what sections does X have', 'show the table of contents', 'get the Installation section'), and a NOT FOR block routes full-page requests to mediawiki_get_page. When-to-use and when-not-to-use are both covered.

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 and openWorldHint=true, so safety profile is covered. The description adds useful context: default threshold of 90 days, sort order (oldest first), and returned fields (days since edit, last editor), which annotations don't convey. It doesn't mention rate limits or auth, but that's a minor gap given annotation coverage.

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

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

Front-loaded purpose sentence, then USE WHEN, NOT FOR, PARAMETERS, and RETURNS sections. Every line is scannable and earns its place; no repetition or 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 list tool with an output schema covering return values, this is nearly complete: purpose, routing, params, and return summary are all present. It omits any mention of the rationale audit parameter and doesn't state pagination behavior, but those are minor given the output schema and annotations.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes slightly beyond by restating parameter meanings and defaults coherently in one block, but adds no syntax or format details not already in the schema. Note: rationale parameter is absent from the description entirely.

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

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

The description states a specific verb+resource+scope: find pages not edited in a specified number of days. It clearly distinguishes itself from siblings by naming both mediawiki_get_recent_changes and mediawiki_find_orphaned_pages as alternatives.

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?

Explicit USE WHEN triggers are given with quoted user phrasings, and NOT FOR exclusions name the exact alternative tools for adjacent use cases. This is textbook routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint=false, so the safety profile is covered structurally. The description adds a RETURNS line and parameter behavior, but since an output schema exists that return summary is largely redundant and the description adds little behavioral context beyond annotations. Adequate, 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?

Front-loaded with the core verb, then clearly labeled USE WHEN / NOT FOR / PARAMETERS / RETURNS sections. No filler sentences; every line carries routing or parameter 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 annotations covering safety, a full input schema, and an output schema handling return values, the description supplies everything else needed: purpose, routing, parameter summary. Nothing an agent needs to invoke correctly 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 100%, so every parameter including start/end semantics and the namespace=-1 sentinel is already documented in the schema. The description restates the params (and omits the rationale param) without adding format or edge-case meaning beyond the schema. Baseline 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?

States a specific verb ('Get') and resource ('all edits made by a specific user'), and explicitly scopes itself against mediawiki_get_revisions and mediawiki_get_recent_changes. An agent can select it without opening any 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?

Provides explicit USE WHEN trigger phrases and an explicit NOT FOR clause naming the two alternative tools for the confusable cases. This is textbook when/when-not/alternatives 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered externally. The description adds nothing behavioral beyond that — no note on caching, freshness, or why an idempotent-looking read is flagged non-idempotent — so it earns only the minimum-plus credit.

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 labeled lines, front-loaded with purpose before usage and return shape; nothing is wasted. The 'PARAMETERS: None' line is slightly redundant against a schema that carries one optional field, keeping it out of 5 territory.

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-required-parameter read tool with full annotation coverage and an output schema, this tells the agent everything needed: what it returns, when to call it, and that it takes no input. Nothing material 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% and the single parameter (rationale) is fully documented in the schema, which sets the baseline at 3. The description's 'PARAMETERS: None' is a mild imprecision since an optional rationale exists, but it adds no meaning beyond 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+resource ('Get information about the wiki itself') and the RETURNS line enumerates the concrete payload (name, version, statistics). The resource is clearly distinct from page-level siblings like mediawiki_get_page_info or mediawiki_get_page_summary, though no sibling is named explicitly.

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

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

The 'USE WHEN' line gives three concrete user phrasings ('what wiki is this', 'wiki statistics', 'MediaWiki version') that map cleanly to this tool. It offers no exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's behavioral additions (pagination token, returned fields) largely duplicate the schema and output schema, so it adds only modest context beyond structured 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?

Front-loaded with the core action, then clearly sectioned into USE WHEN / NOT FOR / PARAMETERS / RETURNS. The PARAMETERS block is redundant against a fully-covered schema, but the overall length is proportionate.

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 description needn't explain return values, and it correctly stays brief on that front while covering usage and routing. Nothing an agent needs to invoke this correctly appears to be 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 100%, so the schema already documents limit, prefix, continue_from and rationale. The PARAMETERS section restates the same facts (default 50, pagination token) without adding syntax, format, or interaction details.

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

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

States a specific verb and resource ('List all categories in the wiki') and explicitly names the sibling it is not for (mediawiki_get_category_members). An agent can distinguish this from mediawiki_list_pages and mediawiki_manage_categories without opening any 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?

Provides an explicit USE WHEN block with quoted user phrasings and a NOT FOR clause that routes to the correct alternative. Both the when and the when-not conditions are stated outright.

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 and openWorldHint=true, so safety profile is covered. The description adds only that continue_from is a 'pagination token from previous response', which is useful but duplicated in the schema. It does not explain why idempotentHint=false for a read operation (enumeration may change between calls) or any rate/size behavior beyond the default limit.

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?

Well front-loaded: the one-line purpose comes first, then WHEN/NOT-FOR routing, then params and returns. The PARAMETERS and RETURNS sections are partly redundant with the input schema and output schema, which costs it a point, but the layout is scannable and free of filler prose.

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?

Since an output schema exists, the brief RETURNS line is a bonus rather than a requirement, and the routing guidance is complete for a listing tool. Minor gaps: no note on namespace id range/semantics or that large listings should be paged, though continue_from and the default limit are surfaced.

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 PARAMETERS block largely restates the schema (prefix, namespace, limit, continue_from) and omits actual schema detail such as 'max 500' and the namespace examples (0=main, 1=talk). No added semantics beyond what the schema already 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 a specific verb+resource (list wiki pages) with the scoping modifier (optional prefix filter), and explicitly disambiguates from the closest sibling: 'NOT FOR: Finding pages by content (use mediawiki_search).' An agent can distinguish this from the ~40 sibling tools without opening a schema.

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

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

Gives concrete USE WHEN trigger phrases ('list all pages', 'show pages starting with API') plus an explicit NOT FOR with the named alternative (mediawiki_search). Both the positive and negative routing conditions are covered.

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, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description supplements this with pagination behavior (continue_from token) and the return fields, but says nothing about rate limits, auth requirements, or the meaning of idempotentHint=false for retries.

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?

Header-based sections (USE WHEN / PARAMETERS / RETURNS) front-load the trigger conditions and keep each item short. There is mild duplication of schema and output-schema content, but no wasted prose.

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 RETURNS line is redundant but harmless; the description covers trigger, parameters, pagination and defaults well. It is slightly incomplete on the rationale/audit parameter and on openWorld implications, which the description never addresses.

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%, and the PARAMETERS block largely restates it (group values, active_only default, limit default, continue token). It adds the parenthetical '(admins)' for sysop, but omits the rationale parameter entirely, so it neither compensates nor adds much beyond the schema baseline.

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 wiki users') and adds the scoping modifier ('optional group filtering'), which distinguishes it from the user-contribution and page-listing siblings. An agent can identify it without opening the schema.

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

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

The 'USE WHEN' block gives three concrete trigger phrasings ('who are the admins', 'list all users', 'show active editors') that map cleanly to the group/active_only parameters. It does not name an explicit alternative or exclusion (e.g. vs. get_user_contributions), so it stops short of a 5.

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

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

Discloses beyond the annotations: that preview defaults to true for safety, that authentication (bot password) is required to apply, and that anonymous sessions cannot edit. Annotations cover the safety profile (destructiveHint true, idempotentHint false); the description adds the auth requirement and the default-preview behavior, which the agent needs to invoke correctly.

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

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

Front-loaded with the core action, then structured USE WHEN / NOT FOR / NOTE blocks. Slightly dense with the RETURNS and NOTE sections, but each carries an agent-relevant fact.

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?

Complete for a mutation tool: states the when/when-not, auth requirements, the safe default behavior for preview, and what gets returned (added/removed/already present/not found). Output schema exists, yet the description still gives the agent enough to decide and call correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds the 'without Category: prefix' convention and emphasizes the preview default and its rationale, plus notes the required rationale parameter's audit purpose. Marginal but genuine value beyond 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?

Specific verb+resource ('Add or remove categories from a page') with an explicit scoping qualifier ('without editing the full content') that distinguishes it from the sibling mediawiki_edit_page. Clearly names the resource and the 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?

Provides explicit USE WHEN triggers with user phrasings and a NOT FOR section that names two alternative siblings (mediawiki_list_categories, mediawiki_get_category_members) with their distinct purposes. Routing is 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?

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds substantive context beyond them: the default redirect creation, the required authentication (bot password) and move permissions, and that the result includes revision ID, diff URL and undo instructions. This is exactly the extra behavioral detail the annotations cannot carry.

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

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

Front-loaded with the core action, then cleanly sectioned into USE WHEN / NOT FOR / PARAMETERS / RETURNS / WARNING. Every line adds an actionable fact 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 destructive, auth-gated mutation tool the definition covers side effects, permissions, defaults, alternatives and return shape; with an output schema present it does not need to enumerate return fields. An agent has everything needed 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?

Schema description coverage is 100%, so the schema already documents every parameter including defaults, making the PARAMETERS list largely redundant (baseline 3). The description also omits the required 'rationale' parameter entirely, a small gap against the schema's audit-log intent field.

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

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

States a specific verb+resource ('Move (rename) a wiki page') and immediately clarifies the side effect ('Creates a redirect from the old title'). The NOT FOR clause routes the agent to the correct siblings for content edits, so it is distinguishable from mediawiki_edit_page without opening any 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?

An explicit USE WHEN block gives triggering user phrases, and a NOT FOR block names alternatives (mediawiki_edit_page, mediawiki_find_replace) with the condition that selects them. Nothing 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=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds that output is rendered HTML, but since an output schema exists this is largely redundant, and it does not explain the non-idempotent behavior (template/parser-dependent output) that the annotation flags.

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 USE WHEN / PARAMETERS / RETURNS sections are front-loaded and easy to scan, with one line each. The RETURNS line duplicates an existing output schema, which is the only real waste.

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

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

Given one required param, 100% schema coverage, and an output schema in place, the description covers purpose, usage, parameters, and return type adequately. It is complete for a parsing tool, with only the non-idempotent behavior left undescribed.

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 restates both parameters but adds only a marginal gloss ('title: context page title for link resolution') that is slightly inconsistent with the schema wording ('affects template expansion').

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

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

States a specific verb+resource+output: 'Parse wikitext and return rendered HTML.' This clearly separates it from conversion siblings like mediawiki_convert_markdown or mediawiki_apply_formatting, which transform rather than render. It stops short of naming a sibling explicitly, so it lands at 4 rather than 5.

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

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

The 'USE WHEN: preview wikitext rendering, test markup syntax' line gives concrete, actionable context for selecting this tool. However, it offers no when-not guidance and no named alternative for related tasks (e.g. rendering vs converting), so it stays at 4.

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