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

No annotations are provided, so the description carries the full burden. It discloses that bot credentials are optional and how the new name is consumed downstream, but it omits whether the registration persists, whether names must be unique, and what happens on failure.

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

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

Three tight sentences with zero filler, front-loaded with the action and ending on the downstream usage of the result. 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?

With no annotations and no output schema, the description is adequate for a simple registration call but leaves notable gaps around persistence, uniqueness enforcement, and error behavior. It is minimum-viable rather than 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 the schema already documents name, url, username and password. The description only restates that the URL is the base URL and credentials are optional, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('Register a new MediaWiki instance') and adds the payoff ('so you can read and edit its pages'). Clear on what it does, but does not differentiate from the sibling set-wiki, leaving the agent to infer the distinction.

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

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

Gives only post-add guidance ('use the wiki name in other tools' "wiki" parameter'), which is helpful but forward-looking rather than selection guidance. It never says when to call add-wiki versus set-wiki, or what happens on duplicate registration.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the key precondition that the target must not already exist, but says nothing about what happens on violation (error vs. overwrite), permission/auth requirements, or whether the created page is returned.

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

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

Two tight sentences with zero waste; the core action is front-loaded and the constraint plus alternative follow immediately. Every clause 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 mutation tool with no annotations and no output schema, the description covers the action, the precondition, and the alternative well. It stops short of describing failure behavior when the page exists or the return value, which an agent would benefit from given the absence of annotations.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema (including the 'ask the user if not known' guidance for user). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Create) and resource (wiki page) plus the content format (wikitext). It explicitly contrasts itself with the sibling update-page, so an agent can distinguish the two without reading 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?

Gives an explicit precondition (the page must not already exist) and routes the agent to the named alternative (update-page) for the modify case. When-to-use and when-not-to-use are both covered.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses two key traits: the operation is permanent/irreversible, and it requires admin/sysop rights. It doesn't mention rate limits, edit summaries, or what the response contains, but the two disclosed traits are the most safety-critical ones for a destructive operation.

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

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

Two short sentences, zero waste, front-loaded with the destructive action first, then the permission requirement. Ideal density for a simple tool.

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

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

For a destructive mutation tool with no annotations and no output schema, the description covers the essential facts an agent needs: what it does, that it's permanent, and that elevated permissions are required. It doesn't mention failure modes or return values, but the core call-critical information 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 all four parameters (user, wiki, title, reason) are already documented in the schema. The description adds no parameter detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb (delete) and resource (wiki page), plus the critical qualifier 'permanently' which distinguishes it from the sibling undelete-page. An agent can immediately tell what this does and how it differs from the restore tool.

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 implies when to use it (permanent page removal requiring admin rights) versus undelete-page, but doesn't explicitly name the alternative or spell out the when/when-not condition. The permanence qualifier gives clear context that this is irreversible.

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the triage order of matching strategies, redirect following, default cross-wiki scope, and the ranked-result ordering. It omits auth requirements, rate limits, or error behavior, but covers the read-only operational semantics thoroughly.

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

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

Purpose is front-loaded in the first sentence, followed by mechanism and ranking, then usage. Four sentences with little waste, though the final sentence is slightly long. Nothing extraneous.

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

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

No output schema exists, and the description compensates by describing the returned ranked list and its ordering, so an agent knows what to expect. Combined with full schema coverage, it is complete enough to call correctly, missing only minor operational caveats.

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 all three parameters are already documented in the schema. The description restates the cross-wiki default (matching the wiki param) and the single ranked list (relating to limit) but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific noun-and-verb framing ('Unified page locator') and details its three-stage matching strategy (exact/redirect, prefix, full-text). It clearly positions itself as the combined superset of the narrower search-page and search-page-by-prefix siblings, so an agent can tell it apart without opening any schema.

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

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

It gives explicit when-to-use guidance ('Use this as the first step whenever you need to locate a specific page') and explains it works for exact, partial, or topical input. It doesn't name specific alternative tools or state when NOT to use it, so it stops short of a full routing rule.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return shape (titles and IDs) and the aggregation nature, which is useful, but it says nothing about pagination behavior (limit default 50, continue_from), read-only safety, or permission requirements.

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

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

Three short, front-loaded sentences with no obvious padding. The type-filter sentence slightly repeats the enum already in the schema, but the size is appropriate for the tool.

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

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

For a read-only listing tool with full schema coverage and no output schema, the description covers purpose, filter, and return content adequately. The main omission is pagination behavior, which an agent might want when results are truncated.

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

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

Schema coverage is 100%, so every parameter is already documented in the schema, and the type enumeration is duplicated rather than extended. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (list) and resource (members of a category), enumerating the member kinds (pages, subcategories, files). This clearly distinguishes it from list-categories and get-page, though it doesn't name those siblings explicitly.

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

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

"Use type to filter (page/subcat/file)" gives implied usage for one parameter, but there is no guidance on when to prefer this tool over list-categories, search-page, or get-page, and no exclusions or prerequisites.

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

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

With no annotations, the description must carry the behavioral load; it discloses the read-only nature implicitly via 'Get' and enumerates what is returned (dimensions, size, media type, original/preferred URLs), which is genuinely useful. It omits permissions/auth requirements and any behavior for missing or non-file titles.

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

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

Two tight sentences, front-loaded with the core action and followed by the return contents. No filler 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?

With no output schema, the description correctly compensates by listing the return fields, and the input schema fully documents the two parameters. It lacks usage/alternative guidance and auth notes, but for a simple read tool this is close to 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% and the schema already documents both 'wiki' and 'title' (including the 'File:' prefix tolerance), so the description adds no parameter meaning beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ('Get metadata and download URLs for an uploaded file') plus the resource types handled (image, PDF, etc), which is clear and actionable. It does not explicitly differentiate itself from retrieval siblings like get-page or get-revision, so it falls short of a 5.

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

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

The description never says when to use this tool versus alternatives, nor any prerequisites (e.g., that the file must already be uploaded via upload-file/upload-file-from-url). Nothing routes the agent among siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses returned fields (title, ID, content model, revision info, wikitext), which is the main behavioral context. It doesn't state whether the operation is read-only (implicit from 'Retrieve' and 'get'), whether it requires authentication, or error behavior for missing pages – gaps for a read tool with no 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 purpose and return contents, second sentence provides a critical usage directive. 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?

Given no output schema and a simple read operation, the description adequately covers what is returned and when to use it. Minor gaps remain around permissions and error handling, but for a 3-param getter with full schema coverage, it is nearly 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 parameter documentation is fully handled by the schema. The description adds no parameter-specific details (e.g., title format, wiki name default behavior), but baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb (Retrieve) and resource (wiki page's full wikitext source and metadata) and enumerates exactly what is returned. Clearly distinguishes from siblings like get-revision and get-page-history by emphasizing 'full source' and '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?

Explicitly says to call before update-page to read current content, giving a clear workflow context. It doesn't mention when not to use it or name alternatives like get-revision for just a revision, but the primary usage is well-articulated.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the return contents (IDs, timestamps, authors, size changes, edit summaries) and the pagination mechanism, but says nothing about permission requirements, default limits, or whether an empty/nonexistent page errors.

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

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

Three tight sentences with the purpose front-loaded, followed by return content and the pagination hint. No wasted wording, though it could be marginally denser.

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

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

No output schema exists, so the description appropriately covers return fields and pagination. For a simple read tool this is largely sufficient, with only minor gaps around limits and error behavior.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description only reiterates older_than as the pagination key, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (Get) and resource (revision history of a wiki page), which is clearly distinct from sibling get-revision (single revision) and get-page (current content). It does not explicitly name those siblings, but the resource is unambiguous.

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

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

The description gives one concrete usage hint — use older_than to paginate long histories — which is genuinely helpful. However, it offers no guidance on when to prefer this over get-revision or get-page, and no exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape (link titles and namespaces) and direction semantics, but says nothing about read-only nature, permissions, rate limits, or pagination behavior despite a continue_from param existing. Some context, but incomplete for a query 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?

Two tight sentences with no waste, front-loading the two-mode behavior and return format. Efficient, though it could be more concise about the namespace detail.

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

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

With no annotations and no output schema, the description does enough to orient an agent on the core query and return shape, but omits pagination semantics (continue_from) and safety profile. Adequate but with clear gaps for a 5-param, no-annotation 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 the schema already documents all five parameters including the direction enum. The description restates the direction semantics already in the schema but adds no new syntax, format, or constraint details. Baseline 3 applies.

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

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

States a specific verb (get) and resource (page links), and explicitly distinguishes the two modes via direction=from vs direction=to. No sibling tool covers page links, so the purpose is unambiguous.

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

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

Explains what each direction value means, which is implied usage guidance, but offers no when-to-use vs alternatives, no prerequisites, and no routing to other 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?

No annotations are provided, so the description bears the full behavioral burden. It usefully lists return fields (timestamps, change types, page titles, authors, size deltas, edit summaries) in place of an output schema, but omits operational details like auth needs, rate limits, pagination behavior, or the time window covered.

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 front-loaded sentences with no wasted text: purpose, return fields, then usage context. Each sentence contributes distinct information.

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

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

The description adequately covers a read-only feed tool with fully documented parameters and no output schema by summarizing return fields. It leaves minor gaps around ordering and time-window behavior, but these are not critical 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 description coverage is 100%, so parameter semantics are fully documented in the schema. The description only implies cross-wiki scope via 'across wikis' and adds no syntax, defaults, or filtering guidance beyond the schema.

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

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

States a specific verb and resource: 'Get a feed of recent edits, page creations, and log events across wikis.' The cross-wiki scope and feed framing distinguish it from page-specific siblings like get-page-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?

Says it is 'Useful for monitoring wiki activity,' which implies a use case but does not specify when to choose this over get-page-history, search-page, or other siblings. No alternatives or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a safe read, and the description does disclose the returned fields (title, timestamp, author, size, byte delta, edit comment), which is genuinely useful. However it says nothing about error behavior for an invalid/missing revision ID, wiki defaulting, or permissions.

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

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

Two short sentences, purpose front-loaded, and the return-value list is compact and informative. 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 simple two-parameter read tool with no output schema, the description covers what the tool does and enumerates the returned fields, which compensates for the missing output schema. Minor gap: nothing about the wiki defaulting behavior or failure modes.

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

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

Schema description coverage is 100%, so both parameters (wiki, revision_id) are already documented in the schema; baseline 3 applies. The description's 'by ID' adds only a marginal restatement of the revision_id parameter.

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

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

States a specific verb+resource: get details for a single revision identified by ID. This is distinguishable from get-page-history (which lists revisions) and get-page, but the description never explicitly contrasts with those siblings, so it falls just short of a 5.

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

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

The phrase 'by ID' implies the caller must already have a revision ID, which is useful context, but there is no explicit when-to-use guidance, no mention of get-page-history as the alternative for listing revisions, and no stated prerequisites.

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

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

With no annotations, the description carries full behavioral burden. It does disclose the return content (page/subcat/file counts), which is helpful, but says nothing about pagination behavior despite the limit and continue_from parameters, nor about permissions or read-only nature.

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

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

Three short sentences, front-loaded with the core action and return shape, then the filter hint. No filler, though the third sentence is soft utility framing rather than essential information.

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

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

For a four-parameter list tool with no output schema, the description covers the action, the filter, and the return shape, which is adequate. It omits pagination behavior and multi-wiki scoping semantics that the continue_from and wiki parameters imply.

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 four parameters; baseline 3 applies. The description's prefix note largely restates the schema's own 'Filter categories by prefix' and adds nothing for wiki, limit, or continue_from.

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

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

States a specific verb and resource ('List all categories on the wiki') and discloses what is returned (page/subcat/file counts). It implicitly distinguishes itself from the sibling get-category-members by listing categories rather than their members, though it never names that alternative.

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 final sentence ('Useful for discovering how content is organized') implies a discovery use case, and the prefix note hints at narrowing. However, there is no explicit when-to-use vs when-not guidance and no mention of the sibling get-category-members for drilling into a category.

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?

With no annotations, the description carries the full burden. It discloses the returned fields and implies a read-only operation via the verb 'List', but does not explicitly state that it has no side effects or describe any potential error conditions or output format beyond the listed attributes.

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

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

A single, well-structured sentence that front-loads the purpose and immediately provides actionable guidance. Every word adds value, 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?

For a zero-parameter listing tool with no annotations or output schema, the description is reasonably complete. It covers what is listed and when to use it, but could optionally mention absence of side effects or whether wikis are sorted.

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 an empty input schema, so parameter documentation is not needed. The description adds value by explaining what the output contains (URLs, auth status, default), which is useful for the agent.

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 all registered wikis and specifies the returned attributes (URLs, auth status, default). It is distinct from sibling tools like add-wiki and remove-wiki, which modify wikis, and search tools, which operate on 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 gives explicit when-to-use guidance: 'Call this first if you're unsure which wikis are available.' It does not explicitly name alternatives or when-not scenarios, but the context makes it clear this is the initial discovery 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?

With no annotations, the description carries the burden and does disclose the key behavioral trait: it does not affect the underlying wiki, only the session registration. It does not state reversibility (whether re-adding restores access), error behavior for unknown names, or permission requirements, so it falls short of full 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?

Two short sentences, front-loaded with the action and followed by the crucial scoping caveat. Every clause 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 one-parameter tool with no output schema, the description covers the essential behavior (session-scoped removal, non-destructive). Minor gaps remain around reversibility and error cases, but nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and the single 'name' parameter is documented in the schema. The description adds no format, naming, or resolution semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Unregister') and resource ('a wiki') and immediately clarifies the scope of the effect ('no longer accessible'), which distinguishes it from the destructive delete-page sibling. An agent can tell this apart from add-wiki/list-wikis/set-wiki without opening any schema.

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

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

The clause 'only removes it from this session' implies the appropriate use case (session-scoped unregistration rather than data deletion), but no alternative tool is named and no when-not guidance is given. Usage is inferable rather than explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add useful behavior by stating the return payload (page titles, IDs, text excerpts) and that the search is read-only in nature, but it says nothing about result ordering, pagination beyond the limit param, or whether searching all wikis has cost 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?

Three short sentences, front-loaded with the core operation, then the return shape, then the selection cue. No filler 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?

For a read-only search tool with a fully documented schema, the description covers purpose, output shape, and when to reach for it. It is nearly complete; only ranking/pagination behavior and the query syntax are unaddressed.

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

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

Schema description coverage is 100%, with wiki, limit, and query all documented in the schema, so the baseline is 3. The description adds no extra meaning about query syntax (e.g., whether it supports phrases or operators) or the behavior of omitting wiki, which the schema already covers.

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

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

States a specific verb and resource ('Full-text search across wiki pages') and immediately says what comes back (titles, IDs, text excerpts), which separates it from siblings like find-page or search-page-by-prefix. An agent can identify the operation without opening the schema.

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

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

Gives an explicit selection condition: 'Use this to find pages when you don't know the exact title,' which implicitly contrasts with the exact-title lookup sibling. It does not name the alternative tool (find-page) or say when not to use this one, so it stops short of full routing guidance.

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

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

No annotations are provided, but this is an inherently safe read-only lookup and the description discloses the return payload ('matching page titles and IDs') plus a performance characteristic. It does not mention pagination behavior, the cross-wiki default, or rate limits, so it adds moderate rather than rich 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?

Three short sentences, front-loaded with the core action and scope, and each subsequent sentence (return values, performance trade-off) earns its place. No padding or redundant restatement of the name.

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

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

With no output schema, the description responsibly states what comes back (titles and IDs), and the inputs are fully covered by the schema. Minor gaps remain around the wiki-scoping default and result limits, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so all three parameters (wiki, limit, query) are already documented in the schema. The description's mention of 'title prefix' restates the query semantics without adding format, matching, or case-sensitivity details, so the schema does the heavy lifting.

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

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

States a specific verb+resource ('Search for pages') and narrows it precisely to title-prefix matching with an autocomplete framing. The note about being 'faster than full-text search' implicitly distinguishes it from the sibling search-page, so an agent can pick between them without opening schemas.

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

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

Gives clear context for when to choose this tool ('when you know the beginning of the page title') and contrasts it against full-text search. It stops short of naming the sibling tool explicitly (search-page), leaving the alternative to inference, so it is strong but not exhaustive.

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?

With no annotations, the description must carry the behavioral burden, and it does disclose the key global side effect: the chosen wiki becomes the implicit default for other tool calls that omit "wiki". It does not mention persistence scope, permissions, or whether the change is reversible, which leaves some gaps for a state-mutating 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?

Two short sentences: the action first, then the consequence, with zero filler. 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 one-parameter setter with a fully documented schema and no output schema, the description gives enough to call it correctly and understand its effect. Only the persistence/permission details are missing, which is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100% and the single "name" parameter is fully documented in the schema as the registered wiki to set as default. The description adds no syntax, format, or constraint detail beyond that, so the baseline of 3 is appropriate.

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

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

States a specific verb (Set) and resource (default wiki) and explains the concrete outcome: which wiki is used when the "wiki" parameter is omitted. This clearly separates it from siblings like add-wiki, remove-wiki, and list-wikis, which manage the registry rather than the default pointer.

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?

Explains the context in which this matters (multiple wikis registered) and what it affects downstream, so an agent can infer when to call it. It stops short of explicit when-not guidance (e.g., what happens on a single-wiki setup or how to reset the default), so it is clear but not fully prescriptive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the admin/sysop permission requirement, but it does not explain whether the restore is reversible, what happens if a page with that title already exists, or how conflicts/history are handled.

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

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

Two sentences, front-loaded with the action and followed by the key permission prerequisite. There is no redundant or filler 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 purpose and authorization, which is helpful, but with no annotations and no output schema, it leaves key behavioral details unstated, such as return behavior, reversibility, or handling of an already-existing page with the same title.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no parameter-level syntax, formatting, or defaulting details beyond what the schema provides, making the baseline score 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: 'Restore a previously deleted wiki page.' It clearly distinguishes the operation from sibling tools such as delete-page, create-page, and update-page by specifying that the page is previously deleted.

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

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

Usage context is clear: use this when a deleted wiki page needs to be restored, and the caller must have admin/sysop rights. It does not name alternatives or explicitly state when not to use the tool, but the context is sufficient for a simple restore operation.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the server-side fetch/apply/save flow for diff, the section-replacement semantics, and content-replacement scope. It omits mutation-confirmation, revertability, and auth/permission requirements, but the core behavioral mechanics of each mode are well covered.

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

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

Front-loaded with the workflow and mode guidance, which earns its place. However, the 11-line wikitext style guide is largely tangential to invoking this tool and bloats the definition; it reads as reference material rather than invocation guidance.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers workflow, mode selection, and edit semantics well enough to invoke correctly. Missing permission/attribution caveats (the 'user' param notes attribution) and confirmation behavior are the main 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 schema already documents all 9 parameters. The description adds mode-selection semantics (e.g., 'append... without reading current content first') beyond the schema, but does not add parameter-level syntax detail beyond what the schema provides.

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

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

States a specific verb+resource ('Update an existing wiki page') and immediately differentiates the edit modes, which distinguishes it from siblings like create-page and delete-page that share the page 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 names the workflow prerequisite (call get-page first) and provides a clear decision framework: 'use exactly one' of diff/section+content/append/prepend/content, with 'Preferred' and 'Avoid for large pages' guidance. This is textbook when-to-use 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?

No annotations are provided, so the description carries the full behavioral-disclosure burden. It states the base64 input requirement but omits authentication or permission needs, overwrite behavior for duplicate filenames, size limits, and what side effects occur on the wiki.

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 definition is short and front-loads the main purpose, but the second sentence repeats the base64 requirement already stated in the first sentence and in the schema. One sentence would have sufficed.

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 six-parameter mutation tool with no annotations and no output schema, the description is too thin. It does not cover permissions, overwrite behavior, attribution expectations, or the default-wiki behavior, leaving important operational context to the schema alone.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including the base64 data field. The description adds no meaning beyond what the schema provides; it merely repeats the base64 encoding requirement.

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

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

The description names a specific verb and resource: upload a file to the wiki. It also specifies the input mechanism, base64-encoded data, which implicitly separates it from upload-file-from-url, but it does not explicitly name or contrast with that 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?

The description implies use when the file content is available as base64, but it gives no explicit when-to-use guidance, no prerequisites, and no named alternative such as upload-file-from-url. An agent must infer the selection criteria from the input format alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the server-side fetch model (the wiki server, not the client, downloads the file), but says nothing about authentication or permission requirements, overwrite behavior when the filename already exists, size limits, or failure modes for unreachable URLs.

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

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

Two short sentences, front-loaded with the action and resource, with the second sentence adding only the mechanism that distinguishes it from the sibling tool. No filler.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the definition is adequate but thin: it omits conflict/overwrite semantics, permission needs, and any notion of what the call returns (e.g., the created file reference). The schema covers the inputs, so the remaining gap is behavioral rather than structural.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, including the attribution note on 'user' and the wikitext hint on 'description'. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Upload a file to the wiki') and adds the distinguishing mechanism ('by fetching it from a URL'), which separates it from the sibling upload-file. It never names that sibling explicitly, so an agent must infer the routing, but the purpose itself is unambiguous.

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

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

Usage is only implied: the 'fetching it from a URL' clause suggests this is for remote sources rather than local files, but there is no explicit when-to-use statement, no mention of the alternative upload-file, and no prerequisites or exclusions.

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