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

With no annotations, the description carries the full behavioral burden for a mutation tool. It discloses the auth requirement, but says nothing about title-collision behavior (error vs overwrite), whether the edit summary is logged, required permissions, or whether the creation is immediately visible — all material for a write operation.

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

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

Two short sentences with the action front-loaded and zero wasted words. The brevity is efficient, though it borders on under-specification for a mutation 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?

An output schema exists, so return values need not be described. However, for a create operation with no annotations, the description omits collision handling, permission scope, and side effects — gaps that leave an agent unable to predict behavior before writing.

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%, with title, content, and summary each documented including the default. The description adds no meaning beyond that, so the baseline 3 applies; notably it does not clarify that content must be wikitext (that lives only in the schema).

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

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

"Create a new wiki page" is a specific verb plus resource, clearly distinct from read-side siblings like get_page_tool. It never explicitly contrasts with edit_page_tool, which is the nearest alternative for existing pages, so it falls short of full sibling differentiation.

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

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

No guidance on when to use this versus edit_page_tool, or what to do if the page already exists. The only condition given is "Requires authentication," which is a prerequisite rather than a usage rule.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the admin-auth requirement, but for a destructive mutation it says nothing about irreversibility, side effects, whether the page is recoverable, or what happens to related 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?

Two short sentences, front-loaded with the core action and followed by the key access constraint. There is no wasted language.

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 is simple and the input schema is fully documented, plus an output schema exists. However, because this is a destructive operation with no annotations, the description should say more about irreversibility, scope of deletion, and recovery behavior.

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 input schema. The description adds no parameter-level meaning beyond that, which is the baseline expectation when the schema is complete.

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

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

The description gives a specific verb and resource: "Delete a wiki page." That clearly separates it from create, edit, move, and read page tools. It does not explicitly name a sibling alternative, but the purpose is unambiguous.

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

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

The only guidance is "Requires admin authentication," which is a prerequisite rather than a when-to-use rule. It does not explain when deletion is appropriate, when to prefer archive/edit, or any conditions that should make an agent pause.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the authentication requirement, which is useful, but says nothing about whether content fully replaces existing wikitext, what happens on a missing page or edit conflict, or whether minor edits suppress notifications.

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

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

Two short sentences with no filler and the core purpose front-loaded. The auth prerequisite is placed second, which is reasonable, though the description is arguably too terse rather than wasteful.

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 write operation with zero annotation coverage, the description is thin: it omits overwrite semantics, conflict handling, and failure modes. An output schema exists so return values needn't be explained, but the behavioral contract for editing is largely 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% with clear per-field descriptions for title, content, summary, and minor, so the baseline is 3. The description adds no extra meaning about how these parameters interact or what defaults imply.

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 ("Edit an existing wiki page"), and the word "existing" correctly frames it as a mutation of an already-present page rather than creation. It does not explicitly name siblings like create_page_tool or delete_page_tool, but the name and phrasing make the distinction fairly evident.

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

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

No indication of when to use this versus create_page_tool or move_page_tool, no prerequisites beyond "Requires authentication," and no note that the target page must already exist. The agent must infer all routing decisions.

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

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

The readOnlyHint annotation already establishes this is a safe read. Beyond that, the description adds nothing: it does not mention that results are paginated via a continue token, that limit caps at 500, or that members can be filtered by type. For a tool with 100% annotation coverage of only readOnly, the description should carry more behavioral weight.

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

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

A single front-loaded sentence with zero waste. However, the terseness is close to under-specification rather than disciplined conciseness.

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

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

An output schema exists, so return-value explanation is not required, and the input schema is fully described. What is missing is the operational context an agent needs: how category membership relates to subcats/files, and how paging works in practice.

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 (limit, category, member_type, continue_from) are already fully documented in the schema. The description adds no parameter-level meaning, which is acceptable given the high coverage 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 clear verb ('Get') and resource ('pages in a category'), which is unambiguous about what the tool returns. It does not distinguish itself from siblings like get_page_categories_tool (the inverse direction) or search_tool, leaving that inference 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?

There is no guidance on when to use this versus list_pages_tool, search_tool, or get_page_categories_tool (which maps page to categories rather than categories to pages). The agent must infer the selection criteria entirely from tool names.

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

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

readOnlyHint=true already declares the safe-read profile, and an output schema exists, so the safety and return-value burden is covered elsewhere. The description adds essentially nothing beyond structured fields — no note on which metadata fields are returned, whether missing filenames error out, or how namespaces/redirects are handled.

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

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

One short sentence, resource-first, with zero filler. Nothing in the sentence fails to earn its place.

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

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

For a single-parameter read tool with annotations and an output schema, the description tells an agent enough to call it correctly. The only meaningful omission is the lookup-vs-list decision relative to list_files_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 coverage is 100% and the single parameter is documented (including the optional "File:" prefix handling), so the schema does the heavy lifting. The description contributes no additional filename syntax or resolution semantics; 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 (file/image metadata) scoped to the wiki, which is clearly distinct from sibling list_files_tool (enumerating files) and get_page_tool (page content). It stops short of explicitly naming an alternative, but the resource itself disambiguates well.

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

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

There is no guidance on when to reach for this versus list_files_tool (to find a filename) or get_page_tool (for page content). The only usage signal is implicit in the resource name, which is the same deficiency the MID calibration example was penalized for.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds no behavioral context beyond it — nothing about whether results are paginated, ordered, truncated by limit, or what happens for a missing page. For a simple read this is acceptable but adds no value over the structured metadata.

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

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

A single short sentence, front-loaded with the verb and the scope constraint. Efficient, though its brevity borders on underspecification rather than crispness.

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

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

An output schema exists so return values need not be described, and the schema fully documents the inputs. Still, for a lookup keyed on page title there is no note on title normalization or failure behavior, leaving a small but real gap.

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

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

All three parameters are fully documented in the schema, including defaults and the max for limit and the show_hidden default, so the description needs no compensation. It adds nothing about the title parameter's resolution (exact vs. normalized title), but baseline 3 applies at 100% coverage.

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

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

The description states a specific verb and resource: 'Get categories that a page belongs to,' which is more precise than the name alone and clearly scopes the result to a single page. It implicitly differentiates from siblings like list_categories_tool (all categories) and get_category_members_tool (members of a category), though it never names them.

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

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

Usage is only implied by the scoping phrase 'that a page belongs to.' No explicit when-to-use guidance, no exclusions, and no mention of the obvious alternative (list_categories_tool) for the reverse lookup direction, leaving the agent to infer the split.

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

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

The only annotation is `readOnlyHint: true`, which the description does not contradict, but the description adds no behavioral context beyond the name—such as error behavior for missing pages, whether parsing includes templates or macros, or any rate limits. With annotations covering only the safety profile, the description should do more to differentiate this transformation from raw page retrieval.

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

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

The description is a single, front-loaded sentence with no wasted words. It is efficiently sized for a simple tool, though the extreme brevity means it omits useful context rather than being optimally structured for decision-making.

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 is low-complexity, has a complete input schema, and includes an output schema, so the description need not explain return values. However, it omits critical routing information—especially how this differs from `parse_wikitext_tool`—which is necessary for an agent to use it correctly in context.

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

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

Schema description coverage is 100%: the single `title` parameter is fully documented in the schema as 'Page title to parse.' The description adds no additional meaning about format, allowed values, or behavior beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Parse') and resource ('wiki page') with a clear output format ('HTML'), so an agent knows the general operation. However, it does not distinguish this from the closely related sibling tools `get_page_tool` and `parse_wikitext_tool`, leaving ambiguity about which tool to select.

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

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

The description provides no guidance on when to use this tool versus alternatives such as `parse_wikitext_tool` or `get_page_tool`. It does not state prerequisites, exclusions, or contextual conditions for selection.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the payload is wikitext rather than rendered HTML, which is useful, but says nothing about missing-page behavior, redirects, or page-size limits.

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

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

One short, front-loaded sentence with no filler. It is efficient, though bordering on under-specified rather than optimally concise.

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

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

An output schema exists so return shape needn't be explained, and the single parameter is fully documented. However, for a lookup tool the description omits the edge cases an agent needs (nonexistent title, redirects), leaving a modest gap.

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

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

Schema coverage is 100% and the single 'title' parameter is documented with an example in the schema. The description adds only the retrieval key restatement, 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+resource ('Get page wikitext content') and the retrieval key ('by title'). The word 'wikitext' implicitly distinguishes it from get_page_html_tool, 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?

Usage is implied by the resource name, but the description never says when to prefer this over get_page_html_tool, search_tool, or list_pages_tool, nor what happens for missing pages. Adequate but leaves routing to inference.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description needn't restate that. It adds the useful fact that the payload covers configuration and version, but says nothing about whether the result is cached, permissions-gated, or costly.

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

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

A single short sentence with no filler, and the resource (wiki configuration/version) is stated up front. Nothing to trim.

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

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

An output schema exists, so return values need not be described. For a zero-parameter, read-only info tool the description plus annotations plus output schema cover what an agent needs; only the meaning of 'configuration' is left slightly open.

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

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

The tool takes no parameters, so the baseline for this dimension is 4. Nothing in the description conflicts with the empty 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 concrete verb ('Get') and resource ('wiki configuration and version info'), which distinguishes it from the other info tools in the sibling set (get_user_info_tool, get_file_info_tool). The scope is clear, though it doesn't explicitly say what 'configuration' comprises.

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

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

Usage is only implied: an agent can infer this is the tool for checking wiki version or config, but there is no explicit 'use when' statement and no mention of alternatives or prerequisites. With no parameters there is little that could go wrong, which keeps this at a minimum-viable 3.

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

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

The readOnlyHint annotation already tells the agent this is a safe read. The description adds nothing beyond that — no mention of what happens when the username does not exist, whether the lookup is exact-match or fuzzy, or any rate/permission considerations.

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

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

A single short sentence with zero padding and the core action front-loaded. It is efficient, though the terseness comes at the cost of specification rather than being an example of tight completeness.

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 is simple, annotations cover the read-only safety profile, and an output schema exists so return values need not be described. Still, for a lookup tool nothing is said about missing-user behavior or the exact-match nature of the username, leaving a modest gap.

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

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

Schema coverage is 100% with a single well-documented 'username' parameter, so the schema does the heavy lifting. The description adds no extra meaning such as case sensitivity, exact-match requirements, or accepted formats, which is the expected baseline of 3.

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 user details from the wiki'), so an agent knows it retrieves information about a wiki user. It does not differentiate itself from nearby siblings such as list_user_contributions_tool or get_site_info_tool, and 'details' remains vague about what fields are returned.

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

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

There is no guidance on when to use this tool versus alternatives like list_user_contributions_tool, nor any stated prerequisites. The agent must infer usage entirely from the name.

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?

readOnlyHint=true already declares this is a safe read, so the description adds almost nothing beyond annotations. Worse, 'List ALL categories' is mildly misleading given the schema's default limit of 50 and pagination parameters, which imply results are truncated – a caveat the description should call out.

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

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

One short, front-loaded sentence with zero waste. Its brevity stems from under-specification rather than elegant compression, but nothing needs cutting.

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, readOnly annotations, and full parameter documentation, the essentials are covered externally. However, for a tool sitting among several similarly named category/page readers, the description should at minimum mention pagination behavior and how it differs from get_category_members_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 limit, prefix, and from_name are all fully documented in the schema. The description adds no semantics of its own, which is the correct baseline 3 when the schema does all the work.

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

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

The description gives a clear verb and resource ('List all categories'), which is enough to tell it apart from sibling readers like get_category_members_tool or list_namespaces_tool by name alone. It stops short of explicitly contrasting itself with those siblings, so it lands just below a 5.

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

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

There is no guidance on when to use this versus get_category_members_tool (members of one category) or get_page_categories_tool (categories of one page) – a distinction an agent could easily get wrong. No prerequisites or exclusions are stated.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description should add context such as ordering, pagination behavior, or what a file entry contains. It adds nothing beyond the annotations and the tool name.

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

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

The single sentence is front-loaded and waste-free, but it is under-specified rather than appropriately sized for a tool with pagination and filtering options. Brevity here reflects missing content, not efficiency.

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 and the schema documents all parameters, so the essentials are covered. However, with four params including a pagination cursor, the description should at least signal ordering and how from_name relates to limit; that context 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?

All four parameters have full schema descriptions (limit, prefix, from_name pagination, mime_type), so the schema carries parameter semantics completely. The description contributes no additional meaning, which is the baseline 3 case at 100% coverage.

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

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

The description states a specific verb and resource ("List files") on the wiki, which is clear enough in isolation. But it does not distinguish this from sibling list tools such as list_pages_tool, list_categories_tool, or get_file_info_tool, leaving the agent to infer the boundary between listing files and listing other resources.

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

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

There is no guidance on when to use this tool rather than get_file_info_tool or list_pages_tool, and no mention of preconditions or exclusions. The only usage hints (prefix, mime_type filtering, pagination) live in the schema, not the description.

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?

readOnlyHint=true already declares the safety profile, so the description carries a lighter burden, and "all namespaces on the wiki" does add scope context (wiki-wide, unfiltered). Beyond that it adds nothing — no note on whether results are paginated, ordered, or whether the namespace set is small/fixed — which is a modest but real gap for an enumeration tool.

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

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

A single short sentence, front-loaded with the verb and with zero filler. It is on the terse side rather than wasteful, which costs it nothing on conciseness but leaves no room for the usage/behavioral detail noted above.

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

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

For a zero-parameter, read-only enumeration tool with an output schema present, the description covers the essential question of scope (all namespaces, wiki-wide). Return shape need not be explained given the output schema, so nothing critical is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for 0 params is 4. The description correctly implies no filtering or paging arguments exist.

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?

"List all namespaces on the wiki" gives a specific verb (list) and a specific resource (namespaces), which is unmistakably distinct from siblings such as list_pages_tool, list_categories_tool, and list_files_tool. It does not explicitly name or contrast with any sibling, but the resource noun alone is enough to disambiguate.

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

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

Usage is only implied: an agent can infer this is the tool for enumerating namespaces, and the absence of any parameters means there is little to get wrong. However, the description never states when to prefer it (e.g., before calling a namespace-scoped tool) or that it is the only namespace-listing option.

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

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

Annotations already declare readOnlyHint=true, so safety is covered structurally, but the description adds nothing beyond that - no mention of result ordering, pagination behavior via from_title, or the default/max limit. With an annotation present the bar is lower, yet the description contributes essentially zero behavioral context of its own.

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

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

A single compact sentence with zero filler, and the core action is front-loaded. Nothing is redundant or padded relative to what it says.

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 and all parameters are schema-documented, so the basics are covered. But for a listing tool with a pagination parameter and overlapping siblings, the description omits the distinction from search_tool and any pagination/ordering note, leaving a small but real gap given the sibling landscape.

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 (limit, prefix, namespace, from_title) are already documented with defaults and semantics. The description only restates the prefix filter and adds no syntax, interaction, or edge-case detail beyond the schema, making the baseline 3 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 (list) and resource (wiki pages) plus a qualifier (optional prefix filter), so the agent instantly knows the operation. However, it does not differentiate from siblings like search_tool, get_page_tool, or list_recent_changes_tool, which overlap in retrieving page collections.

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

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

Usage is only implied: 'List wiki pages' suggests enumeration, and 'optional prefix filter' hints at prefix-scoped listing. There is no explicit when-to-use guidance (e.g., use instead of search_tool when you need a full or prefix-scoped enumeration), and no mention of when not to use it.

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

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

The readOnlyHint annotation already establishes this as a safe read operation. The description adds only 'recent edits' without defining recency, ordering, pagination behavior, or any rate/limit context, so it contributes very little beyond the annotation.

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

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

A single front-loaded sentence with no filler. It is efficiently sized, though its brevity reflects under-specification rather than deliberate minimization.

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, a full output schema, and complete parameter descriptions, the structured fields carry most of the burden. Still, the description does not clarify recency scope or sibling-tool selection, leaving gaps for an agent deciding between this and related list/search tools.

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 all five optional parameters are documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description gives a specific verb ('List') and resource ('recent edits on the wiki'), so the tool's basic purpose is clear. It does not, however, distinguish this from siblings like list_user_contributions_tool or search_tool, leaving the agent to infer the difference.

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

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

There is no guidance on when to use this tool versus searching, listing a user's contributions, or fetching page history. No alternatives or exclusions are named, so the agent must guess at the appropriate context.

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

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

readOnlyHint=true already establishes this as a safe read, so the description's only job is to add context such as ordering, pagination, or the shape of the contribution feed. It adds none of that, leaving the behavioral picture entirely to the annotations and output schema.

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

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

A single front-loaded sentence with zero padding. It is efficient, though the terseness borders on under-specification rather than optimal brevity.

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 4 parameters, an output schema, and readOnly annotations, the description only needs to explain scope and routing, and it half does. It never clarifies whether results are chronological, whether it covers all namespaces by default, or how it differs from other activity-listing siblings.

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 username, limit, namespace, and from_timestamp are all documented in the schema itself. The description contributes no additional meaning about how those filters interact, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List edits by a user'), which is enough for an agent to know this returns a user's contribution history rather than site-wide activity. It does not differentiate itself from list_recent_changes_tool or get_user_info_tool, which are the most likely confusions.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling list_recent_changes_tool that also surfaces edit activity. Usage is only inferable from the name-plus-one-sentence.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it only discloses the auth requirement. For a mutation tool it omits what an agent most needs: that a redirect is left behind by default (no_redirect=false), that the talk page is moved by default, and that history/links are affected by the rename.

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

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

Two short sentences with zero filler and the core action is front-loaded. The brevity is efficient but edges toward under-specification given the tool mutates page identity.

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 explanation is not required, but for a 5-parameter mutating tool with no annotations the description is thin: it never mentions redirect creation, talk-page handling, or failure conditions such as title collisions.

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 defaults is already documented in the schema; the description adds no parameter-level meaning. A baseline 3 is appropriate, though a note that to_title must not collide with an existing page would have earned more.

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 ('Move (rename) a wiki page') and usefully disambiguates that move means rename, which an agent could otherwise misread as a file-system move. It does not distinguish itself from siblings like edit_page_tool or delete_page_tool, which a Wiki-API-literate agent must infer.

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

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

There is no guidance on when to use this versus editing a page title or creating a new page under a different title, nor on preconditions such as page existence or conflicting target titles. The only stated condition is 'Requires authentication', which is a prerequisite, not usage guidance.

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

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

The readOnlyHint=true annotation already establishes that this is a non-mutating operation, so the description's only obligation is to add context — template resolution behavior, how the optional title affects output, or what happens with malformed wikitext. It adds none of that; the entire description just restates the operation. The one useful detail (title for template resolution) lives only in 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?

A single terse sentence with no waste, and the operation/transformation is front-loaded. It is arguably too terse rather than bloated, which is penalized in contextual completeness rather than here.

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 no explanation, and the input schema fully documents both parameters. However, a wikitext parser has real behavioral subtleties (template/module expansion, dependence on title, error handling on invalid markup) that go unmentioned, leaving the definition only minimally adequate.

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

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

Schema description coverage is 100%, with both parameters documented inline, including the optional title's role in template resolution. The description contributes nothing beyond the schema, 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 (parse) and the exact transformation (raw wikitext to HTML), which is unambiguous about what comes in and what comes out. It does not distinguish itself from the sibling get_page_html_tool, which also yields HTML, so an agent can't be fully certain from the description alone which one to reach for.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the sibling alternatives such as get_page_html_tool or get_page_tool. The agent must infer the use case purely from the verb.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds nothing beyond that — no ranking behavior, result shape, or pagination/limit interaction context. With an output schema present the return format needn't be spelled out, but 'full-text' semantics (matching, scoring) are left entirely opaque.

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

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

One front-loaded sentence with zero waste. It is efficient but borders on under-specified rather than maximal conciseness; a short clause on scope would still earn its place.

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

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

For a 3-parameter read-only tool with a full output schema, the safety and parameter burden is carried by structured fields. What remains missing is the routing decision among many sibling listing/search tools, which is the one thing the description should have supplied.

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% with clear descriptions for limit, query, and namespace, so baseline is 3. The description adds no extra meaning — e.g., what namespace scope means for search reach or how limit interacts with ranking — beyond what the schema already says.

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 ('Full-text search') and resource ('across the wiki'), which is enough to distinguish a search operation from get_page_tool or list_pages_tool. It stops short of explicitly contrasting with those siblings, so it lands at 4.

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

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

There is no guidance on when to search versus browsing with list_pages_tool or list_recent_changes_tool, and no mention of when results are or aren't appropriate. The single sentence implies lookup usage but excludes nothing.

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