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?

Annotations already indicate readOnly, idempotent, non-destructive. The description adds important behavioral details: supported side types (revision ID, title, supplied wikitext), the rejection of text-vs-text, truncation at 50000 bytes with a trailing marker, and error behavior for missing titles/revisions. This is beyond what annotations provide.

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

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

The description is well-structured with the main purpose first, followed by detailed usage. It is slightly long but every sentence adds necessary information. 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 complexity (8 parameters, no output schema), the description is thorough: it covers parameter semantics, truncation, change-detection mode, and error handling. It does not describe the exact return format, but that is acceptable due to the diff output being standard. The annotations and schema coverage further complete the picture.

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 the description adds critical semantics: it explains that each side can be a revision ID, page title, or supplied wikitext, and that both sides cannot be supplied wikitext. It also explains the effect of includeDiff=false, which is not fully captured in the schema description.

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

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

The description clearly states the verb ('returns'), the resource ('changes between two versions of a wiki page'), and the output ('compact text diff'). It distinguishes from sibling tools like get-page by explaining that this tool provides a diff, not the full text.

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 this tool (to get changes) and when to use an alternative ('For the full text of both sides, fetch with get-page instead'). Also describes the includeDiff=false option for cheap change-detection, and clarifies that text-vs-text is rejected and that nonexistent titles/revisions cause errors.

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

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

Description reveals failure on duplicate and optional contentModel, but contradicts the idempotentHint annotation (true) by stating it fails if page exists. This is a significant inconsistency that 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?

Three concise, well-structured sentences that front-load the core action and return values, with no unnecessary 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?

Covers purpose, failure conditions, contentModel usage, and chunking strategy. Missing explicit return format structure (but partially described). Good given no output schema, though the 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 6 parameters with descriptions (100% coverage). Description adds context by explaining contentModel selects non-default formats and suggests pairing with update-page, going slightly beyond 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 creates a new wiki page and returns specific fields. It distinguishes from update-page for existing pages, providing a specific verb and resource.

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 (new page) and when not (existing page: use update-page). Also provides guidance on contentModel and pairing with update-page for chunking.

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?

Beyond annotations (readOnlyHint, idempotentHint), the description details truncation at 50000 bytes with a trailing marker, the need for a follow-up call with section=N, error behavior for non-existent titles, and the metadata fields (revision ID, page size, section outline). This adds significant behavioral context.

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

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

The description is a single, well-structured paragraph. It front-loads the core purpose and uses concise sentences to add critical details without redundancy. Every sentence earns its place.

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

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

For a read-only tool with 5 parameters and no output schema, the description covers purpose, alternatives, truncation, and parameter use. It omits details about the output structure, but the context is largely sufficient for an agent to invoke the tool correctly.

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

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

Although schema coverage is 100%, the description enriches the meaning of metadata and content parameters by explaining their real-world use (e.g., edit-conflict detection, section retrieval after truncation). It adds value beyond the schema definitions.

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 a wiki page with options for wikitext, HTML, or metadata. It explicitly distinguishes from siblings like get-pages and get-revision, 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?

The description provides explicit alternatives for multiple pages (get-pages) and historical revisions (get-revision), and explains when to use metadata and section parameters. However, it does not mention scenarios where this tool should not be used.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral context: truncation at 50000 bytes, trailing marker with sections, missing pages reported inline, requestedTitle behavior. 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?

Front-loaded with main purpose and use cases, then details on limits and alternatives. Every sentence adds information with no redundancy.

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

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

Covers all necessary behavioral details despite no output schema: limits, error handling, alternatives. Complete for a read-only batch retrieval tool with good 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 has 100% description coverage. Description adds meaning beyond schema: explains that missing pages are reported inline, truncation behavior, requestedTitle condition. Adds value to parameter understanding.

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 multiple wiki pages (wikitext or metadata), distinguishes from get-page (single page, HTML output), and specifies use cases like batch reading, diffing, and syncing.

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: 'Suited to reading a cluster of related pages, diffing a page family, or syncing pages to local storage.' Also specifies alternative: 'For a single page or HTML output, use get-page.'

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

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

Annotations already 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, so no contradiction. The description adds value by specifying the returned content types (source, html, metadata only) and the error case when revision ID does not exist. It does not describe the full response structure, but the behavioral traits are adequately disclosed.

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 three sentences, front-loading the main action and options. Every sentence adds value: purpose, error behavior, and alternative tool. No redundant or verbose content.

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

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

The description covers the main functionality (get revision, content types, error handling) and includes a pointer to an alternative for latest revisions. However, without an output schema, it does not fully describe the return format (e.g., what fields are present for each content type). It mentions metadata fields but not the full response structure, leaving some gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides. It mentions revision ID and content type but does not elaborate on the meaning or constraints of the 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 explicitly states it returns a specific historical revision of a wiki page by revision ID, and clarifies it can return wikitext source, rendered HTML, or metadata only. It also distinguishes from the sibling tool get-page by noting that get-page with metadata=true is for the latest revision plus metadata, making the purpose unique and clear.

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

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

The description provides clear when-to-use guidance: for retrieving a specific historical revision by ID. It explicitly gives an alternative: 'For the latest revision plus metadata, use get-page with metadata=true.' This helps the agent choose the correct tool.

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 mark the tool as readOnlyHint, idempotentHint, and non-destructive. The description adds behavioral context by stating what information is returned (reachability, extension-gated tool support), which goes beyond annotations. 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?

The description is concise, front-loaded with the main purpose, and every sentence adds value. No fluff or repetition.

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

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

For a zero-parameter read-only tool, the description completely explains the output fields and usage purpose. No output schema is provided, but the description explicitly lists the returned fields, which is sufficient.

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

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

The input schema has no parameters, so schema description coverage is trivially 100%. The description does not add parameter semantics, but none are needed. Baseline 3 applies as per high coverage rule.

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 lists every configured wiki with specific details like key, sitename, server URL, read-only status, default status, reachability, and extension-gated tool support. It distinguishes itself from sibling tools by being the only list/discovery tool, while siblings like add-wiki or remove-wiki perform mutations.

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 says 'Use to discover the configured wikis, their keys, and which extension tools each supports.' This provides clear usage context. It does not explicitly mention when not to use it, but the purpose is straightforward and well-defined.

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 provide readOnlyHint, idempotentHint, destructiveHint=false. The description adds critical behavioral details: HTML truncation at 50000 bytes with a trailing marker and how to retrieve the rest via smaller fragment, enhancing transparency beyond structured fields.

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

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

Three sentences, front-loaded with purpose, followed by key behavioral details. No wasted words; every sentence 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?

Despite no output schema, the description enumerates return values (HTML, warnings, categories, etc.) and addresses truncation. For a tool with 4 parameters and no output schema, this is a complete and helpful description.

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

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

Schema covers all 4 parameters (100% coverage). Description adds context: default value for title ('API'), and that applyPreSaveTransform matches editor 'Show preview' behavior. This adds meaningful nuance 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 renders wikitext without saving, and distinguishes it from sibling tools like create-page and update-page by positioning it as a dry-run mechanism.

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 use cases: dry-running edits before create/update, and previewing standalone wikitext. Implicitly excludes when you want to save, but lacks an explicit 'when not to use' statement.

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 declare readOnly, openWorld, idempotent hints, and non-destructive. Description adds behavior beyond annotations: accepts up to 100 matches (default 10), flags additional matches in response, and suggests narrowing queries. No 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 sentences with zero waste. First sentence states purpose and return fields. Second sentence adds usage nuance (cap, default, flag, suggestion). 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?

No output schema, but description enumerates return fields (snippet, size, timestamp) and behavioral details (cap, flag). Parameter coverage is complete. Sufficient for an agent to understand usage, though could mention pagination or response structure more explicitly.

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 3. Description adds value by specifying the limit default (10), the maximum cap (100), and explaining that extra matches are flagged and query narrowing is needed—details beyond the schema's simple min/max 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?

The description clearly states the tool searches wiki page titles and content (full-text) and returns matching pages with snippet, size, timestamp. It distinguishes from the sibling tool 'search-page-by-prefix' by explicitly mentioning its full-text scope versus title prefix lookup.

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 advises when to use this tool (full-text search) and when to use the alternative (title-prefix lookup via search-page-by-prefix). It also mentions the match cap and strategy to narrow queries for more results. Lacks explicit 'when not to use' but provides sufficient guidance.

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

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

Annotations already declare readOnlyHint, 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?

The description discloses important behaviors beyond annotations: failure on non-existent page, conflict detection with latestId, each call creates a new revision, and chaining mode='append' requires re-fetching latestId. Bot flag behavior is also detailed. No contradiction with annotations.

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

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

The description is a dense single paragraph but front-loads the main purpose. It is relatively concise given the detail, though could benefit from minor structuring. No fluff or redundancy.

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

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

Despite no output schema, the description mentions return value (new revision ID). It covers failure conditions, conflict detection, and all parameter use cases. For a tool with 9 parameters and 2 required, it is fully 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 coverage is 100%, so baseline is 3. The description adds valuable context: latestId origin, section numbering/indexing, mode direction. This enhances understanding without being necessary, pushing score to 4.

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

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

The description clearly states the tool replaces existing page content and returns the new revision ID. It distinguishes from create-page for new pages, and mentions modifiers like section and mode. The verb 'replaces' and resource 'content of a wiki page' are specific.

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 instructs to use create-page for new pages, explains edit-conflict detection with latestId, and provides guidance on when to use section and mode. It also describes when not to use (page must exist). Alternatives like create-page are mentioned.

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.