Server Quality Checklist

Tool Scores

• create_asset_folderB
  3/5.0
  Behavior2/5

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

  The annotations provide only idempotentHint=false, so the description carries the burden of explaining effects. It does not disclose what happens on duplicate slugs, whether parent_folder_id must exist, or what the response contains, leaving important behavioral traits ambiguous.

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

  Conciseness4/5

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

  Two short sentences with no filler, and the core purpose is front-loaded. The second sentence adds relevant context about the slug, earning its place.

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

  Completeness2/5

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

  For a mutation tool with no output schema, the description should explain return value and edge cases (e.g., duplicate slug, invalid parent_id). It contains neither, so an agent cannot fully predict the outcome of the call.

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

  Parameters4/5

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

  All three parameters are fully documented in the schema (100% coverage), so the description only needs to add extra meaning. It adds a useful clarification that the slug appears in the URL of every file inside the folder, which goes beyond the schema's 'URL segment' description.

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

  Purpose4/5

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

  The description states a clear verb ('creates') and a specific resource ('a folder in the asset store'), which distinguishes it from sibling operations like list_asset_folders, upload_asset, or delete_asset. However, it does not explicitly name a sibling or contrast path, so it stops short of the best-practice standard.

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

  Usage Guidelines2/5

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

  No guidance is given on when to choose this tool over alternatives, such as list_asset_folders (reading) or upload_asset (adding files). The only usage hint is that the slug affects all file URLs, which is more of a naming tip than a selection criterion.

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

• list_usersB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context that email addresses are returned because they are the login and explains how providerKey maps to login methods, but it does not disclose pagination behavior, default ordering, or response shape. This is acceptable for a simple read tool but not richly transparent.

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

  Conciseness4/5

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

  The description is concise and front-loads the core purpose in the first sentence. The providerKey clarification is relevant but slightly jargon-heavy; still, every sentence earns its place.

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

  Completeness3/5

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

  For a read-only listing tool with no output schema, the description gives some output context (emails, providerKey) and annotations cover safety. However, agent-facing gaps remain: no pagination/default-limit clarification, weak order_by semantics, and no guidance on when to use search_users instead. The misleading 'page lists' note in the limit description further reduces completeness.

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

  Parameters2/5

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

  Schema description coverage is 67% (limit and filter have descriptions; order_by does not). The tool description adds no parameter semantics of its own. The limit description is partly off-topic for users, referencing tags, locale, and path, so the description does not compensate for the moderate schema gap.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Lists the wiki’s user accounts.' This is clear and distinguishes it from mutation tools, but it does not differentiate it from the sibling search_users, which also deals with user lookup.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use list_users versus search_users or get_user. The providerKey explanation is context, not usage direction, and the limit parameter's schema description even veers into page-list terminology ('Wiki.js has no offset for page lists'), which is misleading for a user list tool.

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

• rename_assetA
  3.6/5.0
  Behavior4/5

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

  The description discloses a meaningful side effect beyond the idempotentHint annotation: 'Pages embedding it by its old URL will break — Wiki.js does not rewrite them.' This gives the agent important context that the operation is not just a label change. It does not contradict the idempotentHint annotation.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. The main action is stated first, followed immediately by the critical side effect, making it easy to parse and act on.

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

  Completeness4/5

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

  For a simple three-parameter tool with full schema coverage, the description covers the most important behavioral caveat. The confirm_token workflow is documented in the schema, so the absence of it in the description is not a serious gap. A short note about the token confirmation flow would make it fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and each parameter already has a useful description, including the confirm_token flow. The tool description itself adds no further parameter-level detail, so the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Renames an asset.' This clearly identifies the tool's function. However, it does not differentiate this tool from related siblings like upload_asset or delete_asset beyond the name, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to choose rename_asset over other asset tools, nor any prerequisites or exclusions. The only implied usage is 'use this when renaming an asset,' which is not enough to satisfy the when-to-use dimension.

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

• move_pageA
  3.7/5.0
  Behavior4/5

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

  The description discloses the critical non-obvious side effect that internal links to the old path are not rewritten, which is valuable and not present in the annotations. This directly informs the agent's pre-call decisions. It does not mention the output or confirm-token flow, but idempotentHint=false already signals the non-idempotent nature.

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

  Conciseness5/5

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

  The description is two focused sentences with the core move semantics first and the important caveat second. There is no filler, tautology, or unnecessary repetition of parameter details already covered by the schema.

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

  Completeness3/5

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

  The core operation and the main side effect are covered, and the schema fully documents parameters. However, with no output schema and no explicit prose about the two-call confirm-token execution flow, the agent must infer the exact response shape and call sequence, which is a notable gap for a mutating tool.

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

  Parameters3/5

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

  The input schema has 100% description coverage with detailed explanations for all six parameters, including path formatting, locale defaulting, and the confirm_token workflow. The prose description only restates the high-level effect and therefore adds little beyond the schema.

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

  Purpose4/5

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

  The description states a specific action, "Moves a page to another path, another locale, or both," which clearly identifies the resource and the operation. It differentiates from content-editing tools like update_page by focusing on page identity and location, though it does not explicitly name a sibling alternative.

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

  Usage Guidelines3/5

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

  The warning to check list_page_links first when link integrity matters is a useful conditional guideline for safe use. However, the description does not explicitly contrast this tool with alternatives such as update_page or migrate_pages_locale, so the agent must infer when move_page is preferred over other page operations.

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

• list_groupsA
  3.8/5.0
  Behavior4/5

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

  The readOnlyHint annotation already marks the operation as read-only. The description adds behavioral detail beyond that: the response includes per-group user counts, and isSystem groups are built-in permanent groups. This is meaningful context and does not contradict the annotation.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. The first sentence states the core purpose and output, and the second adds an important caveat about system groups. Every sentence earns its place.

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

  Completeness3/5

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

  For a simple read-only list tool, the description covers the main output and an important caveat. However, there is no output schema and no parameter documentation, so an agent cannot determine filter semantics, default ordering, or the exact shape of the returned group data.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not explain filter or order_by at all. The enum values for order_by are somewhat self-explanatory, but filter's meaning and any defaults are left completely unspecified, so the description fails to compensate for the schema gap.

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

  Purpose5/5

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

  The description clearly states the action ('Lists'), the resource ('the wiki's groups'), and the specific output detail (how many users each group has). It also names the system groups and their special status, which distinguishes this tool from sibling tools like list_users and delete_group.

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

  Usage Guidelines3/5

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

  The description gives useful context by warning that isSystem groups are permanent and should not be deleted, which implies when the result matters for deletion decisions. However, it does not explicitly state when to use this tool versus alternatives such as get_group or list_users.

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

• diff_page_versionsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds behavioral context: it returns a unified diff, treats an omitted to_version as a comparison against the live page, and collapses two page-body reads into one call. It doesn't discuss output formatting details or limits, so a 3 is appropriate.

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

  Conciseness5/5

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

  Two dense, front-loaded sentences with no filler. The first sentence states the core behavior and the optional mode; the second justifies the tool's value without repeating the schema.

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

  Completeness5/5

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

  Given the readOnly annotation, complete parameter schema, and simple scalar inputs, the description supplies enough context for correct invocation. With no output schema, naming the result as a 'unified diff' and covering the live-page comparison makes the return behavior sufficiently clear.

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

  Parameters3/5

  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 and the description need not document parameters. The one parameter behavior it mentions (omitting to_version compares with the live page) is already present in the schema's to_version description.

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

  Purpose4/5

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

  Description clearly identifies the operation: returns a unified diff between two page versions, with an optional live-page comparison. It doesn't name a sibling explicitly, but the verb+resource and the 'instead of two full page bodies' phrase make the purpose unambiguous compared with get_page_version and list_page_history.

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

  Usage Guidelines4/5

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

  The description gives a clear use case — answering 'what changed here' efficiently — and implicitly contrasts with fetching two full page bodies. It stops short of naming sibling tools or stating when not to use it, so the guidance is good but not exhaustive.

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

• convert_page_editorA
  4/5.0
  Behavior3/5

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

  Annotations only provide idempotentHint=true, so the description carries most of the behavioral burden. It adds a valuable caveat that Wiki.js does not translate the body during conversion, which is the most surprising behavior. However, it omits the two-phase confirmation flow implied by confirm_token and does not state whether converting destroys or irreversibly replaces the previous storage format.

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

  Conciseness5/5

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

  The description is three sentences with no filler. The core action is front-loaded, the critical translation caveat follows immediately, and the usage guidance closes with a clear boundary. Every sentence earns its place.

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

  Completeness4/5

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

  Given the 100% schema coverage and the idempotency annotation, the description covers the key use case and the most surprising conversion behavior. The main gap is the lack of explicit mention of the confirmation workflow and return values, but the input schema's confirm_token description compensates for that. No output schema is present, but the essential context for correct selection and invocation is provided.

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

  Parameters3/5

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

  Schema description coverage is 100%, so every parameter is already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, such as path format, locale identity, or the confirm_token workflow. Baseline 3 applies because the schema does the heavy lifting.

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

  Purpose5/5

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

  The description uses a specific verb ('Changes the storage format of a page') and clearly identifies the resource and the operation's scope. The 'not to reformat one' clause explicitly distinguishes this conversion-oriented tool from content-editing siblings like update_page or render_page, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description gives an explicit when-to-use ('correct a page created with the wrong editor') and a when-not-to-use ('not to reformat one'). It does not name a specific alternative tool, but the positive and negative guidance is clear enough for an agent to route correctly among the listed sibling tools.

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

• delete_tagA
  4/5.0
  Behavior4/5

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

  Annotations already mark destructiveHint=true, so the description adds useful context beyond that: the two-phase confirmation-token requirement and the reassurance that pages themselves are not deleted. This is meaningful behavioral disclosure.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: the primary effect, the non-destructive impact on pages, and the required confirmation token. No filler or redundancy.

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

  Completeness4/5

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

  The description plus schema covers the full workflow: effect, scope, and confirmation-token protocol. It is complete enough for an agent to call the tool correctly, though it could be slightly clearer about what the first unconfirmed call returns.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters are already well documented, including how confirm_token should be obtained. The description's mention of a confirmation token adds no new parameter-level meaning, so the baseline score of 3 applies.

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

  Purpose5/5

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

  States a specific verb and resource: 'Removes a tag from the wiki and from every page that carries it.' It also disambiguates scope by clarifying that pages themselves are untouched, distinguishing this from page-deletion and tag-update tools.

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

  Usage Guidelines3/5

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

  The intended use is implied clearly by the description—use this to globally remove a tag—and it mentions the confirmation-token prerequisite. However, it does not explicitly contrast with alternatives such as update_tag or explain when not to use this tool.

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

• restore_page_versionA
  4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds valuable nuance: current content is not lost but becomes a history entry, while the live page is replaced. It also discloses the confirmation-token requirement, which is not visible in annotations. This goes beyond the structured metadata without contradicting it.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The core action is front-loaded, followed by a crucial safety nuance and the required token. Every sentence earns its place, and the structure is easy to parse quickly.

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

  Completeness4/5

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

  Given the high schema coverage and available annotations, the description covers the essential purpose and effect. The only minor gap is that it doesn't outline the two-step confirmation flow, but the parameter schema already explains that omitting confirm_token returns a token. For a tool with no output schema and three simple parameters, the description is sufficiently complete when combined with the schema.

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

  Parameters3/5

  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 three parameters including the confirmation token's purpose and workflow. The description adds no new parameter-level meaning beyond stating that a confirmation token is required, which is already present in the schema. The baseline of 3 is appropriate given full schema coverage.

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

  Purpose5/5

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

  The description clearly states the specific action and resource: rolls a page back to a stored version, replacing the live page. It adds meaningful detail beyond the title by explaining that current content is preserved as a history entry, which distinguishes this from update_page or delete_page. The verb 'rolls back' and the explicit 'live page is replaced' remove ambiguity about the operation's effect.

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

  Usage Guidelines3/5

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

  The intended use case is implied: use this when you want to return a page to a prior version. However, the description does not explicitly contrast it with sibling tools such as update_page, get_page_version, or purge_page_history, nor does it state when not to use it. The confirmation token requirement is a procedural detail, not an alternative-selection guideline.

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

• update_commentA
  4/5.0
  Behavior4/5

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

  Annotations already mark this as destructive, and the description adds meaningful context: Wiki.js keeps no comment history, so the previous text is permanently lost. This goes beyond the annotation by explaining the consequence. It does not restate the annotations or contradict them.

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

  Conciseness5/5

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

  Two short sentences contain the essential action and the key consequence with no filler. The destructive caveat is front-loaded right after the main verb, making the description easy to parse.

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

  Completeness4/5

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

  The description is sufficient for a simple mutation tool: it states what is changed, that the change is irreversible, and the schema fully covers the confirm_token flow and parameter constraints. The only minor omission is an explicit note that a confirmation token may be needed before the replacement is actually applied, but that is already present in the schema.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents comment_id, content, and confirm_token with clear descriptions. The tool description adds no parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb ('replaces') and resource ('the body of a comment'), making the operation unmistakable. It also naturally distinguishes this tool from delete_comment (removes the whole comment) and create_comment (adds a new comment), even without naming them.

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

  Usage Guidelines3/5

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

  The description clearly implies this tool is for modifying the text of an existing comment, but it gives no explicit guidance about when to prefer it over create_comment or delete_comment. There is no direct mention of alternatives or conditions that would rule them out.

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

• delete_groupA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark the action destructive, and the description adds safety-critical context beyond that: member accounts survive while the access they got from the group is lost. It also discloses the two-step confirmation-token requirement, aligning with idempotentHint=false and adding value over the structured annotations.

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

  Conciseness5/5

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

  Three short sentences, each carrying distinct information: the action, the membership consequence, and the command prerequisite. It is front-loaded with the core operation and contains no filler or repetition.

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

  Completeness5/5

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

  For a destructive, non-idempotent delete operation, the essential invocation facts are all present: what is deleted, how members are affected, and how the confirmation token is obtained. There is no output schema, but none is needed for the agent to call and interpret the two-step flow correctly.

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

  Parameters3/5

  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 group_id as the numeric Wiki.js id and confirm_token as the token from the previous unconfirmed call. The description only restates the token requirement and does not add meaning beyond the parameter descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb-resource pair, 'Removes a group,' and immediately clarifies the boundary with user deletion by stating 'members keep their accounts but lose whatever access the group gave them.' This distinguishes delete_group from sibling delete_* tools and avoids ambiguity with update_group or unassign_user_from_group.

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

  Usage Guidelines3/5

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

  The use case is implied: this is the tool for permanently removing a group, and the confirmation-token line tells an agent what the call flow looks like. However, it never explicitly contrasts this with alternatives such as unassign_user_from_group or update_group, so a caller is not told when not to choose this tool.

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

• get_userA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so safety is established. The description adds value beyond that by disclosing exactly what the response includes and, importantly, that no credentials are ever returned because Wiki.js does not expose them. This is useful behavioral transparency for an agent deciding whether this call satisfies an information need.

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

  Conciseness5/5

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

  The description is two tight sentences with no filler. The core purpose and key inclusions are front-loaded, and the security-relevant caveat is stated efficiently at the end.

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

  Completeness5/5

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

  For a simple get-by-id tool with one well-documented parameter and a readOnly annotation, the description covers what the call returns, what it includes, and what it deliberately omits. An agent has enough information to invoke it correctly and interpret the result.

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

  Parameters3/5

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

  Schema coverage is 100%, and the single user_id parameter is already documented as the numeric Wiki.js id. The description does not add new parameter-level meaning, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description identifies both the verb and resource: retrieving full detail for one account. It distinguishes itself from sibling list/search tools by emphasizing 'one account' and specifying included information such as group memberships and two-factor authentication status.

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

  Usage Guidelines3/5

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

  The phrase 'one account' implies this tool is for single-user lookup rather than listing or searching, but the description never explicitly names alternatives like list_users or search_users. The usage context is clear enough to infer, but there is no direct when-to-use versus when-not-to-use guidance.

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

• list_search_enginesA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, so the safety profile is covered. The description adds non-obvious behavioral context about how the default search index only covers titles and descriptions, and that page contents may be unsearchable until an engine is configured and rebuilt. This goes beyond what annotations provide and warns the agent about a real limitation.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the tool's purpose, followed by a valuable caveat. No filler or repetition; every clause contributes meaning.

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

  Completeness4/5

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

  For a zero-parameter read-only listing tool, the description is sufficiently complete. It tells the agent why the tool matters and how it affects interpretation of search results. It does not describe the exact return shape, but no output schema exists and the semantics are simple enough that this is a minor gap.

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

  Parameters4/5

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

  The tool has zero parameters, and schema description coverage is effectively 100% by default. The description correctly does not waste space on parameters, so the baseline of 4 applies.

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

  Purpose4/5

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

  The description identifies the subject ('Which search engine this wiki uses') and connects it to the related search_pages tool, making it clear this is about the wiki's search backend. It is not a tautology and adds useful context, though it does not explicitly say 'list' or describe the exact set of returned engines.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on when to use this tool: before trusting search_pages results. It explains the default 'Database - Basic' limitation and the need for a real engine and rebuilt index, which helps an agent decide whether to rely on search results. It does not name alternatives explicitly, but the context is strong.

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

• search_usersA
  4.1/5.0
  Behavior3/5

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

  Annotations already mark readOnlyHint=true, so safety is covered. Description adds that search is by name-or-email fragment and that results are used to obtain ids, but doesn't disclose return format, multiple results, or pagination.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the verb and resource, then the use case. No filler.

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

  Completeness5/5

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

  For a single-required-param read-only search with full schema coverage, the description gives the agent enough to choose and call it correctly. It identifies what the id is needed for, and while no output schema exists, the resolve-to-id clue covers the essential return use.

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

  Parameters3/5

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

  Schema covers 100% of parameters and already describes 'query' as a name or email fragment. Description reinforces this by saying 'Finds users by name or email' and ties it to resolving ids, but adds no format or behavioral detail beyond the schema.

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

  Purpose5/5

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

  States a specific verb ('Finds') and resource ('users') and specifies matching by name or email. It differentiates itself from list_users/get_user by describing the intended resolve-to-id use case.

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

  Usage Guidelines4/5

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

  Directly instructs when to use: resolve a person to an id expected by list_pages and group tools. It doesn't explicitly name alternatives or exclusions, but the intended context is clear from the description.

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

• update_userA
  4.1/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description discloses that the groups list is replaced rather than merged, which is a nontrivial behavioral trait. It doesn't mention the confirm_token confirmation flow, but that detail is present in the input schema, so the description plus schema cover the key side effects.

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

  Conciseness5/5

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

  Two sentences put the action first and the critical caveat second, with no filler. The wording is compact while carrying necessary behavioral information.

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

  Completeness4/5

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

  For a mutation with no output schema, the description conveys the main side effect, the primary alternative, and enough overlap with the schema to guide correct invocation. It could spell out the two-call confirmation flow, but that is already encoded in confirm_token's description, making the overall package adequate.

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

  Parameters4/5

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

  Schema coverage is 57%, so the schema already describes four parameters. The description adds crucial semantics for groups (replaces, not appends) and links the tool to the assign alternative, clarifying behavior for that parameter. Name, location, and job_title are self-explanatory and need no extra prose.

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

  Purpose4/5

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

  The description states the operation ('changes an account's details or its group membership') with a clear verb and resource, going beyond the title. It doesn't enumerate every mutable field, but it names the core capabilities and flags the group-replacement behavior that distinguishes it from simple assignment tools.

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

  Usage Guidelines4/5

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

  It explicitly points to assign_user_to_group for a single addition, giving the agent a clear decision rule for an important alternative. It doesn't mention other sibling tools like set_user_active or reset_user_password, so the guidance is partial but not misleading.

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

• assign_user_to_groupA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide idempotentHint=false, so the description carries the behavioral disclosure burden. It adds meaningful traits: the operation is additive, not a replacement, and requires a confirmation token because group membership grants access. This goes well beyond the annotation, though it does not describe exact response behavior.

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

  Conciseness5/5

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

  Two sentences with every clause earning its place. The additive nature, the alternative, and the confirmation requirement are all stated without redundancy. The most important differentiator is front-loaded.

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

  Completeness4/5

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

  For a three-parameter tool with no output schema, the description covers the core action, the rationale for confirmation, and the relationship to update_user. It does not describe the return value or what happens if confirm_token is omitted, but the schema already covers the token mechanics, leaving only minor gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already fully documents user_id, group_id, and confirm_token. The description reinforces the two-step token flow but adds no new parameter-level detail beyond what the schema already provides, 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.

  Purpose5/5

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

  The description uses a specific verb and resource ('Adds one account to one group') and clearly differentiates it from update_user by calling it 'the additive counterpart to update_user's groups list.' An agent can immediately tell this tool from its siblings, including unassign_user_from_group.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use this tool: adding a single user to a single group while preserving existing memberships. It names update_user as an alternative and explains the confirmation-token prerequisite. It does not explicitly state 'do not use this when...' or mention unassign_user_from_group, so it misses the top tier.

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

• create_commentA
  4.2/5.0
  Behavior4/5

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

  With only idempotentHint=false in annotations, the description carries the behavioral burden. It discloses an important side effect: the comment is attributed to the API key's account, usually a service account. This goes beyond the schema and annotations and helps the agent set proper expectations.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The first sentence delivers the core purpose, and the second adds a relevant behavioral caveat. Every sentence earns its place.

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

  Completeness4/5

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

  The description covers the action, optional reply behavior, and an important identity/attribution detail, which is enough for a simple create operation. It does not describe the return value, but there is no output schema and the omission is minor for invoking this tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters are already well documented. The description adds the optional-reply context for reply_to and the attribution nuance, but does not add meaning beyond what the schema already provides for content and page_id. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Posts a comment on a page, optionally as a reply to another.' This clearly distinguishes it from sibling tools like update_comment, delete_comment, get_comment, and list_comments. The optional reply behavior adds useful precision without ambiguity.

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

  Usage Guidelines4/5

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

  The description gives a clear context for use: creating a comment, optionally as a reply. It also provides practical guidance about attribution to a service account and advises the agent to say so in the text when it matters. It does not explicitly enumerate exclusions or alternatives, but the context is clear enough for correct selection.

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

• create_groupA
  4.2/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond the annotations: the group starts with no permissions, no page rules, and grants nothing until update_group is called. This is valuable for an agent deciding whether creation alone is sufficient, and it goes beyond the idempotentHint=false annotation.

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

  Conciseness5/5

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

  Two sentences, no filler. The primary action is stated first, followed by one sentence of behavioral context that also names the relevant sibling tool. Every part earns its place.

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

  Completeness4/5

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

  For a simple creation tool with a single required parameter and no output schema, the description covers the essential semantics: what is created, its initial state, and the next step via update_group. It does not describe return values or duplicate-name behavior, but these are minor gaps given the tool's simplicity and the rich schema for the only parameter.

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

  Parameters3/5

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

  The only parameter, name, is already fully documented in the schema with a description and constraints (string, minLength 1, maxLength 255). The tool description adds no further parameter detail, so the baseline score of 3 applies because schema coverage is 100%.

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

  Purpose5/5

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

  The description opens with 'Creates an empty group,' naming a specific verb and resource and noting the initial state. It distinguishes the behavior from the sibling update_group by explaining that the new group needs further configuration before it grants anything.

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

  Usage Guidelines4/5

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

  The description clearly indicates that create_group produces an empty container and that update_group is required to add permissions or page rules. This implies when to use the tool and its relationship to the follow-up sibling, though it does not explicitly list exclusions or alternatives beyond update_group.

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

• get_page_conflictA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description aligns with that by saying it 'Returns' rather than mutates. It adds useful behavioral context beyond the annotation: the returned version is the conflicting newer one, and the response includes who saved it and when. No contradiction exists.

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

  Conciseness5/5

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

  Two tightly written sentences say exactly what the tool returns, why it exists, and what information is included. No filler or repetition of schema details.

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

  Completeness4/5

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

  For a simple one-parameter read-only tool, the description is largely complete: it explains the conflict context, the returned data, and the downstream use case. It stops short of describing exact output structure or null/error behavior, but the description gives enough for an agent to invoke it correctly in its intended scenario.

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

  Parameters3/5

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

  The only parameter, page_id, is fully documented in the schema with type and range, and schema coverage is 100%. The description does not need to add parameter-level detail, 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.

  Purpose5/5

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

  The description states a specific verb ('Returns'), a specific resource ('the version of a page that is newer than the one you read'), and clearly distinguishes this from ordinary page reads by tying it to update_page's conflict behavior. The title reinforces the same focused purpose.

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

  Usage Guidelines4/5

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

  The description gives an explicit trigger: use this when update_page refuses to write due to a conflict, so the newer change can be redone on top instead of discarded. It does not explicitly contrast with sibling get_page_version, but the conflict-specific context makes the intended usage clear.

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

• list_assetsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: assets are flat, there is no global search, and listing is confined to one folder (not recursive). It does not mention pagination or response shape, but for a read-only list operation the added constraints are valuable.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: the purpose is front-loaded, the root convention is stated, and the no-search navigation caveat is included. There is no fluff or redundancy.

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

  Completeness4/5

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

  The tool is simple, has complete schema documentation, and annotations cover the read-only safety profile. The description adds the key non-obvious context (flat assets, no search, need to walk folders) that an agent needs to use it correctly. It omits only optional details like result limits or exact return shape, which are minor for a list operation.

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

  Parameters3/5

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

  The input schema has 100% parameter description coverage: kind is fully explained and folder_id explains root behavior and provenance. The description echoes the folder root concept ('Folder 0 is the root') but does not add substantive parameter meaning beyond the schema, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('Lists the images and files in one asset folder') and immediately clarifies that folder 0 is the root. It also distinguishes list_assets from list_asset_folders by explaining that assets are flat and finding one requires walking folders.

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

  Usage Guidelines4/5

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

  The description gives clear context: this lists one folder, folders are navigated via list_asset_folders, and there is no search across assets. It does not explicitly state 'use list_assets when you need files in a known folder vs. list_asset_folders to enumerate folders,' but the intended usage is strongly implied.

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

• migrate_pages_localeA
  4.2/5.0
  Behavior4/5

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

  Annotations already flag destructiveHint=true, and the description adds meaningful specifics: every page path changes, all external links break, and a confirmation token is required. It communicates bulk whole-wiki scope beyond the schema, though it does not discuss reversibility or what happens to the source locale.

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

  Conciseness5/5

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

  Four short sentences, each adding distinct value: scope, typical use case, external consequence, and confirmation requirement. The action is front-loaded and there is no filler.

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

  Completeness4/5

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

  For a destructive bulk operation with no output schema, the description covers purpose, use case, consequences, and confirmation, while the schema covers parameter formats. It stops short of a 5 by not spelling out the two-step confirmation call flow or return behavior, though those are largely inferable.

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

  Parameters3/5

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

  Schema coverage is 100%, so the description does not need to explain parameters in depth. It mentions the confirmation token but adds no finer semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Moves all pages from one locale to another, across the whole wiki.' This clearly distinguishes it from the sibling move_page tool, which handles a single page, and the title reinforces the bulk scope.

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

  Usage Guidelines4/5

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

  It gives the canonical trigger ('usual reason is a wiki set up under the wrong locale code') and the major cost ('every external link into the wiki breaks'), which tells an agent when this heavy operation is appropriate. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

• purge_page_historyA
  4.2/5.0
  Behavior5/5

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

  Even with destructiveHint=true already present in annotations, the description adds critical non-obvious behavior: deletion is permanent ('gone permanently'), it applies wiki-wide, and it requires a confirmation token. This materially raises the caution level for an agent invoking the tool.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: the action comes first, followed by the permanence warning and the invocation prerequisite. There is no filler or repetition of what the schema already provides.

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

  Completeness4/5

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

  Given the rich enum schema and the confirm_token description, the definition covers what an agent needs to invoke the tool safely, including the non-reversible nature. It could be more explicit that the first call returns a token for the second call, but the schema already states that, so this is not a serious gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The older_than parameter is fully enumerated with ISO-8601 durations, and confirm_token's two-step behavior is documented in the schema. The description repeats 'confirmation token' but adds no extra parameter-level meaning.

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

  Purpose5/5

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

  The description opens with a specific verb, object, and scope: 'Deletes stored page versions older than a cutoff, across the whole wiki.' This goes beyond the title by adding the cutoff and whole-wiki semantics, and it clearly distinguishes the tool from siblings like list_page_history, get_page_version, and 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.

  Usage Guidelines3/5

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

  The description implies the maintenance use case ('this is the one maintenance operation that destroys data') and states the confirmation prerequisite, but it does not explicitly say when to choose this tool over alternatives or when not to run it. An agent has to infer the cleanup scenario from the title and first sentence.

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

• rebuild_page_treeA
  4.2/5.0
  Behavior4/5

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

  With only idempotentHint=false and no readOnly/destructive hints, the description carries the behavioral disclosure burden. It does disclose that this is a mutating repair operation and adds the important safeguard that a confirmation token is required. However, it does not explicitly state what is overwritten or warn about irreversibility, so it is strong but not fully transparent.

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

  Conciseness5/5

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

  The description is two efficient sentences. The primary action and trigger condition are front-loaded, and the confirmation-token requirement is stated as a short trailing clause. There is no filler or redundant elaboration.

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

  Completeness4/5

  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 two-stage confirmation flow, the description plus schema adequately explain when to use the tool, what the token is, and how to obtain it. The absence of an output schema leaves response shape undocumented, but that is not a blocking gap for an action-oriented repair tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the confirm_token parameter already explains that it comes from a previous unconfirmed call and can be omitted to receive one. The description only repeats the token requirement without adding new semantic detail, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states a specific verb and resource: it 'recomputes the folder structure Wiki.js derives from page paths' and labels itself as the repair for a navigation tree that disagrees with actual pages. This distinguishes it from read-only siblings like get_navigation_tree and from rebuild_search_index, since the focus is specifically on the page-path-derived folder structure.

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

  Usage Guidelines4/5

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

  The description gives a concrete when-to-use condition: use it when the navigation tree disagrees with the pages actually present, usually after a bulk import or database edit. It does not explicitly name alternatives or state when not to use it, so it falls just short of full usage guidance.

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

• render_pageA
  4.2/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description adds a meaningful safety guarantee: 'Changes no content and cannot lose anything.' This clarifies that the operation is non-destructive, which is valuable and not fully implied by idempotency. It does not discuss errors or side effects like cache invalidation, but the main behavioral trait is covered.

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

  Conciseness5/5

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

  Three short sentences, each with a distinct purpose: what it does, when to use it, and why it is safe. The information is front-loaded and there is no filler.

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

  Completeness4/5

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

  For a single-parameter, low-complexity tool, the description covers purpose, usage context, and safety. There is no output schema and the description does not explain the return value, but this is a minor gap for an action whose primary effect is the regeneration itself.

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

  Parameters3/5

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

  Schema description coverage is 100% and page_id is already documented as a 'Numeric Wiki.js id.' The description adds no new parameter-level meaning beyond tying the id to a page's source HTML, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description names a specific action and resource: 'Forces Wiki.js to regenerate one page’s HTML from its source.' It clearly identifies the affected resource (one page) and distinguishes this from broader rebuild/refresh operations like rebuild_page_tree or flush_page_cache.

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool: 'The fix for a page whose rendering is stale after a theme or renderer change.' It does not name alternative tools or explicitly state when not to use it, but the context is clear 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.

• reset_user_passwordA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide idempotentHint=false. The description adds valuable behavioral context: the tool sends an email, does not set or return a password, and requires a confirmation token for the follow-up call. This goes beyond the annotation and clarifies side effects.

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

  Conciseness5/5

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

  Three short sentences, each adding a distinct and necessary piece of information: what the tool does, what it does not do, and what is required. No filler or redundancy.

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

  Completeness4/5

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

  For a two-step token-based reset flow, the description covers the core behavior, side effect (email), and token requirement well. The schema handles parameter details. It does not state the return value explicitly, but the schema's confirm_token description already implies a token is returned when omitted.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both user_id and confirm_token already documented in the schema. The description reinforces the token workflow but does not add meaningful parameter-level meaning beyond what the schema provides, 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.

  Purpose5/5

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

  The description states a specific verb and resource ('Starts Wiki.js' own password reset for a local account') and explicitly clarifies that no password is chosen or returned, which distinguishes it from direct password-setting tools like update_user. The behavior is immediately clear.

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

  Usage Guidelines4/5

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

  The description explains the email-link reset flow and the need for a confirmation token, giving a clear sense of when to use this tool. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide selection.

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

• search_tagsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful behavioral context beyond that: the operation is fragment-based searching, is comparatively cheap, and supports a specific pre-filter workflow with list_pages. It does not detail return format or matching semantics, but for a read-only search with annotations, this is sufficient.

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

  Conciseness5/5

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

  Two concise sentences deliver the core function, performance advantage, and typical use case without repetition or filler. The most important information is front-loaded.

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

  Completeness4/5

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

  For a simple one-parameter read-only search tool with a 100% covered schema, the description is largely complete: it explains what the tool does, when to use it, and why it is preferable in certain cases. The only minor gap is that with no output schema, it does not explicitly describe the return value, though 'Finds tags' reasonably implies a list of matching tags.

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

  Parameters3/5

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

  The schema already describes the single required parameter 'query' well ('Fragment to match against tag names'), so schema coverage is 100%. The description does not add meaningful new parameter detail beyond the schema, landing at the baseline of 3.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Finds tags matching a fragment.' It also differentiates this from list_tags by noting it is 'cheaper than list_tags on a wiki with hundreds of them,' making the tool's scope and distinction clear.

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

  Usage Guidelines4/5

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

  The description gives clear context: it is 'the usual way to check what a tag is actually called before filtering list_pages by it' and is cheaper than list_tags on large wikis. It identifies the relevant sibling alternative but does not explicitly state when to prefer list_tags instead, so it falls just short of full explicit when-not guidance.

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

• set_user_tfaA
  4.2/5.0
  Behavior4/5

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

  Annotations only provide idempotentHint=false, so the description carries the behavioral burden. It discloses the security consequence of disabling 2FA, the enrollment trigger when enabling, and the requirement for a confirmation token — useful operational context beyond what annotations convey.

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

  Conciseness5/5

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

  Three tight sentences with no filler: the core action is front-loaded, the critical security caveat follows immediately, and the prerequisite is stated last. Every sentence earns its place.

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

  Completeness4/5

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

  The description covers the essential behavioral outcomes and prerequisite for a non-trivial two-phase token flow. It does not explicitly state the return value, but the schema's confirm_token description ('Omit it to receive one') sufficiently implies the response shape for an agent.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents enabled, user_id, and confirm_token clearly. The description reiterates the token requirement but adds little parameter-specific meaning beyond what the schema provides.

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

  Purpose5/5

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

  Description states a specific verb ('Switches') and resource ('account's second factor'), and explicitly covers both polarities (on/off). It is clearly distinct from sibling user-management tools like set_user_active or verify_user, which address different account state changes.

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

  Usage Guidelines4/5

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

  Provides clear usage context: turning off weakens the account and is gated; turning on forces enrollment at next sign-in. It lacks explicit 'when not to use' guidance, but no sibling tool targets 2FA, so the intended use is unambiguous.

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

• unassign_user_from_groupA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the operation destructive and non-idempotent. The description adds value by disclosing the confirmation-token workflow and the specific edge-case danger of removing someone from their only group, which goes beyond the generic annotation hints.

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

  Conciseness5/5

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

  Two compact sentences with no filler. The action comes first, and the critical caveat about confirmation and the 'only group' consequence is front-loaded and concise.

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

  Completeness4/5

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

  For a destructive two-step operation, the description covers the core risk and confirmation requirement. It does not explain return values, but the schema's confirm_token description already implies the first call returns a token, so no essential calling information is missing.

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

  Parameters4/5

  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 semantic meaning by clarifying that the operation can leave a user with no group and that a confirmation token is required, which helps the agent understand the user_id/group_id/confirm_token relationship beyond the schema's minimal id descriptions.

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

  Purpose5/5

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

  The description states a specific action and resource: 'Takes one account out of one group.' Combined with the title and tool name, it is unmistakable and differentiates from the sibling assign_user_to_group.

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

  Usage Guidelines3/5

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

  The description gives clear context about the destructive consequence but does not explicitly state when to use this tool versus alternatives, nor does it name the inverse operation assign_user_to_group. Usage is implied rather than explicitly routed.

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

• verify_userA
  4.2/5.0
  Behavior4/5

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

  With only idempotentHint=false in annotations, the description carries the behavioral burden and does add useful context: the normal user-click flow and the requirement of a confirmation token. It does not detail side effects like reversibility or notifications, but the key verification behavior is disclosed.

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

  Conciseness5/5

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

  Two tightly scoped sentences with no filler. The main action is front-loaded, and the token requirement plus normal-flow context each earn their place.

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

  Completeness4/5

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

  For a simple two-parameter mutation with full schema coverage, the description plus schema provide enough to invoke it correctly. It does not describe return values, but no output schema exists and the action's outcome is stated clearly.

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

  Parameters3/5

  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 user_id and confirm_token, including the important 'Omit it to receive one' behavior. The description adds no further parameter meaning beyond repeating the token requirement.

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

  Purpose5/5

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

  The description uses the specific verb 'Marks' and names the exact resource and outcome: 'an account’s email as verified.' This clearly differentiates it from sibling user-management mutations like update_user, set_user_active, or reset_user_password.

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

  Usage Guidelines4/5

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

  It explains that verification is normally done by the user clicking a link, implying this tool is for manual/admin verification, and it highlights the confirmation-token requirement. It does not explicitly name alternatives or say when not to use it, but the context is clear for such a focused action.

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

• flush_page_cacheA
  4.3/5.0
  Behavior5/5

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

  The description goes well beyond the idempotentHint=false annotation by disclosing that nothing is lost, every page must be re-rendered, busy instances slow down, and a confirmation token is required. This gives an agent a realistic picture of side effects, safety, and workflow.

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

  Conciseness5/5

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

  Three short sentences front-load the core action, then add consequences and the confirmation requirement. There is no filler, redundancy, or unnecessary restatement of the title.

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

  Completeness5/5

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

  For a simple one-parameter tool, the description covers the action, scope, side effects, safety profile, and confirmation requirement. The token mechanics are already documented in the parameter schema, and no output schema is needed for an agent to call this correctly.

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

  Parameters3/5

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

  The only parameter, confirm_token, is fully described in the schema ('Token from this tool’s previous, unconfirmed call. Omit it to receive one.'), so schema coverage is 100%. The description only repeats that a token is required and adds no new format or workflow detail beyond the schema.

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

  Purpose5/5

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

  States a concrete action: 'Drops Wiki.js’ rendered-page cache for the whole wiki.' It specifies the resource (rendered-page cache) and scope (whole wiki), which distinguishes it from sibling rebuild/purge tools like rebuild_search_index or purge_page_history.

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

  Usage Guidelines3/5

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

  The operational context is clear: pages are re-rendered on first access and a busy instance gets slower. However, the description does not explicitly say when to use this tool versus alternatives such as rebuild_page_tree or rebuild_search_index, so the usage guidance is implied rather than stated.

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

• get_commentA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, covering the operation's safety profile. The description adds value by disclosing what the response contains—source and rendered HTML—which is useful since there is no output schema. It does not detail error cases or missing-comment behavior, but the low annotation burden makes this acceptable.

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

  Conciseness5/5

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

  A single, directly structured sentence that communicates action, target, and return content with no filler. The key phrase 'single comment by id' is front-loaded, making the tool's purpose immediately scannable.

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

  Completeness5/5

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

  For a simple get-by-id tool with one fully documented required parameter and a readOnlyHint annotation, the description is sufficiently complete: it names the resource, the lookup key, and the returned content. No output schema is present, but the description compensates by stating the primary output fields.

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

  Parameters3/5

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

  The schema already fully documents comment_id with type, range, and description at 100% coverage. The description's 'by id' merely maps to this parameter and adds no new semantic detail beyond what the schema provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Returns') and names the exact resource ('a single comment by id'), further specifying the response shape ('with its source and its rendered HTML'). This clearly distinguishes it from comment collection or mutation tools like list_comments, create_comment, update_comment, and delete_comment.

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

  Usage Guidelines4/5

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

  The intent is clear: use this tool when you have a specific comment ID and want that one comment's data. It does not explicitly mention alternatives like list_comments for retrieving multiple comments, but the 'single comment by id' phrasing provides strong contextual guidance without exclusions.

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

• get_groupA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description adds value beyond that by disclosing what data the response contains: global permissions, page rules, and members. It also reveals an important workflow trait: update_group replaces the whole rule set, so this tool is the safe prerequisite read.

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

  Conciseness5/5

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

  Two sentences with no filler. The first sentence states the core behavior and result contents; the second provides essential workflow context about update_group. Every clause earns its place.

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

  Completeness5/5

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

  For a single-parameter read tool with a readOnlyHint annotation and no output schema, the description is complete: it identifies the resource, the returned components, and the practical reason to call it. An agent has everything needed to invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% and the only parameter, group_id, is already documented as 'Numeric Wiki.js id.' The description adds no parameter-level detail, so the schema carries the full burden. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Returns one group with its global permissions, its page rules and its members.' It also frames the tool as 'the authoritative answer to who can see or edit what', which clearly communicates its unique role among the siblings.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool: it is the authoritative source for group permissions and 'what update_group needs as its starting point.' It does not explicitly enumerate alternatives like list_groups or get_user, but the usage context is strong enough for an agent to route correctly.

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

• list_asset_foldersA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already covers the safety profile, and the description adds a meaningful behavioral detail: Wiki.js returns one level at a time, forcing repeated calls for deep trees. It also clarifies the special root sentinel (folder 0), which is not obvious from annotations.

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

  Conciseness5/5

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

  The description is two tight sentences with no filler. The core action and scope are front-loaded, and the one-level-at-a-time caveat is placed right after, earning its place as practical guidance.

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

  Completeness5/5

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

  For a simple read-only listing tool with one optional parameter, no nested objects, and no output schema, the description covers everything needed: what is listed, the root convention, and the traversal behavior. No critical operational detail is missing.

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

  Parameters3/5

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

  Schema coverage is 100%, and the schema already describes parent_folder_id including the default root behavior. The description repeats 'Folder 0 is the root' but adds no new parameter semantics beyond the schema, so it meets the baseline without exceeding it.

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

  Purpose5/5

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

  The description states a specific verb ('Lists') on a specific resource ('folders directly under an asset folder') and clarifies scope with root semantics. This distinguishes it clearly from sibling tools like list_assets or create_asset_folder, so an agent can tell what it does without opening the schema.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: it returns only immediate children, and 'a deep tree needs one call per level' tells the agent how to navigate. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a full 5.

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

• list_commentsA
  4.3/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds genuinely useful behavioral context: an empty response can mean comments are disabled, not just that there are no comments, and it points to get_site_info to resolve that ambiguity. No contradictions with the annotations exist.

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

  Conciseness5/5

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

  Two sentences front-load the core operation and addressing scheme, then append the important empty-list caveat. There is no filler, repetition of schema content, or extraneous detail.

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

  Completeness5/5

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

  For a low-complexity read-only tool with only two parameters, the description covers the key behavioral edge case and the unusual addressing rule. No output schema is present, but the return concept ('comments on one page') is clear enough for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  Schema coverage is 100%, and the schemas already document both parameters thoroughly, including path format, locale defaults, and locale patterns. The description reinforces the path-not-id nuance, but that is more of a usage hint than new parameter semantics, so it does not push the score above the baseline.

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

  Purpose5/5

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

  The description clearly states the operation ('Returns the comments on one page') and the exact addressing scheme (path + locale, not page id). It also distinguishes this tool from sibling page tools by highlighting the unusual path-based addressing, so an agent can separate it from list_pages and get_comment without inspecting schemas.

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

  Usage Guidelines4/5

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

  It gives clear context for when to use the tool and explicitly excludes page-id addressing, which is important for Wiki.js. It also names get_site_info as the way to disambiguate an empty list, giving a concrete alternative for that edge case. It does not enumerate every sibling alternative, but the context is sufficient for this simple read-only tool.

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

• list_localesA
  4.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it reveals that the tool reports both installed locales and the default, and explains a consequential fallback behavior tied to WIKIJS_LOCALE. This helps the agent understand why the result matters.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the tool's essential question, followed by a succinct, high-value rationale. Every sentence earns its place; there is no redundant or filler content.

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

  Completeness5/5

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

  For a simple read-only list tool with one optional parameter, the description plus schema fully covers what the agent needs: what is returned, when to call it, and why it is relevant to the surrounding page tools. No output schema is necessary for such a simple result.

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

  Parameters3/5

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

  The input schema already documents installed_only clearly with 100% coverage, including its default value. The description adds no additional parameter-level detail, so it meets the baseline but does not exceed it.

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

  Purpose5/5

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

  The description immediately states the tool's purpose: reporting which locales are installed and which is the default. It names the specific resource and the two distinct outputs, making it clearly distinguishable from sibling tools like list_pages or get_site_info.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: 'Worth checking once per wiki' and explains why it matters before using page tools, since they fall back to WIKIJS_LOCALE. It does not mention alternatives, but no obvious alternative tool exists for this operation.

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

• list_page_historyA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already establishes safety; the description adds useful behavior beyond that: newest-first ordering, contents ('who changed what and when'), distinctive pagination behavior, and the role of returned version IDs as inputs to other tools. No contradiction exists between the description and the annotation.

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

  Conciseness5/5

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

  The description is two tight sentences with no wasted words: the core operation and output content come first, then the crucial pagination and version-ID context. Every sentence earns its place.

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

  Completeness5/5

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

  For a read-only list tool with a fully described input schema, the description supplies the essential output semantics: what is returned, in what order, and how the returned IDs relate to sibling version operations. No output schema exists, but the description is sufficient 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.

  Parameters3/5

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

  All five parameters are fully described in the schema, which is 100% coverage, so the baseline is 3. The description adds some relevant context by emphasizing pagination and the downstream use of version IDs, but it does not provide per-parameter details beyond what the schema already states.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Lists the stored versions of a page, newest first, with who changed what and when.' It clarifies ordering and content, and the closing sentence ties this tool's output (version ids) to distinct sibling operations, so it is clearly differentiated from get_page_version, purge_page_history, and other history-related tools.

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

  Usage Guidelines4/5

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

  The note that 'This is the one Wiki.js query that really paginates' gives a clear behavioral cue for when this tool is appropriate, and the version-id link indicates the workflow: list history first, then pass IDs to get_page_version, diff_page_versions, or restore_page_version. It does not explicitly state exclusions or name a non-paginated alternative for simply retrieving one version, so it falls just short of a 5.

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

• create_userA
  4.4/5.0
  Behavior4/5

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

  With only idempotentHint:false in annotations, the description carries useful behavioral weight: it explains the invitation-vs-password path and that an account in no group can log in but see nothing. This goes beyond the schema. It does not mention permissions, duplicate handling, or what the response contains, but the annotation already signals non-idempotency.

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

  Conciseness5/5

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

  Three sentences, no filler. The core action is front-loaded, followed by the two most consequential decisions (password vs invitation and group assignment behavior). Every sentence earns its place.

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

  Completeness4/5

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

  For a tool with 8 parameters, no output schema, and minimal annotations, the description covers the key operational decisions and a notable behavioral consequence (blank visibility without groups). It omits a few details like must_change_password and confirmation-token usage, but the schema already documents several of those, so the overall context is sufficient for correct invocation.

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

  Parameters4/5

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

  Schema description coverage is 75%, so the schema already documents most parameters. The description adds valuable semantics for groups (IDs come from list_groups) and send_welcome_email (it replaces password for local accounts). However, it does not explain must_change_password or the exact confirmation-token flow, though the schema partially covers that.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: "Creates an account." It additionally clarifies the local-versus-invitation creation paths and the role of group IDs, so an agent can clearly distinguish this creation operation from the many user-management siblings like update_user, delete_user, and list_users.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use it and how to make key choices: supply a password for a local account, or set send_welcome_email for an invitation. It also points to list_groups for group IDs, which is helpful routing guidance. It does not explicitly name alternatives or state when not to use create_user, so it falls short of a 5.

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

• delete_commentA
  4.4/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses that deletion is permanent, that replies survive the deletion, and that a confirmation token is required. These are meaningful behavioral details that materially affect how an agent should invoke the tool.

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

  Conciseness5/5

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

  Three short sentences, each carrying essential information: the core action, the non-cascade behavior, and the confirmation requirement. No filler, and the most important information is front-loaded.

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

  Completeness4/5

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

  Together with the schema, the description fully explains the confirmation flow: call once without confirm_token to receive one, then call again with it. Since there is no output schema, the exact response shape is not specified, but the essential workflow is documented across the description and schema.

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

  Parameters3/5

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

  The input schema already provides 100% coverage with clear descriptions for comment_id and confirm_token, including the confirmation-token workflow. The description adds no parameter-specific meaning beyond what the schema already states, 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.

  Purpose5/5

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

  The description uses a specific verb ('Removes'), a clear resource ('a comment'), and a strong qualifier ('permanently'). It also differentiates itself from related comment tools by noting that replies are not removed, which prevents confusion with update_comment or get_comment.

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

  Usage Guidelines4/5

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

  The description clearly conveys the primary use case—permanently deleting a comment—and explains the important requirement of a confirmation token. It does not explicitly mention alternatives or exclusions, but the tool's scope is so specific that little ambiguity remains.

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

• get_page_treeA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral details beyond that: mode semantics for filtering folders/pages and the important caveat that wide levels are truncated to the result budget. This enriches the agent's understanding without contradicting annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: the core action and differentiation, the mode values, and the truncation caveat. The most important information is front-loaded, and there is no redundant wording.

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

  Completeness4/5

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

  For a read-only listing tool with no output schema, the description covers the key behavioral distinctions and result-budget truncation. It does not describe output fields or error behavior, but the schema and annotations provide enough support for correct invocation.

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

  Parameters4/5

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

  Schema description coverage is 75%, and the description compensates for the one undocumented parameter (mode) by explaining exactly what ALL, FOLDERS, and PAGES return. It does not add detail for path, locale, or include_ancestors, but those already have schema descriptions.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Lists the pages and folders directly under a path.' It also differentiates the tool from search by calling it 'the structural view a wiki has and a search does not,' making its role clear among siblings like search_pages and grep_pages.

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

  Usage Guidelines4/5

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

  The description gives clear context for when the tool is appropriate—when a hierarchical, structural view is needed rather than a search result. It does not explicitly name alternative sibling tools or state when not to use them, so it falls slightly short of full exclusions.

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

• get_page_versionA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, covering the mutation-safety profile. The description adds useful behavioral context by stating that the full historical body is returned and indicating that reading both versions is more expensive than diffing, though it does not discuss auth or rate limits.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The core behavior is front-loaded and the alternative-tool guidance is placed in a separate, clearly scoped sentence.

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

  Completeness4/5

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

  For a low-complexity read tool with a fully documented parameter schema and read-only annotation, the description covers the primary return characteristic (full body of the historical version). It could mention response shape more explicitly, but most needed information is present.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters already documented as the numeric Wiki.js id and the version id from list_page_history. The description adds no extra parameter-level meaning, so baseline 3 applies.

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

  Purpose5/5

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

  States the verb 'Returns' and the exact resource: 'a single historical version of a page'. It also clarifies the body is included and explicitly names diff_page_versions as the sibling for comparison, so the tool is clearly distinguished from related tools.

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

  Usage Guidelines5/5

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

  Gives explicit guidance: use this tool when you need one stored version with its full body, and use diff_page_versions instead when checking changes. The 'far cheaper than reading both' rationale makes the routing decision actionable.

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

• list_api_keysA
  4.4/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description adds valuable behavioral context: Wiki.js stores only truncated keys, never returns the secret, and therefore the output cannot be used to authenticate. This is a non-obvious limitation that prevents an agent from mistakenly treating the listed keys as usable credentials.

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

  Conciseness5/5

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

  Two sentences with no filler: the first states the action and output fields, the second adds a crucial security caveat. The main purpose is front-loaded, and every sentence earns its place.

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

  Completeness4/5

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

  For a zero-parameter, no-output-schema list operation, the description covers the key returned dimensions and the critical secret-handling limitation. It does not specify pagination or sorting, but these are minor omissions for such a simple tool.

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

  Parameters4/5

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

  There are zero parameters and the schema coverage is 100%, so no parameter documentation is required. The description correctly focuses on output semantics rather than inputs; the baseline for a zero-parameter tool is 4.

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

  Purpose5/5

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

  The description opens with 'Lists the wiki’s API keys', giving a specific verb and resource, then enumerates the returned attributes: expiry, revoked status, and whether API access is enabled. This clearly differentiates it from mutation siblings like revoke_api_key and set_api_state.

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

  Usage Guidelines3/5

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

  The description makes the listing purpose obvious but never states explicit when-to-use or when-not-to-use guidance relative to alternatives. An agent can infer this is the read-only inspection tool, but the definition does not call out siblings such as revoke_api_key or set_api_state as the appropriate choice for other intents.

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

• list_storage_targetsA
  4.4/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint=true. The description adds meaningful behavioral context: credentials in the configuration are redacted, and it clarifies that the tool reports sync status and last error. No contradictions with annotations.

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

  Conciseness5/5

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

  A single, front-loaded sentence conveys the resource, example backends, returned fields, and a security note. Every clause adds value and there is no filler or repetition.

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

  Completeness4/5

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

  For a zero-parameter, read-only list tool, the description sufficiently defines what an agent will get back: storage backends with sync status and last error, plus credential redaction. It does not specify output field formats, but no output schema is present, and the high-level summary is adequate for correct invocation.

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

  Parameters4/5

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

  The tool has zero parameters, so there are no parameter semantics to clarify. The baseline for 0 params is 4, and the description appropriately focuses on output rather than parameter details.

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

  Purpose5/5

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

  The description identifies the exact resource ('configured storage backends'), the kind of data returned ('sync status and last error'), and gives concrete examples (git mirrors, S3 buckets, local file dumps). This goes beyond the title and distinguishes it from generic list_* siblings.

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

  Usage Guidelines4/5

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

  The description implies the use case: checking the configured storage backends and their health. There are no storage-specific sibling tools, so no exclusions or alternatives are needed. While it doesn't explicitly say 'use when...', 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.

• set_user_activeA
  4.4/5.0
  Behavior4/5

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

  Annotations only say idempotentHint=false, so the description carries the burden of behavior. It discloses that deactivation is non-destructive to content, blocks sign-in, is reversible, and needs a confirmation token. It does not mention what happens to existing sessions or what the confirm flow returns, but the core side effects are clear and consistent with the annotation.

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

  Conciseness5/5

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

  Three short sentences front-load the action, then add the most important side effect and the selection-vs-delete_user distinction. Every sentence earns its place.

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

  Completeness4/5

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

  For a low-complexity state toggle, this is nearly complete: the schema covers parameters fully, and the description covers effects and the main alternative. The only omission is the result of a successful call or an unconfirmed first call, but the schema's confirm_token note already fills in the workflow.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters are already documented in the schema. The tool description adds only the high-level 'on/off' framing and the token requirement, which does little beyond the schema's own descriptions.

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

  Purpose5/5

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

  The description opens with a specific action, 'Switches an account on or off', and states the key effect: a deactivated account cannot sign in but keeps its pages and groups. It further distinguishes itself from delete_user by calling itself the reversible alternative, so an agent can separate it from the closest sibling.

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

  Usage Guidelines5/5

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

  It gives an explicit routing signal: use this as the reversible alternative to delete_user, and the retention of pages/groups makes the trade-off concrete. This is direct when-to-use guidance relative to the obvious sibling without requiring schema inspection.

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

• update_tagA
  4.4/5.0
  Behavior5/5

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

  Beyond the idempotentHint annotation, the description discloses the high-impact propagation ('affects all of them at once'), flags it as risky, and introduces the confirmation-token requirement. This is meaningful behavioral context that structured annotations do not convey.

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

  Conciseness5/5

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

  Two sentences deliver the action, the scope, the risk, and the token requirement with no filler. The core action is front-loaded before the warning.

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

  Completeness4/5

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

  For a 4-parameter update with a fully described schema and an idempotency annotation, the description covers purpose, scope, risk, and token flow. It does not describe the response format, but there is no output schema and the schema handles the mechanics, so only a small gap remains.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents tag_id, tag, title, and confirm_token. The description adds only general context about the confirmation token and the global rename effect, not new parameter-level detail, so it stays at the baseline.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Changes a tag’s name or display title', and immediately distinguishes the tool from sibling tag tools such as list_tags, search_tags, and delete_tag by naming the update action. It also adds the global scope across pages, making the purpose unmistakable.

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

  Usage Guidelines4/5

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

  The description makes clear this is the action to use when renaming a tag, and explains the all-pages effect that an agent should consider before calling it. It does not explicitly name an alternative or a when-not-to-use case, but the sibling set has no other tag-renaming tool, so the context is sufficient.

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

• upload_assetA
  4.4/5.0
  Behavior5/5

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

  Annotations only specify idempotentHint=false, so the description carries the full behavioral burden. It reveals non-obvious restrictions (SVG/HTML/XML refused) with a security rationale, and it discloses that the underlying Wiki.js route is undocumented and may change in future releases. This goes well beyond what the schema or annotations reveal.

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

  Conciseness5/5

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

  Each sentence earns its place: the first defines the operation, the second explains encoding and type derivation, the third documents the refusal rules and rationale, and the fourth warns about the fragile route. No filler or redundancy.

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

  Completeness4/5

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

  For a mutation tool with minimal annotations and no output schema, the description covers encoding, content-type behavior, security-based refusals, and the unstable route. It omits an explicit statement about return values or error behavior, but the information needed to invoke the tool correctly is present.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all three parameters are already documented. The description adds the useful fact that the content type is derived from the extension and that content is base64-encoded, but it does not substantially expand on the schema definitions. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states a specific action ('Uploads'), a specific resource ('an image or file to an asset folder'), and its purpose ('so it can be embedded in a page'). It differentiates this from sibling asset tools like list_assets, rename_asset, and delete_asset by describing a creation workflow.

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

  Usage Guidelines4/5

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

  The description gives practical usage context: content is base64-encoded, the content type is derived from the extension, and SVG/HTML/XML are explicitly refused. It also warns that the route is undocumented and may change. It does not explicitly name alternatives, but there is no competing upload tool among the siblings.

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

• delete_assetA
  4.5/5.0
  Behavior5/5

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

  Beyond the annotations (destructiveHint=true, idempotentHint=false), the description adds significant behavioral detail: deletion is permanent, downstream pages will break, and a confirmation token is required. This gives the agent a concrete model of side effects and the two-step confirmation flow.

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

  Conciseness5/5

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

  The description is three short sentences, each carrying distinct information: the permanent action, the downstream consequence, and the confirmation requirement. It is front-loaded and contains no filler or repetition of the schema.

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

  Completeness5/5

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

  Given the simple parameter set and full schema coverage, the description plus annotations provide everything an agent needs: the destructive nature, permanent side effects, and the confirmation-token protocol. No critical behavioral gap remains.

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

  Parameters3/5

  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 asset_id and confirm_token well. The description adds context about the confirmation requirement but no new parameter-level detail, matching the baseline for fully covered schemas.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Deletes an asset permanently.' It also clarifies the consequence (broken image or dead link), which distinguishes it from other delete_* siblings by naming the resource and its unique destructive effect.

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

  Usage Guidelines4/5

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

  The description makes clear when to use the tool: when an asset must be permanently removed. It also communicates the key procedural requirement of a confirmation token. It does not explicitly name alternatives or when-not-to-use conditions, but the context is sufficient for an agent to select this tool over related delete_* operations.

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

• delete_pageA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare destructiveHint=true, but the description adds meaningful context beyond that: Wiki.js has no trash, deletion cannot be undone, page history is included, and a confirmation token is required. This gives the agent a realistic sense of the consequences before invoking the destructive operation.

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

  Conciseness5/5

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

  Three short sentences, each earning its place: what is deleted, why it is irreversible, and what is required. The most important safety information is front-loaded in the first sentence.

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

  Completeness5/5

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

  For a destructive tool with no output schema, the description covers everything an agent needs to decide and execute correctly: the scope of deletion, permanence, irreversibility, and the confirmation-token requirement. Parameter details are fully covered by the schema, so nothing necessary is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all four parameters in detail. The description adds no parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  States a specific verb and resource: 'Deletes a page and its history.' This clearly distinguishes it from sibling delete tools like delete_comment, delete_user, and delete_tag. The inclusion of 'and its history' also differentiates it from purge_page_history, which only removes history.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use the tool: to permanently delete a page and all of its history. It also communicates a key usage requirement, the confirmation token, and the irreversible nature of the operation. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

• list_page_linksA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description adds critical behavioral caveats: Wiki.js 'returns the whole graph at once and offers no filter, so on a large wiki this is truncated.' This warns the agent about incomplete results and the absence of filtering, which is valuable operational context.

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

  Conciseness5/5

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

  Three sentences with no filler: the core behavior comes first, followed by the motivating use case, then the truncation caveat. Every sentence contributes distinct decision-relevant information.

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

  Completeness5/5

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

  For a single optional-parameter read-only tool with no output schema, the description covers what is returned, why it is useful, and its main limitation. Combined with the schema's locale documentation, the agent has enough information to call this tool correctly.

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

  Parameters3/5

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

  The only parameter, locale, already has a thorough schema description covering format, default, and meaning. The tool description merely repeats the 'one locale' concept, adding little beyond what the input schema already provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Returns every page together with the internal links it contains,' identifying it as a link-graph tool for one locale. This clearly distinguishes it from sibling tools like list_pages or get_page, which do not describe page-to-page link relationships.

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

  Usage Guidelines4/5

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

  It gives a clear use case: 'Useful for finding what would break before moving or deleting a page,' which tells an agent when to invoke it. It does not explicitly name alternatives or state when not to use it, so it falls just short of full exclusion guidance.

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

• list_tagsA
  4.5/5.0
  Behavior4/5

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

  With readOnlyHint=true, the safety profile is already covered by annotations. The description adds meaningful behavior: it returns every tag, includes display title and last-used timestamp, and positions tags as a cross-cutting index. It doesn't mention ordering or pagination, but for a zero-parameter list tool this is adequate.

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

  Conciseness5/5

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

  Two sentences, no wasted words. The first sentence front-loads what the tool returns, and the second supplies valuable usage context connecting this tool to search and list_pages. Every phrase earns its place.

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

  Completeness5/5

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

  For a simple, zero-parameter, read-only list tool, the description is complete. It explains the resource, the output fields, the ideal use case, and the natural follow-up tool. The readOnly annotation covers safety, and no output schema is needed given the description already names the return fields.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description correctly avoids inventing parameter details and instead describes the output fields, which is the right focus for this tool.

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

  Purpose5/5

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

  The description states a specific verb and resource: it lists every tag in the wiki, including display title and last-used time. This fully differentiates it from search_tags, which is for finding specific tags, and from list_pages, which lists pages rather than tags.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use this tool, calling it 'often a better starting point than search' and explaining how to follow up with list_pages. It doesn't explicitly state when not to use it or name all alternatives, but the guidance is concrete and actionable.

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

• revoke_api_keyA
  4.5/5.0
  Behavior5/5

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

  Annotations already mark destructiveHint=true, but the description adds substantial behavioral context: permanence, impossibility of un-revoking, potential self-inflicted connection loss, and the confirmation-token requirement. This is exactly the kind of value descriptions should add beyond annotations.

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

  Conciseness5/5

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

  Two short sentences with no filler. The most important behavioral facts (permanence, self-impact, token requirement) are front-loaded, and every sentence earns its place.

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

  Completeness5/5

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

  For a destructive, irreversible tool, the description covers permanence, the confirmation workflow, and the risk of cutting the server's own connection. Combined with the schema, no information critical to calling the tool correctly is missing.

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

  Parameters3/5

  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's 'Requires a confirmation token' adds process-level nuance but the schema already explains that confirm_token should be omitted to receive one. No new parameter-level semantics are introduced beyond the schema.

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

  Purpose5/5

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

  States the specific verb 'Revokes' and the resource 'API key', adding 'immediately and for good' and 'Wiki.js has no way to un-revoke one'. This clearly distinguishes it from read-oriented siblings like list_api_keys and other API-related mutations.

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

  Usage Guidelines4/5

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

  Provides clear usage context: the operation is permanent, requires a confirmation token, and warns about revoking the server's own key. It does not explicitly compare against alternative tools, but no direct alternative exists among siblings, so the caution and prerequisite are sufficient guidance.

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

• update_pageA
  4.5/5.0
  Behavior5/5

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

  The description discloses several non-obvious behaviors beyond the idempotentHint annotation: ambiguous or missing old_text matches are refused, concurrent edits are detected and refused unless force=true, and metadata-only updates are allowed. This richly informs the agent about side effects and failure modes.

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

  Conciseness5/5

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

  The description is front-loaded with the core action and uses three dense, purposeful sentences. Every clause contributes behavioral or usage guidance, with no redundant padding or repetition of schema details.

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

  Completeness5/5

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

  For a 13-parameter mutation tool, the description covers the most decision-critical aspects: content vs edits, edit uniqueness, concurrency protection, force override, and metadata-only updates. The remaining details are adequately handled by the rich input schema and the expected_updated_at notes about get_page.

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

  Parameters4/5

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

  Schema coverage is high (85%), so the schema already explains most parameters. The description adds meaningful conceptual grouping—content replaces the whole body, edits are surgical and require unique old_text, and metadata can be changed independently—which helps an agent understand parameter relationships beyond the raw field descriptions.

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

  Purpose5/5

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

  The description opens with 'Changes a page' and then specifies the two primary update modes: replacing the whole body via content and performing surgical find-and-replace via edits. It also clarifies that metadata fields can be updated without touching the text, making the tool's scope distinct from create_page, move_page, and delete_page.

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

  Usage Guidelines3/5

  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 content vs edits and explains the concurrency/force behavior. However, it does not explicitly name sibling alternatives or state exclusions, such as when to prefer convert_page_editor for changing editor format or create_page for a new page.

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

• create_pageA
  4.6/5.0
  Behavior4/5

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

  Annotations only carry idempotentHint=false, so the description bears the behavioral disclosure burden. It discloses the PageDuplicateCreate failure mode for duplicate paths and clarifies that the editor determines content interpretation. It does not go further into permissions, side effects, or response shape, but it reveals the most important non-obvious behavior.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core purpose, and every sentence adds discriminating information: creation, duplicate-path behavior with an explicit alternative tool, and editor semantics. There is no filler or redundancy.

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

  Completeness4/5

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

  For a create operation with nine parameters and no output schema, the description covers the essential invocation decision: when to create versus update, and how to interpret content via the editor field. The remaining parameter details live in the schema, and no critical selection or invocation context is obviously missing.

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

  Parameters4/5

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

  Schema coverage is high at 78%, so the baseline is already strong. The description adds meaning beyond the schema by explaining that the editor controls how content is interpreted and that markdown source must set editor="markdown". This is genuinely useful for choosing the right parameter value.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Creates a page') and immediately distinguishes the tool from its sibling update_page. The purpose is unambiguous and differentiated from the large sibling set.

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

  Usage Guidelines5/5

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

  The description provides explicit usage conditions: the path must not already exist in the locale, otherwise update_page should be used for existing pages. It also tells the agent when the editor parameter matters, giving clear decision-relevant guidance.

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

• delete_userA
  4.6/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses the concrete consequence: the account is removed and its pages must be reassigned to another user. It also reveals the non-obvious confirmation-token requirement, adding valuable behavioral detail that an agent could not infer from annotations alone.

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

  Conciseness5/5

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

  Three short sentences, with the core action front-loaded and no redundant filler. Every sentence contributes either to the primary purpose or to essential invocation requirements.

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

  Completeness4/5

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

  The description captures the essential two-step confirmation workflow and the required replacement parameter, while the schema fully documents the token's optionality and format. No output schema exists, but for a destructive action, the absence of return-value details is a minor gap.

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

  Parameters4/5

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

  Schema coverage is 100%, so a baseline of 3 applies. The description adds meaningful semantic value by explaining why replace_with_user_id is required and what the confirmation token is for, going beyond the schema's brief field descriptions.

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

  Purpose5/5

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

  The description opens with the direct action 'Removes an account,' clearly identifying the verb and resource. It further distinguishes itself by explaining the account inheritance requirement, which is unique to user deletion among the delete_* sibling tools.

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

  Usage Guidelines4/5

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

  The description gives clear operational context, explaining that replacement ownership is mandatory and that a confirmation token is needed. It does not explicitly name alternative tools or state when not to use it, but the deletion context is unambiguous.

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

• get_pageA
  4.6/5.0
  Behavior5/5

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

  The readOnlyHint annotation already signals safety, and the description adds genuinely useful behavior beyond it: truncation to fit the result budget, the semantics of each mode, and the windowing strategy for large pages. An agent knows what will happen when reading a big page.

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

  Conciseness5/5

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

  The description is compact and front-loaded: action first, then addressing, then mode semantics, then content-specific reading strategies. Every sentence earns its place and none merely restates the schema.

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

  Completeness5/5

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

  With no output schema, the description carries the burden of explaining return semantics, and it does: metadata, outline, content, and rendered are each described. Truncation is flagged, parameter combinations are clarified, and nothing essential for correctly invoking this read-only tool is missing.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds meaning beyond the schema: page_id OR path+locale are alternative addressing routes, mode changes what offset/max_chars/section mean, and section vs offset+max_chars are presented as explicit alternatives. This is exactly the relational context an agent needs.

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

  Purpose4/5

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

  States a specific verb+resource: 'Reads one page', addressable by page_id or path plus locale. The four modes clearly define distinct output intents. It doesn't explicitly contrast with siblings like list_pages or get_page_version, but the 'one page' scope makes the purpose unmistakable.

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

  Usage Guidelines4/5

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

  Gives clear within-tool guidance: choose 'outline' as the cheapest way to inspect a long page, use section or offset/max_chars for content, and warns that large pages are truncated. It does not, however, say when to prefer sibling tools such as get_page_version for historical content or list_pages for discovery.

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

• get_navigation_treeA
  4.7/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint: true. The description adds useful behavioral context: results are per-locale, hand-curated, and may not reflect the actual page tree. This goes beyond what the annotation conveys, though it does not discuss auth or rate limits.

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

  Conciseness5/5

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

  Two sentences, no filler. The main subject is front-loaded, and the corrective contrast with get_page_tree is placed right after the core definition.

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

  Completeness5/5

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

  For a parameterless, read-only tool, the description is complete. It states the domain (sidebar navigation), the locale scoping, the hand-curated nature, and the key distinction from the actual page tree. No missing information prevents correct use.

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

  Parameters4/5

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

  The input schema has zero parameters and 100% description coverage, so there is nothing for the description to add. No parameter information is needed for correct invocation.

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

  Purpose5/5

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

  The description clearly identifies the resource: the sidebar navigation as configured per locale. It immediately differentiates this from get_page_tree, so an agent knows exactly what this tool returns and what it does not.

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

  Usage Guidelines5/5

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

  It explicitly states that this is not the page tree and names get_page_tree as the tool that reflects actual pages. This gives a clear when-not and routes to the correct alternative without requiring schema inspection.

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

• get_site_infoA
  4.7/5.0
  Behavior4/5

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

  The readOnlyHint annotation conveys safety, but the description adds meaningful behavior: it states the tool exposes which fields are returned and deliberately omits host filesystem and database host details. This goes beyond annotation-only coverage, though it stops short of describing error behavior or exact response format.

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

  Conciseness5/5

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

  Three sentences, each earning its place: return content, diagnostic usage, and deliberate exclusions. The most actionable information is front-loaded.

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

  Completeness5/5

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

  For a zero-parameter diagnostic tool backed by a readOnlyHint annotation, the description is complete. It explains what the call returns, what it proves, and what sensitive fields are intentionally absent.

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

  Parameters4/5

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

  The tool has zero parameters and the schema describes 100% of the parameter space. Per the baseline for zero-parameter tools, the description is not required to explain parameter behavior, and it appropriately focuses on return value and usage.

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

  Purpose5/5

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

  The description explicitly lists what the tool returns: version, database, host summary, site title/description, and totals. It clearly identifies the resource and scope, and the diagnostic framing distinguishes it from sibling tools.

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

  Usage Guidelines5/5

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

  The description gives explicit situational guidance: 'The first call to make when something is not behaving — it proves the URL and the API key work at all.' This tells an agent exactly when to invoke this tool, even without naming alternatives.

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

• grep_pagesA
  4.7/5.0
  Behavior5/5

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

  Despite readOnlyHint being present, the description adds substantial behavioral context: it fetches pages one-by-one, matches locally, is expensive, and returns matching lines with context rather than whole pages. This goes beyond the annotation and gives the agent a realistic expectations about cost and output.

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

  Conciseness5/5

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

  Four sentences, each earning its place: what it does, why it exists, how to control cost, and what it returns. The most important scoping and cost warnings are front-loaded before the return format.

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

  Completeness5/5

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

  For a moderately complex, high-cost read operation with no output schema, the description still tells the agent the return shape, the performance profile, the motivation, and the narrowing levers. Nothing essential is missing for correct tool selection and safe invocation.

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

  Parameters4/5

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

  Schema coverage is 86%, so the baseline is 3, but the description enriches parameter understanding by explicitly recommending path_prefix, tags, or locale to narrow the search and advising to keep max_pages small. These are strategic parameter-usage insights not present in the schema.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Searches the actual text of pages with a regular expression, by fetching them and matching locally.' It also distinguishes itself from Wiki.js's default search engine and the sibling search_pages by explaining the default does not index page content at all.

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

  Usage Guidelines4/5

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

  The description clearly states when this tool is appropriate — when page content must be searched because the default search engine doesn't index it. It also warns that this is the expensive path and tells the caller to narrow the scope with path_prefix, tags, or locale and to keep max_pages small. It does not explicitly name an alternative tool for the when-not case, but the intent is clear.

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

• list_pagesA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description adds valuable behavioral context: result reports matched vs. shown counts, no offset is supported, no page content is returned, and default ordering is newest first. This helps the agent reason about output meaning without an output schema.

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

  Conciseness5/5

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

  Four sentences, front-loaded with the core purpose and followed by high-value caveats. Every sentence earns its place, with no redundant filler.

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

  Completeness5/5

  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 result-count semantics, ordering, filtering strategy, and the key limitation (no offset). It also points to get_page for content, making it complete enough for correct invocation.

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

  Parameters4/5

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

  The schema already covers most parameters, and the description adds the key strategic point that narrowing is preferred over paging, plus the default ordering behavior. This meaningfully clarifies how limit, tags, locale, creator_id, and author_id relate to each other.

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

  Purpose5/5

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

  Clearly states it lists pages with their metadata and specifies the default ordering (newest first). It also distinguishes itself from get_page by noting it returns no page content, so an agent can tell list from content-fetch behavior.

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

  Usage Guidelines4/5

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

  Explains the no-offset limitation and explicitly tells agents to narrow via tags, locale, creator_id, or author_id rather than paging. It routes content needs to get_page, though it does not explicitly contrast with search_pages or grep_pages.

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

• rebuild_search_indexA
  4.7/5.0
  Behavior5/5

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

  Beyond the bare idempotentHint=false annotation, the description discloses important runtime behavior: the reindex affects every page, the alternative is silent failure, and a confirmation token is required. This is far more transparent than most tool descriptions.

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

  Conciseness5/5

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

  Three sentences, each earning its place: what it does, when it is needed, and what it does on the basic engine. The most important information is front-loaded.

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

  Completeness5/5

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

  For a single-parameter tool with fully documented schema and no output schema, this description covers purpose, timing, side effects, and the odd failure mode. Nothing an agent needs to decide whether to call this tool is missing.

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

  Parameters3/5

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

  The schema already fully documents confirm_token with a pattern and explanation. The description mentions the token requirement but adds no meaning beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Reindexes every page in the active search engine.' It also clarifies the exact trigger condition and scope, making it easy for an agent to distinguish this from unrelated sibling tools.

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

  Usage Guidelines5/5

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

  The description explicitly says when this is required ('after switching away from Database - Basic'), warns that the new engine 'starts empty' and 'silently returns nothing' otherwise, and notes that it does nothing on the basic engine. This gives clear go/no-go guidance.

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

• search_pagesA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description discloses important behavioral traits: the default engine only indexes titles/descriptions, the result names the active engine, results carry no excerpt, and the engine choice determines applicability. This adds significant context and does not contradict any annotation.

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

  Conciseness5/5

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

  The description is front-loaded with the most important caveat, then provides a conditional alternative and a follow-up recommendation. Every sentence carries essential information with no filler or redundancy.

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

  Completeness5/5

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

  For a search tool with one required parameter, no output schema, and a read-only annotation, the description covers the key environmental constraints and behavioral expectations. It tells the agent what the results will not contain, how to detect the active engine, and how to route to sibling tools when needed.

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

  Parameters3/5

  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, so the baseline is 3. The tool description does not add per-parameter semantics beyond mentioning follow-up retrieval with get_page, which is not parameter-specific.

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

  Purpose5/5

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

  The description opens with a specific verb and resource, 'Full-text search' over pages, and then differentiates itself from grep_pages by clarifying what the default engine indexes. It clearly tells an agent that search_pages searches page titles/descriptions on a basic engine, not the body text.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use search_pages versus grep_pages, conditioned on the active search engine and whether the target is inside a page's body. It also recommends following up with get_page when content is needed, giving direct when-to-use and when-not-to-use guidance.

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

• set_api_stateA
  4.7/5.0
  Behavior5/5

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

  The destructiveHint annotation is true, and the description goes well beyond it by disclosing that all API keys are disabled, including this server's own key, that the web UI is the only recovery path, and that a confirmation token is required.

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

  Conciseness5/5

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

  Two sentences with no filler. The purpose is front-loaded, and the critical warnings and confirmation requirement are included in tight, high-value prose.

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

  Completeness5/5

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

  For a destructive two-parameter tool with no output schema, the description fully covers what the agent needs: global scope, irreversible-looking severity, recovery path, and the confirmation flow. Nothing essential is missing.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds consequential meaning to the enabled parameter by stating what disabling actually does: it disables every API key at once. It also surfaces the confirmation-token requirement.

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

  Purpose5/5

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

  States a specific verb and resource: 'Switches Wiki.js’ whole API on or off.' It clearly identifies the scope as global, distinguishing it from sibling tools like revoke_api_key that act on individual keys.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use the tool, including the severe consequence that turning it off 'disables every API key at once' and that recovery requires the web administration UI. It does not name alternatives, but no close alternative exists among the siblings.

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

• update_groupA
  4.9/5.0
  Behavior5/5

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

  Beyond the idempotentHint annotation, the description discloses the wholesale-replacement behavior and the destructive consequence that omitting a rule deletes it. It also warns that this call decides who can read and edit the wiki, which is critical behavioral context for a permissions-changing operation.

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

  Conciseness5/5

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

  The description is three purposeful sentences, front-loading the most important wholesale-replacement warning before giving the workflow and safety rationale. No sentence is redundant with the schema or annotations.

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

  Completeness5/5

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

  Given the tool’s destructive semantics, confirmation-token flow, and lack of output schema, the description covers the essential context: full replacement behavior, pre-read with get_group, and the need for a confirmation token. The schema handles remaining parameter details, so nothing critical is missing for correct invocation.

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

  Parameters4/5

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

  Schema coverage is high at 83%, so many parameter details are already in the input schema. The description adds important semantic context not in the schema: permissions and page_rules must be sent as the complete set, and omitted rules are deleted. This elevates it slightly above the high-coverage baseline.

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

  Purpose5/5

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

  The description states a specific verb ('Replaces') and resource ('a group’s name, permissions and page rules'), and explicitly contrasts itself with a partial update, making its scope unmistakable. This clearly differentiates it from related group tools like get_group and create_group.

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

  Usage Guidelines5/5

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

  The description gives explicit, actionable workflow guidance: read the group with get_group first, send back the full set with changes applied, and expect to provide a confirmation token. This tells the agent exactly when and how to use the tool, and highlights the consequence of omitting rules.

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