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

No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions that registration enables reading/editing and notes optional bot credentials, but it omits key details such as side effects (e.g., persistence, overwriting existing entries), error conditions, or whether the action requires special permissions. The description is thin on what actually happens during registration.

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

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

The description is two sentences, front-loaded with the core action, and each sentence adds value. The first states the purpose, the second explains how to use the added wiki. No wasted words or redundant details.

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 simple registration role and 4 parameters, the description covers the essentials: what it does and how to proceed. However, with no output schema and no annotations, it lacks information about expected outcomes (e.g., whether it returns an ID or success message) and potential pitfalls (e.g., duplicate names). It is adequate but not thoroughly 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% for all four parameters, each with a clear description (e.g., 'Base URL of the MediaWiki instance'). The description adds little beyond paraphrasing: it refers to 'wiki base URL' and 'optional bot credentials,' which duplicates schema info. It does not provide examples, formatting rules, or additional semantics, so it meets the baseline of 3.

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

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

The description clearly states the tool's function: 'Register a new MediaWiki instance so you can read and edit its pages.' It uses a specific verb ('Register') and a distinct resource ('MediaWiki instance'), setting it apart from sibling tools like remove-wiki and list-wikis. It also explains the follow-up usage, reinforcing its unique role.

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 context on when to use the tool: 'Register a new MediaWiki instance... After adding, use the wiki name in other tools' "wiki" parameter.' This implicitly tells agents to add a wiki before invoking read/edit tools. It doesn't explicitly mention alternatives or exclusions, but the usage context is unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It discloses a key behavior: the page must not already exist, implying the operation will fail or reject if it does. It also mentions the content format (wikitext). It does not detail auth requirements or return behavior, but for a create operation, the precondition is the most critical context and is 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?

Two sentences, front-loaded with the primary action and immediately followed by the critical constraint and alternative. No fluff; every word 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?

The schema covers all parameters fully, and the description covers the central behavioral constraint and usage guidance. It lacks an explicit statement of return values or error handling, but given the simple create operation and full schema coverage, the provided context is sufficient for selecting and calling the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter nuance: "wikitext" clarifies the content field, and "must not already exist" relates to the title. This is slight but doesn't substantially exceed what the schema already provides.

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

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

The description clearly states the action: "Create a new wiki page with wikitext content." It names the resource (wiki page), the verb (create), and the content format (wikitext). It also distinguishes itself from sibling by explicitly saying "use update-page to modify existing pages," which removes ambiguity.

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 to use this tool versus an alternative: "The page must not already exist — use update-page to modify existing pages." This gives a clear precondition and points to the sibling tool for existing pages, providing strong usage direction.

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. It discloses that deletion is permanent and requires admin/sysop rights. Yet it does not detail any further side effects (e.g., impact on history or associated files) or whether the deletion is reversible via undelete-page, making it only partially transparent.

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 consists of two concise sentences: the first states the action, and the second states the permission requirement. Every word is necessary, making it highly efficient.

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

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

Given the tool's destructive nature and lack of annotations, the description should provide more context about expected outcomes. While the permission and permanence are mentioned, there is no guidance on success/failure responses or broader consequences. The moderate complexity and complete schema coverage balance this, resulting in a mid-range score.

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

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

All four parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description itself adds no extra parameter context, thus the score remains at 3.

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

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

The description states 'Delete a wiki page permanently.' This is a specific verb (delete) and resource (wiki page), and the word 'permanently' distinguishes it from undelete-page. Clear and unambiguous.

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

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

The description notes 'This requires admin/sysop rights on the wiki,' which is a prerequisite for usage. However, it does not explicitly explain when to use this tool versus alternatives like undelete-page or page editing, leaving the decision to inference.

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

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

The description discloses the search order (exact -> prefix -> full-text), redirect following, cross-wiki default behavior, and ranking logic. This goes beyond a simple 'finds pages' and provides valuable behavioral context, especially since no annotations are present.

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 focused sentences that front-load the purpose, explain the algorithm, and give usage guidance. No redundant or filler content; 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?

Given the tool's moderate complexity and lack of an output schema, the description covers key aspects: matching strategies, ranking, cross-wiki scope, and usage recommendation. It does not specify the result list item structure, but the core behavior is well explained.

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

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

Schema descriptions already cover all parameters fully (100% coverage). The description adds reasonable context about how the query maps to different match types and how the wiki parameter defaults to all registered wikis, but this is more behavioral than parameter-level detail.

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 identifies the tool as a 'Unified page locator' and details its multi-strategy search (exact title, prefix, full-text) with a specific ranking order. This distinguishes it from sibling tools like search-page and search-page-by-prefix by emphasizing the unified approach.

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

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

It explicitly instructs to use this tool as the first step when locating any page, and notes it handles exact titles, partial titles, and topic descriptions. While it does not name alternatives explicitly, the recommendation is strong and implies its superiority for general page location.

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 burden of behavioral disclosure. It does state that the tool returns member titles and IDs, but it omits important behavioral traits such as pagination behavior, the effect of the 'limit' parameter, and how the continuation token works. The claim to 'List all' members is misleading given the default limit of 50, and no details about auth or rate limits are provided, leaving the agent underinformed.

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 and front-loaded, consisting of three short sentences. The first sentence states the core action and scope, the second describes the return value, and the third gives immediate usage guidance. Every sentence contributes useful information without 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?

The tool has 5 parameters, no output schema, and no annotations, so the description must compensate by explaining behaviors like pagination and limits. It does not mention that the 'limit' parameter caps results (contradicting the 'all' claim) or how continuing pagination works with 'continue_from'. The description also omits any mention of the 'wiki' parameter or error cases, making it incomplete for effective autonomous 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 description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it mentions the 'type' filter, which is already documented in the schema's enum, and the return type (titles and IDs) but does not explain parameter semantics like the 'category' prefix handling or how 'continue_from' is used. Thus, the description neither compensates for gaps nor adds significant meaning, aligning with 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?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('pages, subcategories, or files within a specific category'). It distinguishes itself from sibling tools like list-categories (which lists categories) and get-page (which retrieves a single page) by focusing on category members. The mention of returning member titles and IDs further clarifies the function.

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 context for when to use the tool (listing category members) and offers usage guidance for the 'type' parameter ('Use type to filter'). However, it does not explicitly mention alternatives or when not to use this tool, leaving some inference required from the sibling tool names. This meets the 'implied usage' level but lacks explicit exclusions or alternative references.

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 exist, so the description carries the full burden. It explicitly lists the return payload (dimensions, file size, media type, original and preferred-format URLs) and clarifies that it provides URLs rather than file content. It omits error cases and permissions, but for a read-only metadata operation the core behavior is well 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?

Two concise sentences that lead with the core operation and immediately list the returned data. No filler or redundant phrasing.

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 metadata getter with no output schema, the description adequately covers what the tool does and what it returns. It lacks edge-case handling or error behavior, but the essentials are present. The absence of annotations is partially offset by the explicit return field list.

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

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

Schema descriptions cover 100% of parameters (wiki and title), each with clear meaning. The description adds no parameter-specific semantics beyond the schema, 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?

The description clearly states the specific verb 'Get' and the resource 'uploaded file', with examples like image/PDF. It also notes it returns metadata and URLs, which distinguishes it from sibling upload tools such as upload-file and upload-file-from-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?

Usage is implied by the domain ('for an uploaded file') and the return values, but no explicit when-to-use or alternative tool guidance is provided. It does not mention when not to use it or compare to get-page, but the purpose is clear enough for basic selection.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns page title, ID, content model, latest revision ID/timestamp, and raw wikitext. However, it does not mention error behavior (e.g., missing pages) or authentication needs. For a read operation, this is decent but not exhaustive.

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

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

The description is three sentences, each providing essential information: what it does, what it returns, and when to use it. There is 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?

The description covers the core purpose, the return data (important since there is no output schema), and the main usage context. It is sufficient for an agent to decide when and how to invoke the tool without requiring additional details.

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 100% coverage for all three parameters (wiki, title, include_html), so the description doesn't need to add much. The description mentions 'full wikitext source' but does not elaborate on the parameters themselves, so it stays at 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?

The description clearly states the tool's function: 'Retrieve a wiki page's full wikitext source and metadata' and lists specific return values. It also distinguishes from siblings by advising to use it 'BEFORE update-page', making it clear this is for reading existing content.

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 'Call this BEFORE update-page to read the current content you want to edit.', providing a direct usage workflow and naming an alternative (update-page). This gives clear 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 transparency burden. It discloses the return fields (IDs, timestamps, authors, size changes, edit summaries) and pagination behavior, which is helpful. However, it does not specify sort order, error behavior, or authentication requirements, leaving minor gaps.

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, consisting of two sentences that front-load the primary purpose and then provide useful return and usage details. No redundant or vague wording.

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

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

For a read-only history tool, the description is complete: it specifies the output fields and pagination, while the schema covers all input parameters. There is no output schema, so listing the return fields is essential and well-handled.

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 schema already documents all parameters (100% coverage), so the baseline is 3. The description adds value by explaining that older_than is used for pagination, which is not explicit in the schema's description. This enriches 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 the tool retrieves the revision history of a wiki page, using a specific verb and resource. This distinguishes it from siblings like get-page (page content) and get-revision (single revision).

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

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

The description provides usage guidance for pagination with older_than, but it does not explicitly compare to alternative tools or state when not to use this tool. The context implies this is the tool for revision history, but no direct when/when-not guidance is 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?

With no annotations provided, the description carries the transparency burden. It discloses the directional behavior (outgoing vs. backlinks) and the return content (titles and namespaces). While it omits pagination details, the schema's continue_from parameter implies handling that is not fully explained, but the core read-only nature is evident from 'Get' and 'find'.

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 sentence that front-loads the purpose and gracefully includes the direction logic and return 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?

The tool is relatively simple with a detailed schema and no output schema. The description covers the primary function and return values, but lacks explicit pagination guidance or the exact structure of results. Given the absence of annotations and output schema, it is slightly incomplete but adequate for most use cases.

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 detailed parameter descriptions, so the baseline is 3. The description adds minimal extra meaning beyond the schema, mostly reinforcing the direction semantics and return output. It does not elaborate on wiki, limit, or continue_from beyond what the schema already states.

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

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

The description clearly identifies the tool's function: retrieving outgoing links (direction="from") or backlinks (direction="to"). It specifies the resource (page) and the output (link titles and namespaces), distinguishing it from sibling tools like get-page or 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?

The description explains the two operational modes with clear direction parameters, telling the user when to use 'from' versus 'to'. It does not explicitly mention alternatives among sibling tools, but the context is clear enough that no exclusions are needed.

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 return fields ('timestamps, change types, page titles, authors, size deltas, and edit summaries') and scope ('across wikis'), but does not mention pagination behavior, sorting, or that it is a read-only operation. With no annotations provided, the description carries the full burden, leaving some behavioral aspects undocumented.

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

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

The description is two sentences, front-loaded with purpose, then return data, then use case. Every sentence earns its place with no fluff, making it an ideal 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?

For a tool with 5 parameters, no output schema, and no annotations, the description is incomplete on behavioral aspects like pagination (continue_from token), default limits, and the time window for 'recent.' While schema covers parameter details, the overall workflow (e.g., how to iterate through pages) is not explained.

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 parameters are already documented. The description adds minimal parameter-level meaning beyond the schema; it mentions 'across wikis' which aligns with the wiki parameter but does not enrich understanding of parameters like 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?

The description clearly states the tool's purpose: 'Get a feed of recent edits, page creations, and log events across wikis.' This uses a specific verb (get) and resource (recent changes feed), and differentiates from siblings like get-page-history by emphasizing 'across wikis'.

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 a clear usage context: 'Useful for monitoring wiki activity.' It implies when to use the tool but does not explicitly state when not to use it or mention alternatives like get-page-history. This is clear context without formal 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?

No annotations are provided, so the description carries the burden. It discloses the return data, indicating a read-only operation, but it does not describe error behavior (e.g., when the revision ID is invalid) or any other limitations.

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 sentence that front-loads the action and lists the outputs efficiently. There is no waste 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?

The tool is simple with two parameters and no output schema. The description adequately lists the return fields, which is essential since there is no output schema. It could mention behavior for missing revisions, but the coverage is acceptable for a basic get operation.

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% for both parameters, so the baseline is 3. The description adds 'by ID' but this is already captured in the schema's parameter description. No additional semantic value 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?

The description uses a specific verb ('Get') and resource ('specific revision by ID'), and lists the concrete return fields (page title, timestamp, author, size, byte delta, edit comment). This clearly distinguishes it from sibling tools that handle pages or lists of revisions.

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 indicates this tool is for retrieving a single revision identified by ID, providing clear context for when to use it. It does not explicitly name alternatives like get-page-history or get-recent-changes, but the scope is evident from the phrasing.

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 burden. It discloses the core listing behavior and the counts returned, but omits the pagination behavior (continue_from) and the fact that 'list all' is subject to a limit. This could mislead agents into expecting exhaustive results.

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 three short sentences with no redundant wording. It front-loads the primary action and includes relevant details about counts and the prefix filter.

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 four parameters fully documented in the schema and no output schema, the description is largely complete. It explains what the tool does and suggests a use case. However, it misses the pagination nuance and the ability to omit wiki for all-wiki searches, which are documented in the schema but not highlighted in the 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 coverage is 100%, so the baseline is 3. The description does not add much beyond the schema; 'Use prefix to filter by name prefix' restates what the schema already says. No additional parameter semantics are provided.

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 categories with page/subcat/file counts, using a specific verb and resource. It distinguishes from siblings by focusing on category listing rather than category members or individual 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 provides clear context for use: 'Useful for discovering how content is organized.' It also gives specific usage guidance for the prefix parameter. However, it does not explicitly mention when not to use this tool or name 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?

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 provided, the description carries the full burden of behavioral disclosure. It explicitly states that the wiki itself is not affected and that removal is session-only, which are key non-destructive behavioral traits. It does not cover edge cases like non-existent names or error handling, but the core behavior is transparent and sufficiently detailed for a simple 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?

The description is two sentences, front-loaded with the primary action and followed by a clarifying caveat. Every sentence earns its place, and there is no fluff or redundancy. It is concise yet complete.

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

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

For a single-parameter tool with a simple action and no output schema, the description covers all essential aspects: what the tool does, what it does not do, and the session scope. It is fully complete for the complexity level.

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 describes the 'name' parameter as 'Name of the wiki to remove' with 100% coverage. The description adds minimal semantics beyond the schema, briefly implying that the name refers to a session-registered wiki, but it does not provide additional details such as exact matching, case sensitivity, or prerequisites. Schema coverage is high, so a baseline of 3 is appropriate.

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

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

The description uses a clear verb+resource pair ('Unregister a wiki') and specifically distinguishes what the tool does from what it does not ('Does not affect the wiki itself'). This differentiates remove-wiki from sibling tools like add-wiki and set-wiki, and clarifies that it only removes from the current session, not the underlying 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 provides clear context that this tool is for removing a wiki from the current session without affecting the wiki itself. It does not explicitly state when to use it versus alternatives (e.g., if there were a delete-wiki tool), but the scope clarification effectively guides the agent to use this when merely unregistering is needed.

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 of behavioral disclosure. It mentions return fields ('titles, IDs, and text excerpts') and search scope ('across wiki pages'), but does not disclose details like sorting, pagination, or wiki-filtering semantics. For a simple search tool, this is acceptable but not rich.

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

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

Three concise sentences, each earning its place: purpose, return value, and usage scenario. No filler or redundancy, and key information is front-loaded.

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 3-parameter search tool with no output schema, the description sufficiently covers purpose, return values, and use case. It could mention behavior like result ordering or wiki scoping, but the schema already covers the wiki parameter. The description is complete enough for an agent to select and invoke the tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (wiki, limit, query). The description adds context about query intent ('full-text search', 'don't know exact title') but does not add meaning 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?

The description clearly states 'Full-text search across wiki pages' with a specific verb and resource, and it lists return values ('matching page titles, IDs, and text excerpts'). It also distinguishes from siblings by noting it is for when you 'don't know the exact title', setting it apart from find-page and search-page-by-prefix.

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 guidance: 'Use this to find pages when you don't know the exact title.' This implies when to use the tool (fuzzy/full-text search) but does not explicitly name alternatives or state when not to use it. Sibling tool search-page-by-prefix exists but is not 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?

With no annotations, the description carries the full burden. It discloses that it returns matching page titles and IDs, notes the autocomplete-style behavior, and mentions performance, but it doesn't address authorization, ordering, case sensitivity, or no-result behavior. This is adequate but not comprehensive.

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 three concise sentences, each providing distinct value: purpose, return contents, and usage guidance. It's front-loaded with the primary purpose and has no redundant wording.

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

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

For a simple search tool, the description covers purpose, return format, and when to use it. The main gaps are not naming the alternative tool explicitly and not mentioning edge-case behavior, but overall it's sufficiently complete for an agent to select and 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?

The input schema already describes all 3 parameters with 100% coverage, so the baseline is 3. The description doesn't add extra semantic meaning beyond what the schema provides, such as clarifying the query as a prefix (already in schema) or how limit behaves.

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 for pages by title prefix (autocomplete-style), names the resource (pages) and the specific scope (title prefix), and differentiates from full-text search by noting it's faster when the beginning of the title is known. This distinguishes it from sibling tools like search-page or find-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?

It provides clear guidance on when to use it: 'when you know the beginning of the page title', and implies an alternative (full-text search) for other cases. However, it doesn't explicitly name the sibling alternative tool, which would strengthen the 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?

With no annotations, the description carries the burden. It discloses the global side effect of setting the default wiki (affects other calls with omitted 'wiki' param). It doesn't mention persistence or validation, but it's sufficiently transparent for a simple setter.

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, no filler. Every clause adds value, including the conditional context and the effect on other calls.

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

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

The tool is simple (1 param, no output schema). The description fully explains the purpose and the behavioral consequence. It's complete for its scope, though it doesn't cover edge cases like invalid names or persistence, which are not essential.

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 by linking the 'name' parameter to the 'wiki' parameter used elsewhere, clarifying that the name must be a registered wiki and that it becomes the fallback.

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 the specific verb 'set' plus the resource 'default wiki', and it explains the effect on other tool calls when the 'wiki' parameter is omitted. This clearly distinguishes it from siblings like add-wiki and remove-wiki.

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

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

The description gives clear context: 'When multiple wikis are registered' and explains the consequence for other calls. It implies when to use it, though it doesn't explicitly exclude alternatives or state when not to use it.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does disclose the admin/sysop permission requirement, which is valuable. However, it does not mention side effects such as whether history is restored, what happens if the page already exists, or error conditions for non-deleted pages, leaving some behavioral ambiguity.

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

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

The description is two sentences: the first states the core action, and the second provides a critical permission note. It is front-loaded, efficient, and contains no redundant 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 the tool's simplicity (4 params, no output schema, no nested objects), the description covers the essential purpose and a key prerequisite. It does not elaborate on return values or edge cases, but for a straightforward restoration action, the provided information is sufficiently complete for an agent to use it correctly in most scenarios.

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

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

All parameters (title, user, wiki, reason) are fully described in the schema with 100% coverage. The description adds no additional parameter-level information, so it does not exceed the baseline expected when the schema handles parameter documentation.

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

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

The description uses the specific verb 'restore' and identifies the resource as 'a previously deleted wiki page,' clearly distinguishing it from sibling tools like delete-page or create-page. The title 'undelete-page' aligns directly with this purpose, leaving no ambiguity.

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 clearly indicates the intended action (restoring a deleted page) and provides a key prerequisite (admin/sysop rights). While it does not explicitly mention alternatives like create-page or when not to use the tool, the context 'previously deleted' gives clear guidance for the appropriate use case.

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 of behavioral disclosure. It explains that in diff mode the server fetches current content, applies the patch, and saves; that append/prepend do not require reading current content; and that full replacement can be costly. While it doesn't cover auth or reversibility, it adds meaningful behavioral context beyond the bare schema.

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

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

The description is long but well-structured with clear sections: WORKFLOW, EDIT MODES, and WIKITEXT STYLE GUIDE. It is front-loaded with the core purpose and workflow. While the style guide is verbose, it is relevant for correct use with MediaWiki. The bullet lists and capitalization of key constraints improve scannability.

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 complex tool with 9 parameters and no output schema or annotations, this description is exceptionally complete. It covers the full workflow, all edit modes, essential constraints (use exactly one mode), and even provides a style guide for proper wikitext. It leaves no obvious gaps for an agent to misuse the 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. The description adds value by explaining the edit modes as mutually exclusive options and providing strategic guidance (e.g., diff preferred, content avoided for large pages). It clarifies the purpose of section numbers and the meaning of append/prepend, which enriches 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 opens with 'Update an existing wiki page,' which is a clear verb+resource statement. It distinguishes from siblings like create-page and delete-page by emphasizing 'existing' and outlining multiple edit modes. The specificity of update modes (diff, section, append, prepend, content) further clarifies the tool's scope.

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

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

Explicit WORKFLOW instruction says to first call get-page, then this tool. It also provides mode-specific guidance: diff for surgical edits, section for single sections, append/prepend when no need to read, and content for full replacement (with a warning to avoid for large pages). This clearly tells when to use the tool and how to choose among its modes.

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 only states the action ('upload') and the input format (base64), but does not disclose side effects, permission requirements, overwrite behavior, or response details. This is insufficient for a mutation 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?

The description is two short, direct sentences with no filler or redundancy. The main verb and resource are front-loaded, making it easy to scan.

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

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

With no annotations and no output schema, the description should provide broader context. It fails to mention prerequisites, error conditions, or the return value of a successful upload. For a tool with six parameters, this is insufficient.

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 with clear definitions. The description repeats the base64 detail but adds no additional meaning beyond the schema, earning the baseline of 3.

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

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

The description clearly states the tool's verb ('Upload'), resource ('a file to the wiki'), and method ('from base64-encoded data'). This distinguishes it from the sibling tool 'upload-file-from-url' by specifying the data source.

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

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

The description provides no guidance on when to use this tool versus alternatives like upload-file-from-url. It does not mention prerequisites, conditions, or scenarios that would favor this approach.

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 transparency burden. It does disclose the non-obvious behavior that the wiki server downloads the file directly from the source URL, but it omits critical details such as required permissions, overwrite behavior, authentication needs, or error handling. For a mutation tool, this lack of disclosure is a significant gap.

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

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

The description is two short sentences that immediately state the action and mechanism. It contains no filler or repetitive information, making it highly concise and well-structured. Every word 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 write operation with no annotations and no output schema, the description is too minimal. It does not explain return values, failure modes, required permissions, or what happens on success. The schema covers parameters, but the overall context of using the tool in a workflow is incomplete.

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 schema covers 100% of the parameters, each with a description (e.g., 'url', 'filename', 'description'). The tool description adds no extra meaning to the parameters, so it relies on the schema for semantics. A baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool uploads a file by fetching from a URL, using the specific verb 'upload' and resource 'file'. It distinguishes from the sibling 'upload-file' by explicitly noting the wiki server downloads from a source URL, making the tool's 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 implies usage for remote file uploads, emphasizing the wiki server fetches the file directly from a URL. However, it does not explicitly compare with the sibling 'upload-file' or state when not to use it, though the context of URL fetching is clear.

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