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 key behaviors beyond the basic create action: the root folder default and the idempotency-like error handling (if folder exists, error suggests reuse). It does not cover permissions or return format, but for a create operation these are less critical and the given behavior is valuable.

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, front-loaded with the primary purpose and followed by a key error-handling note. Every word contributes value, with no redundancy or clutter.

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

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

The tool is simple and the description covers purpose and main behavioral quirk. However, it does not mention what the tool returns on success (e.g., folder ID or object), which could be important for an agent without an output schema. It also omits any mention of permissions. These gaps lower the score below what would be fully complete for a creation 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?

The input schema already describes all three parameters fully (slug pattern, parentFolderId default and meaning, name default). The description adds little beyond the schema, aside from reinforcing the root default via 'parentFolderId 0 = root'. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Create') and resource ('asset folder'), and includes the key distinction of a parent folder relationship with 'parentFolderId 0 = root'. This unambiguously differentiates it from sibling tools like wiki_create_page or wiki_upload_asset.

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 usage context: it specifies that the folder is created under a parent, clarifies root semantics, and gives guidance on how to handle the 'already exists' error (reuse the existing folder). It does not explicitly mention alternatives or exclusions, but no direct alternative exists among siblings, so this is sufficient.

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

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

No annotations are present, so the description carries the full burden. It discloses important behaviors: local path validation rules (no dots, spaces, backslashes, double slashes) and the specific error behavior when a page already exists. While it doesn't mention auth or rate limits, the disclosed details are meaningful and go beyond what the name implies.

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 exceptionally concise: two sentences that lead with the core purpose, then add high-value details about path validation and the existing-page error. Every sentence earns its place, with zero waste.

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 has 7 parameters, no output schema, and no annotations, the description is quite complete. It explains the main edge case (existing page) and the path restrictions. While it doesn't describe the return value or all possible side effects, the schema covers parameter semantics, and the description handles the key contextual nuance. This is solid 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?

Schema coverage is 100% with descriptions for all 7 parameters, so baseline is 3. The description adds minimal extra meaning beyond the schema, only reinforcing the path validation rule. It doesn't elaborate on tag usage or other parameters, but the schema already covers them sufficiently.

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 the exact action ('Create a new markdown page') and resource ('in the ok-wiki at the given path'). It also distinguishes from the sibling tool by noting that existing pages should be edited via wiki_update_page, so it's clear what this tool uniquely does.

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

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

The description explicitly tells when to use this tool (for new pages) and when not to (if the page exists, use wiki_update_page). It even names the alternative tool, providing strong usage guidance.

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

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

With no annotations, the description carries the full transparency burden. It discloses important behavioral traits: updatedAt is a conflict checkout stamp (not just a timestamp), contentTruncated indicates body cut off, and specific permissions (manage:pages and read:source) are required. This goes well beyond a minimal description, though it stops short of detailing error handling or a complete return 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?

Three sentences, front-loaded with the main purpose, followed by critical caveats (conflict stamp, truncation, permissions). Every sentence earns its place with no redundancy or filler.

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

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

For a read tool with no output schema, the description explains key return fields (updatedAt, contentTruncated, content), the identifier alternatives, and permission requirements. It is sufficiently complete for an agent to invoke correctly, though a fully exhaustive return field list is not included.

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 four parameters with 100% coverage, including the exactly-one-of rule and locale semantics. The description adds no new parameter-level details beyond reinforcing that path requires locale, so the baseline of 3 is appropriate.

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

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

The description specifies the exact action ('Fetch a single ok-wiki page') and the two lookup modes (numeric id or path+locale). It clearly distinguishes this from sibling list/search tools by emphasizing 'single' page retrieval with metadata and markdown 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 clear usage context: fetch a page when you know its id or path, and pass the result to wiki_update_page to avoid stale edits. It also notes permission prerequisites. However, it does not explicitly enumerate alternatives or when-not-to-use scenarios, though this is implied by the single-page scope.

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 reveals that content is bounded by WIKI_MAX_CONTENT_BYTES and that when truncated, the result includes a truncation marker and `contentTruncated: true`. This is valuable transparency beyond what structured fields would show.

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 concise sentences with no fluff. The first sentence states the action and return fields, the second covers truncation behavior and a usage example. 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 low-complexity tool with two well-documented parameters and no output schema, the description adequately covers return fields, truncation behavior, and a practical use case. It is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, with both parameters (pageId and versionId) already documented. The description adds no extra parameter-level meaning beyond stating that versionId should come from wiki_page_history, which the schema already mentions. 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 tool fetches one historical revision of a page as a full snapshot, listing the exact fields returned. It distinguishes from siblings like wiki_get_page (current version) and wiki_page_history (list of versions) by emphasizing 'historical revision' and 'full snapshot'.

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 an explicit use case ('Pair two calls to show a before/after when explaining a change') and references the truncation rule from wiki_get_page, which implicitly differentiates it from the current-page tool. It does not explicitly state when not to use it, but the context is clear.

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

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

With no annotations, the description carries the transparency burden. It discloses the exact return fields (id, filename, ext, kind, mime, fileSize, url) and highlights the URL prefix nuance for non-root folders, which is valuable for agent decision-making. It does not mention error cases or pagination, but for a simple list tool this is acceptable.

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 purpose. It packs essential details (return fields, URL nuance) without unnecessary words, earning 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 no output schema, the description sufficiently describes the return values and a key behavioral detail (URL root assumption). It omits potential pagination limits or invalid folder handling, but for a straightforward list tool with two optional parameters, it covers the main needs.

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 fully documents both parameters, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that folderId 0 is the root and that the returned URL assumes the root folder, requiring prefixing for other folders. This enriches the semantics of the folderId 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?

The description clearly specifies the action ('List') and the resource ('assets in a wiki asset folder'), with additional context that folderId 0 is the root. It inherently distinguishes itself from sibling tools like wiki_list_tags and wiki_list_pages by focusing on uploaded files.

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 usage context: it explains how folderId and kind affect results, and notes the URL behavior for non-root folders. It does not explicitly name alternatives, but the tool's unique purpose among the siblings makes when-to-use clear.

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

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

With no annotations, the description fully carries the transparency burden. It discloses the server-side vs client-side filtering split, the page-of-results limitation, and the return shape ({ pages, count }). The warning that a page may be outside the first `limit` rows is exactly the kind of behavioral nuance needed.

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, no filler. The first sentence states purpose and typical scenarios; the second covers the critical filtering behavior and return shape. 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 list tool with no output schema, the description covers the essential return value ({ pages, count }), explains the key filtering semantics, and flags the limit-related pitfall. It is complete given the tool's complexity and rich schema.

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

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

Although schema coverage is 100% and baseline is 3, the description adds crucial meaning beyond the schema: it explains that `pathPrefix` filters the fetched page only, not the whole wiki, and that tags are applied server-side before the limit. This elevates parameter understanding significantly.

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/enumerates wiki pages and distinguishes it from search: 'without a search query' with concrete use cases ('what's under projects/?' or 'what's tagged runbook?'). The verb '+resource' specificity combined with sibling differentiation earns 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?

Explicitly frames when to use this tool ('without a search query') and gives real-world examples. It also provides operational guidance about pathPrefix being a client-side filter over only the fetched page, with an explicit caveat to raise limit or sort by PATH before concluding a prefix is empty. This is clear context with implied exclusions from search 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?

With no annotations, the description carries the full burden. It discloses the return format as '{ tags: [{ tag, title }] }' and explains the semantics of 'tag' vs 'title'. It does not mention permissions, errors, or ordering, but for a simple read-only list operation, this is sufficient context beyond what the schema provides (empty 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 two sentences, front-loaded with the core purpose, followed by a clear usage directive. No filler or repetition—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 simple tool with no output schema, the description fully compensates by specifying the return structure, field semantics, and when to invoke it. The guidance about avoiding near-duplicate tags provides important context. No critical information is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the output format rather than parameter details, which is unnecessary here. It adds value by describing the returned fields and their meaning.

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

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

The description clearly states the tool's function: 'Lists the wiki's entire tag vocabulary' with a specific verb and resource. The word 'entire' distinguishes it from sibling wiki_search_tags, which presumably returns a filtered subset.

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 before creating or retagging a page so new pages reuse the existing vocabulary.' However, it does not explicitly name alternatives or state when not to use this tool (e.g., when a quick search is more appropriate), so it misses the full 'when-not/alternatives' criterion for a 5.

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 of behavioral disclosure, and it exceeds expectations. It reveals important quirks: 'a restore shows as an edit here, and the snapshot it created reports action 'restored' via wiki_get_page_version,' and the attribution limitation: 'every edit made through this connector is attributed to user id 1 ('API')... cannot tell one agent session from another.' These are non-obvious behaviors that go beyond typical parameter descriptions.

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, focused paragraph that contains no fluff. It front-loads the core purpose, then efficiently covers output details, behavioral nuances, and a pointer to a related tool. Every clause adds value, and the structure is logical.

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 there is no output schema, the description comprehensively explains the return fields, total count, and edge cases. It also provides guidance on how to drill into a specific version via wiki_get_page_version. For a list-history tool with moderate complexity, this is a fully complete description that covers all necessary context.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters (id, limit, offsetPage), giving a baseline of 3. The description adds meaningful context beyond the schema by explaining that `total` in the result is the true version count, which is essential for understanding limit/offset pagination and slice semantics. This elevates the score to 4.

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

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

The description clearly states the tool's function: 'List the revision history of a page' and enumerates the output fields (versionId, versionDate, authorName, actionType). It explicitly distinguishes this from the sibling tool wiki_get_page_version by noting that versionId should be passed to that tool for snapshot inspection. This is a specific verb+resource with clear sibling differentiation.

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

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

The description provides strong usage context by explaining the meaning of `total` for distinguishing sliced trails from the full history, and it directs users to the alternative tool for snapshot inspection ('Pass a versionId to wiki_get_page_version to inspect a snapshot'). However, it does not explicitly state when NOT to use this tool or provide a full when/when-not structure, so a 4 is appropriate.

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 fully carries the transparency burden. It explicitly discloses the non-destructive behavior: 'appends a new version to the page’s history rather than erasing anything,' that intermediate edits remain, and that a mistaken restore can itself be restored. These are behavioral traits not derivable from the tool name or 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 three sentences, each earning its place: purpose, behavioral clarification, and usage workflow. It is front-loaded with the core function and remains concise without fluff.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential context: what it does, the nature of the operation, and how to obtain the required inputs. It could mention the return format or permissions, but these are not critical for a basic restore operation. The non-destructive nuance 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 coverage is 100%, so the baseline is 3. The description adds minimal parameter insight beyond the schema: it reiterates that versionId comes from wiki_page_history, which the schema already states. No additional semantic detail is provided for pageId or versionId.

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

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

The description opens with a specific verb+resource: 'Roll a page back to an earlier version from its history.' It also distinguishes the tool from siblings by calling it 'the undo for everything else this connector can do,' making its role unique among the listed tools.

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 usage context: retrieve the versionId from wiki_page_history and preview with wiki_get_page_version before restoring. It implies the appropriate workflow and positions the tool as a general undo mechanism, though it doesn't explicitly state when not to use it or name alternatives beyond the preview/history 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?

With no annotations, the description carries the full burden. It discloses the non-semantic substring matching, the fields searched, the return shape, and the relationship between limit and totalHits. This is substantial and well beyond a minimal disclosure, though it omits potential error cases or rate limits, which are less critical for a search 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 purpose, and every clause adds value. It explains behavior, return format, and usage without redundancy, making it highly efficient for an agent to parse.

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

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

Given no output schema, the description compensates by specifying the return object fields and the significance of totalHits. It also covers matching behavior, field scope, and usage context, making it complete for a search tool with three parameters. No critical gaps remain.

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 reinforces the query semantics (literal words, substring matching) but does not add new parameter meaning beyond what the schema already provides. The limit/totalHits relationship is already documented in the schema, so the description adds marginal value.

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

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

The description clearly states the tool performs full-text search across wiki pages, with a specific verb ('search') and resource ('ok-wiki pages'). It differentiates from siblings by positioning itself as 'the first tool to reach for when asked about anything in the wiki' and clarifies it matches title, description, and path, distinguishing it from tag-specific search.

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

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

The description gives clear context on when to use the tool ('first tool to reach for') and how to use it effectively (use literal words, not paraphrases). It does not explicitly name alternatives or exclusion cases, but the behavioral guidance is strong enough for an agent to select it appropriately.

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 of behavioral disclosure. It clearly indicates a read-only search operation and specifies the return format, which is valuable. However, it does not detail matching behavior (e.g., case sensitivity, partial matching) or potential edge cases, though these are minor for a simple search.

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 output, the second provides valuable usage context. There is no redundancy or filler, and the 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 1-parameter read-only search tool, the description gives enough context: purpose, output shape, and when to use it. The lack of an output schema is compensated by the explicit return type, making it largely complete, though minor details like search matching rules are left to the schema.

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

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

The schema already provides 100% coverage of the query parameter with a description and example ('dep' to find 'deployment'), so the description does not add parameter semantics beyond the schema. Per the baseline rule for high schema coverage, a score 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 clearly states the tool searches the existing tag vocabulary and returns matching tag slugs, with the specific output shape { tags: string[] }. It distinguishes itself from the sibling tool wiki_list_tags by emphasizing 'search' and 'matching' rather than listing, making the purpose unambiguous.

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

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

The description explicitly recommends using this tool before creating a page to check for near-duplicate tags, which is clear contextual guidance. However, it does not mention when not to use it or propose alternative tools like wiki_list_tags for other scenarios, so it lacks explicit 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?

With no annotations, the description fully carries the behavioral burden. It discloses how the patch works ('reads the current page, checks for concurrent edits, merges only the fields you supply, and writes the complete page back'), what is preserved, that tags replace the whole list, and that a no-op writes nothing. This is rich, safety-relevant context.

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

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

The description is a single, dense paragraph that front-loads the essential purpose and then explains behavior. Every sentence adds value—covering the patch mechanism, preservation guarantees, tag-replacement caveat, and what the tool doesn't do. No filler or redundant repetition of schema.

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 tool's behavior, safety model, and exclusions comprehensively. It doesn't explicitly state the need to provide exactly one of id or path, though that is captured in the schema parameter descriptions. Also, the mention of preservable fields like 'publish window' and 'scripts' could be slightly confusing since those aren't in the editable parameter set, but overall it's complete enough for correct use.

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

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

Schema coverage is 100% and each parameter has a description. The tool description adds cross-cutting semantics like the partial-patch merge behavior and preservation rule, which goes beyond individual parameter descriptions. However, the per-parameter meaning is already well covered by the schema, so a 4 rather than 5.

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 'Edit an existing wiki page with a partial patch, safely,' which is a specific verb+resource+behavior. It also explicitly distinguishes from other operations by stating 'This tool never moves, renames, or deletes a page,' setting it apart from sibling tools like wiki_create_page or wiki_restore_page_version.

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 clearly conveys when to use the tool: for editing an existing wiki page with a partial patch. It also provides a when-not by stating it never moves, renames, or deletes. However, it does not explicitly name alternative tools (e.g., 'use wiki_create_page for new pages'), which would warrant a 5.

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 burden. It discloses that the file is on the server, subject to size/allowlist constraints, and that returned URLs/markdown assume root folder. This is substantial behavioral context 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?

Three sentences, each adding distinct value: action+outputs, constraints, and folder-path caveat. 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?

With no output schema, the description names the return values (id, URL, markdown). It covers the main use case and important environmental constraints. It could mention error behavior, but for a simple upload tool with 3 parameters, it is adequately 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 descriptions cover all three parameters (100%), so baseline is 3. The description adds practical nuance about folderId: the returned url/markdown assume root, so non-root requires prefixing the folder path. This goes beyond the schema's simple default explanation.

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

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

Description clearly states the action (upload a local file to the wiki as an asset) and the outputs (id, URL, markdown reference). It distinguishes from sibling tools like wiki_list_assets and wiki_create_asset_folder by focusing on the upload operation.

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?

Description gives context (file read from the server, subject to WIKI_MAX_UPLOAD and WIKI_UPLOAD_ALLOWLIST) and a folder-path caveat. It doesn't explicitly contrast with alternatives, but as the only upload tool among siblings, the intended use is clear.

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