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

The description adds context beyond annotations by explaining the registration process, resource URI pattern, and failure conditions. It does not describe network calls or auth requirements, but annotations already provide read/write and idempotency hints.

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

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

Two sentences succinctly convey purpose, mechanism, and failure conditions. No wasted words, front-loaded with the verb 'Registers'.

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 registration tool with one parameter, the description covers key aspects. Lack of output schema is compensated by explaining the resulting resource URI. Minor: no mention of return format or side effects.

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

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

Schema coverage is 100%, so the description does not need to add much. It reinforces the parameter purpose but does not add new meaning beyond the schema's 'Any URL from the target wiki'.

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

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

The description clearly specifies the tool's function: registering a new wiki by fetching its sitename and API configuration from any URL. It distinguishes itself from siblings like 'remove-wiki' and 'list-wikis' by focusing on addition.

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 states when to use (register a wiki) and conditions for failure (non-MediaWiki URL, duplicate key). However, it does not explicitly mention when not to use or compare with alternatives.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses concrete behavioral details: diff output truncates at 75,000 bytes with a completion marker, nonexistent titles/revision IDs produce errors, and includeDiff=false changes the response to just a change flag, revision metadata, and size delta. These details are not present in annotations and materially affect how an agent should call the 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?

Four dense sentences, each carrying a distinct piece of information: core result, side types and constraints, alternative, and truncation/mode behavior. The most important information is front-loaded and there is 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?

The tool has 8 parameters, no output schema, and no required fields, yet the description covers accepted input forms, invalid combinations, error behavior, response size limits, and the alternative response mode. It also points to get-page for full text, making the description sufficient for correct invocation even without an output 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?

With 100% schema coverage, the schema already documents each parameter, so the baseline is 3. The description adds combinatorial semantics by explaining that each side can be specified as revision ID, page title, or wikitext but text-vs-text is invalid, and clarifies the behavioral impact of includeDiff=false. This elevates it above schema-only documentation.

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 opening sentence names the exact operation (returns changes between two versions) and resource (wiki page), and qualifies it as a 'compact text diff'. It also distinguishes itself from get-page by noting that only changes are transmitted, so an agent can select it over the full-text sibling.

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

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

It explicitly routes agents needing full text to get-page instead, and outlines when to switch includeDiff=false for a cheap change-detection request. It also states an important exclusion (text-vs-text is rejected) and gives guidance on avoiding truncation via a narrower revision range or includeDiff=false.

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

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

The description adds meaningful operational behavior beyond the annotations: it discloses that the call fails on duplicate titles, describes the returned identifiers, explains the contentModel fallback to namespace default, and suggests chunked appends for large content. The annotations already cover readOnly, destructive, and idempotent hints, and the description does not contradict them.

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 four sentences, each carrying distinct information: action and return values, duplicate failure and alternative, contentModel semantics, and large-page chaining. It is compact and front-loaded with the core outcome, though slightly longer than strictly necessary.

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

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

Despite the absence of an output schema, the description specifies the returned fields and the key error condition. With full parameter documentation in the schema and the explicit pointer to update-page for existing pages and large-content workflows, the description gives an agent everything needed to invoke 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?

With 100% schema description coverage, the baseline is 3, but the description adds useful meaning to contentModel by giving examples ('javascript, css') and clarifying the namespace-default behavior. It also ties source to the contentModel format, which slightly exceeds what the schema alone states.

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

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

The description opens with a specific verb-object pair ('Creates a new wiki page') and immediately states the return values: title, page ID, and first revision ID. It also distinguishes itself from the sibling tool by saying 'for existing pages, use update-page', so an agent can tell this apart from update-page, move-page, delete-page, or undelete-page.

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

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

The description explicitly states when not to use the tool: 'Fails if a page with the given title already exists; for existing pages, use update-page.' It also gives a concrete pattern for large pages by pairing create-page with chained update-page(operation='append') calls, providing clear guidance on when and how to use it versus alternatives.

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

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

Beyond annotations (destructiveHint, idempotentHint, readOnlyHint), description adds soft delete behavior, retention of history, restoration via undelete-page, and admin purge. It also notes permission requirements and failure conditions.

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

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

Two sentences, front-loaded with the primary action, and every sentence adds value. No unnecessary words.

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 good schema and annotations, description covers soft delete, restoration, failure conditions, and return value. No output schema is needed since the return is simply stated.

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. Description does not add additional meaning beyond the schema; it only mentions returning the deleted title, which is output behavior.

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?

Clearly states the tool removes a wiki page from public view and returns the deleted title. The verb 'Removes' and resource 'wiki page' are explicit. The description distinguishes from sibling 'undelete-page' by mentioning restoration capability.

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 clear context that it's a soft delete and indicates failure conditions (page not exist, lacking permission). However, it does not explicitly mention when to use alternatives, such as for deletion vs. moving or updating.

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?

Adds value beyond annotations by noting the 500-member cap, pagination with continueFrom, and that member type is omitted for ordinary pages. Annotations already indicate read-only/idempotent.

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 moderately sized and front-loaded with the main purpose. It packs filtering and pagination info efficiently, though could be slightly more 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?

Given no output schema, the description adequately covers returned fields, behavior (type omission), filtering, and pagination. Lacks error details, but not a major gap for this 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%, so baseline is 3. Description clarifies the types enum (page, file, subcat) and explains the opaque cursor and category prefix handling, adding modest 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 clearly states it lists members of a category, specifying returned fields (page ID, namespace ID, wiki page title). It distinguishes from sibling tools like get-page, search-page, etc., which operate on pages or search, not category membership.

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 guidance on optional filters (by member type or namespace ID) and pagination with continueFrom. Does not explicitly mention when not to use or compare to alternatives, but the context of siblings makes it clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds behavioral detail: automatic 'File:' prefix addition. No contradictions. Does not cover rate limits or error behavior, but reasonable given annotations.

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

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

Two sentences, front-loaded with primary functionality. Second sentence adds a useful caveat. No wasted words.

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 two parameters, rich annotations, and no output schema, the description adequately covers functionality. It could mention error handling for missing files, but overall sufficient for selection and invocation.

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

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

Schema coverage is 100% with descriptions. Description adds extra context: auto-prefix for title parameter and clarification of wiki parameter as a key from mcp://wikis/ resources. This adds 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?

Description clearly states it returns metadata and download URLs for a file. Specifies the resource (file) and verb (returns). Distinguishes from sibling get-file-data by including download URLs and auto-prefix behavior.

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 clear context on what the tool does but no explicit guidance on when to use it over alternatives, such as get-file-data. No when-not-to-use or exclusions.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds key behavioral details: returns scaled rendition based on width, errors for non-rasterizable file types, clamp on width above 1568, and format option affecting token cost. No contradictions with annotations.

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

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

The description is concise but comprehensive, front-loading the core purpose, then detailing behavior and alternatives. Every sentence adds value without redundancy.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description covers purpose, use cases, return format (inline content block), error conditions, and alternatives. No gaps identified.

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 descriptions for all 4 parameters. The description adds extra context for width (quality knob, defaults, clamping) and format (image vs text, token implications), providing 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?

The description clearly states the tool fetches a wiki file server-side and returns the image inline as a content block, specifically for sandboxed clients needing visual analysis. It also distinguishes from the sibling get-file by noting it errors for non-rasterizable files and directing users to get-file for those cases.

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 explicitly explains when to use this tool (for image delivery to model when client cannot reach wiki host) and when not to (for audio, video, binaries, metadata, or download URL), providing the alternative tool get-file.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details like pagination limit (500) and redirect behavior. No contradictions. Slight room for more on open world implications.

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 efficient and front-loaded. Key purpose first, then parameter behavior, then sibling alternatives. Every sentence adds value, no wasted words.

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

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

For a tool with 8 parameters and no output schema, the description covers core behavior, parameter usage, pagination, and differentiation from siblings. It provides sufficient information for correct invocation.

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

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

Schema coverage is 100%, but description adds context beyond schema, like 'one relationship per call' for type and 'also return the pages that link through it' for expandRedirects. Improves understanding without redundancy.

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

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

The description clearly states it 'Lists pages that reference a target wiki page' with specific verb and resource. It details the returned fields and distinguishes from siblings by mentioning alternatives for category members and full-text search.

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 explicitly states when not to use it: 'For members of a category, use get-category-members; for full-text content search, use search-page.' It also explains when to use different 'type' values and pagination with continueFrom.

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

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

Annotations already indicate read-only and idempotent behavior, but the description adds significant behavioral detail: error on nonexistent title, truncation at 75000 bytes with a marker, and the ability to narrow to a section. This exceeds the annotation information without contradiction.

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

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

The description is detailed but efficiently organized: it leads with the core function, then explains parameters and alternatives in logical order. Every sentence adds useful information for the agent, with no meaningless fluff.

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 tool's complexity (multiple content types, metadata, truncation, sections, and sibling alternatives), the description covers all essential aspects: error behavior, truncation mechanics, follow-up calls, and when to use sibling tools. There is no output schema, but the description gives enough information about what the agent will receive.

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 descriptions cover all 5 parameters, but the description adds valuable semantic context: explains that metadata=true retrieves revision ID for edit-conflict detection, page size, and section outline; content='none' fetches only metadata; section=N narrows content. This goes beyond the schema's basic parameter descriptions.

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 'Returns' and resource 'single wiki page', and explicitly differentiates from get-pages and get-revision by naming them. It also clarifies content types (wikitext, HTML, metadata) and error behavior for nonexistent titles.

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 usage context: when to use metadata=true, content='none', section=N, and clearly states 'For more than one page at a time, use get-pages' and 'For a specific historical revision, use get-revision', providing direct alternative routing.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds pagination details, return format (segments of 20, boolean flags only when true), and error on missing title. No contradictions.

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

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

Two sentences that front-load purpose and key behavior (pagination, error). Every sentence adds value. No extraneous 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?

Given 5 parameters and no output schema, description covers return fields, pagination behavior, and error case. Does not mention rate limits or authentication, but those may be implied by API context. Adequate for agent use.

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 description adds minimal value beyond schema. Mentions mutual exclusivity of newerThan/olderThan, which is already in schema descriptions. Does not elaborate on parameter format or constraints.

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?

Clearly states it returns revision metadata (revision ID, timestamp, user, comment, size, minor flag) for a wiki page. Distinguishes from sibling tools like get-revision (single revision) and get-page (page content) by specifying it returns multiple revisions in segments of 20, newest first.

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?

Explicitly describes pagination with olderThan/newerThan parameters and mutual exclusivity. Mentions error behavior when title does not exist. Does not explicitly mention alternatives like get-revision for single revision, but the pagination description guides usage.

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

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

The description adds substantial behavioral context beyond annotations: the byte budget mechanism, inline reporting of missing pages, order preservation, truncation behavior with a marker, and the requestedTitle nuance. These details are not covered by the annotations (readOnlyHint, idempotentHint, destructiveHint) and greatly help the agent understand response handling. No contradiction with annotations found.

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 well-structured and front-loaded: it opens with the core purpose and content mode, then lists typical use cases, then explains the budget behavior, then truncation, and closes with the sibling alternative and a nuance. Every sentence adds essential value without redundancy, achieving high information density without bloat.

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

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

For a tool with no output schema, the description explains the return format comprehensively: missing pages reported inline, byte budget truncation with a marker, ordering, and the follow-up call for remaining pages. It also clarifies the difference from get-page and the requestedTitle behavior. These are the crucial details an agent needs to call it correctly and interpret responses.

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 five parameters, including the '0..50' limit for titles and the meaning of content and metadata. The description does not add parameter-specific semantics beyond the schema; it speaks about tool-level behavior (byte budget, response ordering) rather than explaining individual parameters. Per the rubric, baseline 3 is appropriate when the schema covers all parameters.

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

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

The description clearly states the tool returns multiple wiki pages in one call, specifying the resource (wiki pages) and the action (returns). It explicitly distinguishes itself from get-page by naming the sibling and the condition to use it (single page or HTML output). The purpose is specific and 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 description provides explicit use cases: 'Suited to reading a cluster of related pages, diffing a page family, or syncing pages to local storage.' It also gives an explicit exclusion: 'For a single page or HTML output, use get-page.' This gives clear guidance on when to use this tool versus the alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds transparency by explaining pagination, filtering, boolean flag behavior, and patrol rights requirements, going beyond annotation-only information.

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 paragraph that is clear but could be more structured. It is front-loaded with the main purpose, but the length and density may reduce readability.

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 no output schema, the description explains row contents, filtering, pagination, and rights requirements. It is complete for the tool's complexity and provides necessary context for effective use.

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?

With 100% schema coverage, baseline is 3. The description adds meaning by explaining defaults for types, boolean flag behavior (appear only when true), mutual exclusivity of user/excludeUser, and the effect of showPatrolStatus.

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

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

The description clearly states the tool returns recent change events, newest first, in segments of 50. It specifies what each row includes and distinguishes from the sibling tool get-page-history for single page revision history.

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 explains defaults, filtering options, and pagination. It explicitly directs users to get-page-history for single page history, providing clear context for when to use this tool vs alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: content truncation at 75000 bytes, error on missing revision, and the note that a past revision has no narrower read. These details go beyond annotations and set correct expectations.

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

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

Three sentences with no redundancy. The purpose is front-loaded, followed by error and truncation details, then alternative tools. Every sentence adds value and the structure is easy to scan.

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 revision retrieval tool with high schema coverage and no output schema, the description covers purpose, error cases, truncation, and alternatives. Nothing essential is missing for an agent 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% and every parameter has a description. The tool description does not add per-parameter semantics beyond what the schema provides; it only restates content types and metadata in prose. Since schema carries the burden, 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 states a specific verb and resource: returns a specific historical revision by revision ID, with content types (source, HTML, or metadata). It distinguishes from get-page (latest revision) and compare-pages (diff). The purpose is unmistakable.

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

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

Explicitly guides when to use alternatives: 'For the latest revision plus metadata, use get-page with metadata=true' and 'for a large one use compare-pages to see what changed.' Also notes error behavior on non-existent revision. Clear 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 indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to restate safety. It adds that includeStatistics toggles additional data, but does not disclose any other behavioral traits like potential response size or error conditions for missing wikis. With good annotation coverage, the description is adequate but not exceptional.

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 paragraph that is front-loaded with the main purpose ('Returns key facts about the targeted wiki'). It lists the returned categories concisely and provides a clear action for the boolean parameter. Every sentence earns its place with no redundancy or fluff.

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 tool complexity (simple read-only info retrieval), the description covers what is returned, including the effect of the optional parameter. No output schema is present, but the list of returned items is sufficiently detailed. It might benefit from noting that the response could be large if many extensions are installed, but overall it is complete enough for an agent to use 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?

Both parameters are fully described in the schema (100% coverage). The description adds specific examples of what includeStatistics returns (page, article, edit counts, etc.), which provides extra context. However, it does not explain the wiki parameter beyond what the schema says, so overall the description adds marginal value over 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 description clearly states that the tool returns key facts about a wiki, listing specific categories: general settings, namespace map, extensions, license. It also mentions the optional includeStatistics parameter to get counts. This distinguishes it from sibling tools like get-page or get-pages, which focus on page content rather than site metadata.

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 explains when to set includeStatistics, but does not explicitly state when to use this tool versus alternatives like get-page or list-wikis. The usage context is implied (for wiki metadata), but lack of explicit guidance on when not to use it or what distinguishes it from similar read tools reduces clarity.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds behavioral context: the tool reports whether each wiki is currently reachable and which extension-gated tools work on it. This goes beyond merely listing config and helps the agent anticipate dynamic behavior.

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

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

The description is two sentences with no filler. It front-loads the main action ('Lists every configured wiki') and packs the essential details into the remaining text. Every clause adds value.

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

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

There is no output schema, so the description is the sole source of return-value information. It enumerates the fields an agent can expect (key, sitename, URL, read-only/default, reachability, extension-tool support) and reinforces its purpose. For a zero-argument tool, this is fully 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?

The tool has zero parameters and the input schema is empty. The description correctly mentions the wiki key as a return value ('pass as the wiki argument to other tools'), not as a parameter, so no parameter semantics are needed. The no-parameter baseline of 4 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 and resource: it lists every configured wiki. It enumerates the exact fields returned (key, sitename, server URL, read-only/default status, reachability, extension-gated tools) and states the tool's purpose: to discover configured wikis and their keys. This clearly distinguishes it from sibling tools like add-wiki and remove-wiki.

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 usage guidance: use this tool to discover configured wikis, their keys, and which extension tools each supports. It also notes that the wiki key is passed as an argument to other tools, which helps an agent know when to call it. However, it does not explicitly mention when not to use it or name alternatives, leaving a minor gap.

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

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

Beyond annotations (destructiveHint, readOnlyHint), the description discloses return values, default redirect creation with a right requirement for suppression, and additional permissions for File pages. It provides rich behavioral context without contradicting annotations.

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

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

The description is a single, well-structured paragraph. The first sentence summarizes the core action and return values, followed by details on redirect behavior, failure conditions, and permissions. Every sentence adds necessary information without redundancy.

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

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

Given the complexity (8 parameters, no output schema), the description covers key failure modes, return values, and permission constraints. It could explicitly state the response structure, but it adequately supports tool invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the implications of 'leaveRedirect' (suppressredirect right) and 'ignoreWarnings' (target redirects), and mentions the file-move permission for File pages, which is not 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?

The description clearly states the tool's action ('Renames a wiki page, moving it') and distinguishes it from other page manipulation tools like create-page, update-page, and delete-page. It specifies the resource (wiki page) and the default handling of talk pages.

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 explains when the tool fails (source not found, target exists, permission issues) and details the redirect behavior with permission requirements. It does not explicitly compare against sibling tools, but the purpose is distinct enough for an agent to decide when 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 description adds the 'Stdio only' constraint beyond annotations. Annotations already mark destructiveHint=true, and description aligns. No contradictions.

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

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

Two sentences covering purpose, argument behavior, and transport restriction. No extraneous text.

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 logout tool with one optional parameter, the description adequately covers behavior and constraints. No output schema is needed for this action.

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 parameter description is clear. The tool description echoes the schema content without adding new semantic depth, meeting the 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 'Removes stored OAuth tokens.' It specifies behavior with and without the `wiki` argument, clearly distinguishing the two modes.

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?

Explicitly mentions 'Stdio only', which is a critical usage constraint. It also explains when to use the optional parameter, though it doesn't compare to sibling tools like `oauth-status`.

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

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

Discloses critical behavior beyond annotations: 'Never returns token values' and specifies return content (wikis, scopes, expiry). Annotations already indicate read-only, idempotent, non-destructive; description adds key detail about secrecy.

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

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

Two sentences front-load purpose and key traits. No wasted words; every phrase adds value.

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 zero parameters and no output schema, the description sufficiently covers purpose, return format, and a behavioral constraint (token secrecy). No gaps for expected agent usage.

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?

No parameters exist, so baseline 4 applies. Description does not need to add parameter meaning.

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

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

Description uses specific verb 'Lists' and identifies resource 'wikis with stored OAuth tokens, their scopes, and expiry'. It distinguishes from sibling 'oauth-logout' by focusing on status rather than logout action.

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 transport constraint ('Stdio only') but does not explicitly state when to use this tool versus alternatives like oauth-logout. Implicit context from sibling names helps but could be more directive.

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 idempotentHint, and the description reinforces this without contradiction. It adds critical behavioral detail beyond annotations: the 75000-byte truncation with a marker, and the recommendation to pass a smaller fragment in a follow-up call to retrieve the rest. This is exactly the kind of operational nuance an agent needs to plan correct calls.

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

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

Two dense sentences with zero filler. The core purpose and return list are front-loaded, followed by concrete use cases and then a critical behavioral caveat. Every clause earns its place; nothing is redundant or missing.

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 a 4-parameter schema (fully documented) and no output schema, so the description must cover return values and edge behavior. It lists all major return types and the truncation mechanism, and it contextualizes the 'title' parameter's default via schema. For an agent to call this correctly, everything essential is present.

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 does not add anything material about parameter semantics – it mentions truncation behavior but does not explain the 'wikitext' parameter's role beyond what the schema already states. It satisfies the baseline but does not exceed it.

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

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

The description opens with a specific action ('Renders wikitext through the live wiki without saving'), a clear resource, and a key qualifier that separates it from writing tools like create-page and update-page. It also enumerates outputs (HTML, warnings, categories, etc.), making the tool's function unmistakable and differentiating it from siblings such as get-page or get-revision.

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 second sentence explicitly names the target workflows: 'dry-running a planned edit before create-page or update-page, or previewing standalone wikitext... with no target page.' This tells an agent exactly when to use this tool and when to rely on its siblings, leaving nothing 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 indicate destructive and idempotent behavior. The description adds valuable context: clearing cached credentials and license metadata, and failure on default wiki. This expands on 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?

Three sentences, each providing essential information (main action, side effects, failure condition). No redundancy 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 tool with one parameter and no output schema, the description covers purpose, behavioral side effects, and a key constraint. It is mostly complete, though it does not describe the return value or success 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 coverage is 100% for the single parameter 'uri'. The description does not add new meaning beyond the schema's description of the URI format. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'removes' and clearly identifies the resource 'wiki from the MCP resources'. It adds unique behaviors like clearing cached credentials and license metadata, and specifies a failure condition for the default wiki, distinguishing it from sibling tools such as 'add-wiki'.

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

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

The description implicitly states when to use (when removing a wiki) and provides a precondition (fails if default wiki). However, it lacks explicit guidance on when not to use or comparisons to alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. Beyond that, it adds substantial behavioral context: the full-text vs title scope, the default of 10 and hard cap of 100 with overflow flagging, and the namespace-scope fallback to content namespaces. This exceeds what the annotations alone convey and there is no annotation contradiction.

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

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

Four dense sentences, each earning its place: purpose+returns, namespace scoping, limit/cap behavior, and sibling routing. The core function is front-loaded and the alternative-tool note is placed last where it reads naturally. The only minor blemish is the awkward phrase 'unless namespaces names the namespace IDs', but it remains intelligible and costs no real clarity.

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 search tool with no output schema, the description compensates by describing the return contract (matching pages with snippet, size, timestamp, namespace). It covers scope, defaults, caps, and the sibling alternative. Given the schema is fully self-documenting for parameter types and the annotations carry the safety profile, 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 description coverage is 100%, so the baseline is 3. The description adds value on top: it reveals the default limit of 10 not present in the schema, explains the cap-flagging behavior for the limit parameter, and clarifies that omitting namespaces means 'content namespaces' — a semantic the schema alone does not state. It doesn't fully document each parameter, but it meaningfully augments the schema rather than repeating it.

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

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

The description states a specific verb and resource: 'Searches wiki page titles and page content (full-text) for the provided terms.' It also enumerates what is returned (snippet, size, timestamp, namespace), which makes the purpose concrete and self-contained. It explicitly distinguishes itself from search-page-by-prefix, so an agent can separate the two sibling tools 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 description gives explicit routing guidance: 'For title-prefix lookup (e.g. autocomplete), use search-page-by-prefix.' It also explains when to narrow a query (when matches exceed the cap), how namespace scope is determined, and where to resolve namespaces (get-site-info). This is explicit when-to-use and when-not-to-use guidance with named alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying that only titles are returned (no snippets/IDs), the limit cap of 500, and that excess matches are flagged. Does not contradict 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?

Three concise sentences: purpose, limit detail, alternative tool. No superfluous words, front-loaded with key information.

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

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

With no output schema, the description hints at the response (flags for excess matches) but doesn't fully detail the return format. However, given the simplicity of the tool (returning titles), it is reasonably complete along with 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 coverage is 100% (baseline 3). The description adds the default limit value (10) and indicates that wiki can be given as a key or full URI, providing extra context 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 description clearly states it returns wiki page titles by prefix, distinguishes from full-text search (search-page) by specifying only titles are returned, and notes it's suited for autocomplete. This effectively differentiates it from sibling tools like get-page and search-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?

Explicitly directs to search-page for full-text content, implies autocomplete use case. Could mention when to use get-page for exact titles, but current guidance is sufficient.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds context about full revision history restoration and failure conditions, disclosing behavior beyond annotations without contradiction.

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

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

Two concise sentences with no wasted words, front-loading the main action and immediately providing key constraints.

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

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

For a tool with 3 parameters and no output schema, the description covers purpose, prerequisites, failure modes, and return value. Could mention output structure, but overall complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional parameter details beyond what the schema provides, offering no extra semantic 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 uses specific verb 'restores' and identifies the resource as a 'previously deleted wiki page', clearly distinguishing it from siblings like delete-page, create-page, and update-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?

Explicitly states prerequisite (page must be in deleted state from delete-page) and failure conditions (no deleted revisions or insufficient permissions). Does not mention alternatives, but context is sufficient.

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

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

Discloses that it replaces file content (destructive), preserves prior revisions, appears in upload log, and fails if file doesn't exist. This adds valuable behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=true) without contradiction.

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

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

Two well-structured paragraphs front-load the core action and return values, then add context, restrictions, and alternatives. Every sentence adds value without 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?

Despite no output schema, the description covers purpose, usage, parameters, behavioral traits, error conditions, and sibling distinctions comprehensively. It is complete for a file revision update 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 covers all 4 parameters with descriptions (100% coverage), but the description adds important operational detail about filepath: it must be an absolute path inside a configured upload directory. This supplements schema information meaningfully.

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

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

The description clearly states it uploads a new revision of an existing file, preserving history, and returns file title and URL. It distinguishes from sibling tools like upload-file (initial upload) and update-file-from-url (remote URL), making the purpose 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?

Explicitly provides when to use (updating existing file revision) and when not (initial upload use upload-file, for description page use update-page, for remote URL use update-file-from-url). Also details restrictions on filepath, offering clear 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 indicate destructive and not read-only. The description adds that prior revisions are preserved, the upload appears in the upload log, and it only replaces bytes. It also describes the fallback mechanism and failure condition when the file does not exist.

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 concise with four sentences, front-loading the core action. Every sentence adds value, and there is no redundancy.

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

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

Given no output schema, the description mentions the return (file title and URL). It covers behavior, failure conditions, and alternatives. Complete for a tool with moderate complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for the 'title' parameter by stating it fails if no file exists, and implies the 'url' parameter is the source. However, it does not add significant new meaning beyond the schema descriptions.

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

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

The description clearly states that the tool fetches a file from a URL and uploads it as a new revision of an existing file, preserving history. It distinguishes from sibling tools by specifying it is for updating an existing file (not initial upload) and only replaces file content, not the description page.

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

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

The description explicitly tells when to use (updating an existing file from URL) and when not to (initial upload use upload-file-from-url, editing description page use update-page). It also explains the fallback behavior for wiki-side fetching.

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 extensive context: failure conditions (page missing, ambiguous find, oversized target), the refusal of find-replace when no match or multiple matches, the effect of section-scoped replace on subsections, and the edit-conflict rejection behavior. It also explains that resending append/prepend duplicates the delta, aligning with idempotentHint=false. No contradictions with annotations.

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

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

The description is long but every sentence earns its place, packing operational semantics, failure modes, and safety guarantees without fluff. It front-loads the core purpose, then systematically covers operations, edge cases, and conflict detection, maintaining logical flow.

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

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

For a tool with 13 parameters, multiple operations, and no output schema, the description covers all operational aspects: return value (revision ID), failure conditions, idempotency caveats, section handling, and conflict detection. It also implicitly addresses parameters like bot and wiki via schema descriptions, leaving no critical gap for correct invocation.

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

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

While schema coverage is 100%, the description adds substantial meaning beyond schema: it explains how operation interacts with parameters, clarifies the 'find' matching rules (exact, whitespace-sensitive, refused on ambiguity), details the 'latestId' requirement rationale, and notes that 'source' for append must start with a newline. This exceeds the baseline for high 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 opens with a precise verb and resource ('Writes to an existing wiki page') and explicitly contrasts it with create-page for new pages. It also enumerates the distinct operations (find-replace, replace, append, prepend) with clear semantics, making it unambiguous against sibling tools like delete-page, move-page, and create-page.

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

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

The description gives explicit when-to-use guidance: it tells agents to use create-page for new pages, explains when to prefer find-replace over replace (to avoid rewriting unread content), and clarifies when append vs prepend is appropriate. It also states when latestId is required (section set) and warns about non-idempotency for resending append/prepend.

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?

While description discloses upload log entry and failure conditions, it contradicts the annotation 'idempotentHint=true' because uploading a file that already exists fails, making it non-idempotent. This reduces transparency.

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?

Description is concise with no extraneous words. First sentence states purpose and return, then restrictions, then alternatives. Optimal length.

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 return values, failure conditions, and alternatives. Missing details on default wiki and comment parameter behavior, but overall adequate. Annotation contradiction detracts.

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 covers all 5 parameters, so baseline is 3. Description adds minor value: clarifies filepath must be absolute and title accepts 'File:' prefix or not, but mostly restates 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 description clearly states the verb 'uploads', specifies the resource 'file from local disk into wiki's File namespace', and distinguishes from siblings like 'upload-file-from-url' and 'update-file'. It also mentions returns file title and URL.

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?

Explicitly tells when to use (upload local file) and provides alternatives for remote upload or replacement. Also describes restrictions: filepath must be absolute in configured dir, fails if title exists.

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

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

Annotations already indicate idempotent, non-destructive, non-read-only behavior. The description adds value by disclosing the fallback mechanism, logging appearance, and failure condition on existing titles, providing rich behavioral context beyond 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?

The description is concise with four sentences, each serving a specific purpose: main action, logging, behavior detail, and alternative guidance. Information is front-loaded and no words are wasted.

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

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

Given no output schema, the description mentions the return value (file title and URL). It covers failure mode, fallback behavior, and provides an alternative tool. It could mention authentication or rate limits but is largely complete for an AI to use.

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 all parameters described in the schema. The description does not add additional semantics or usage details for individual parameters, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool fetches a file from a remote URL and uploads it to the wiki's File namespace, returning the title and URL. It distinguishes itself from the sibling tool 'update-file-from-url' by noting the failure condition for existing files and pointing to the alternative for replacement.

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 explicitly tells when to use this tool (new uploads) and when not to (if file already exists, use update-file-from-url). It also clarifies it works regardless of wiki upload-by-URL settings, providing clear context for decision-making.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds valuable detail: 'Reports anonymous access rather than failing when the session has no credentials', which is 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?

Five sentences, front-loaded with purpose. Each sentence adds value. Could be slightly more concise but well-structured 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?

Given 2 parameters, full schema coverage, no output schema, description covers return values and anonymous behavior. Complete for a simple read-only identity 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%, so baseline is 3. Description restates parameter purposes but adds no significant new meaning beyond schema descriptions.

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?

Description clearly states tool returns identity (username, anonymous status, groups). Verb 'returns' and resource clearly defined. Distinguishes from sibling tools like oauth-status.

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?

Explicitly states when to use: confirm attribution before writing, resolve username. Provides alternative for OAuth scopes: 'use oauth-status instead'. Includes guidance on optional parameter.

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