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

Goes well beyond the annotations (destructiveHint=true, readOnlyHint=false): it discloses the OAuth2 auth source, the two-step confirm/dry-run write protocol, the WALLABAG_ALLOW_WRITES gate, and exactly which actions trigger an extra destructive warning (deletes, bulk URL lists, user registration). This is precisely the safety context an agent needs for a destructive tool.

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

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

Dense and runs several distinct concerns (auth, environment, help, write gating, destructive warnings, action list) into a flat wall of sentences. Information is useful but not organized hierarchically, forcing the reader to parse it rather than scan.

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

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

For a multi-action aggregate tool with no output schema, it covers the important operational facts: auth, write safety, dry-run, help mechanism, and destructive-action set. The main gap is semantic -- it never says what an annotation is or what these operations return -- but the operational completeness is strong.

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

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

Schema description coverage is 100%, so the schema already documents confirm, body, query, params, action, and target. The description mostly restates the confirm/target semantics already encoded in the schema (const true, help target), adding little beyond it. Baseline 3 is appropriate.

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

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

States the resource ('annotations toolset') and enumerates the four actions (delete/get/post/put_by_id), so an agent knows this is a Wallabag annotation CRUD surface. However, it never explains what a Wallabag annotation actually is (a highlight/comment on an entry), which is meaningful context for a domain-specific resource. Clear verb+resource, but no active sibling differentiation.

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

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

Explains the mechanics well -- how to use action help, that writes require confirm=true and WALLABAG_ALLOW_WRITES, and that omitting confirm gives a dry-run. But it gives no guidance on when to reach for this tool versus the sibling wallabag_entries or wallabag_search, leaving routing to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description earns credit for adding auth context the annotations lack: OAuth2 Bearer from WALLABAG_ACCESS_TOKEN or a password grant. It stops short of describing response shape or pagination, but the auth prerequisite is the highest-value behavioral fact for a self-hosted Wallabag tool.

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

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

It is short and reasonably front-loaded with the toolset and auth, but the telegraphic style leaves fragments like 'Self-hosted Wallabag first.' that don't clearly earn their place. The order is odd: the help mechanism is buried in the middle rather than after the action list.

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

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

With 5 parameters, nested body/query/params objects, and no output schema, the description should explain what each action returns and how body/query apply to a read-only config tool. It covers auth and the help mechanism but leaves the two real operations undefined, so an agent still needs an exploratory help call.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only one parameter-level detail — that 'target' pairs with action=help — which the schema's own description of target already states, so it adds essentially no meaning beyond the structured fields.

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

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

It states this covers the 'config toolset (2 operations)' and enumerates the actions (get, get_taggingrule_export, help), so the resource area is identifiable. But the actions themselves are never explained — 'get' could mean anything — so an agent cannot tell what the tool actually retrieves without opening the schema or calling help.

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

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

The description does provide a discovery path: 'action help with target returns one action's parameters,' which is genuine invocation guidance. However, it never says when to choose wallabag_config over siblings like wallabag_info or wallabag_tags, and 'Self-hosted Wallabag first' is an unexplained fragment rather than a usable condition.

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

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

Beyond annotations, the description discloses OAuth2 auth sources, the write-gating environment variable, dry-run behavior that sends nothing, and the extra destructive warning shown for deletes, bulk URL lists, and user registration. These details substantially improve safe invocation and do not contradict the annotations.

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

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

The description is front-loaded and information-dense, with auth and write safety before the action list. The long action enumeration duplicates the schema enum and makes the paragraph run-on, but it is not padded with fluff.

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

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

For a complex 14-operation tool with six parameters, the description covers auth, write safety, dry-run behavior, and how to discover per-action parameters via help. It does not explain return values or per-action semantics, but the help action mitigates the biggest invocation gap.

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

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

Schema description coverage is 100%, so the schema already carries most parameter meaning. The description reinforces action help, target, and confirm semantics, but it largely repeats what the schema states and does not add new syntax or format guidance for body, query, or params.

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

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

The description states that the tool covers the Wallabag entries toolset and enumerates all 14 supported actions, giving a clear verb/resource picture. It does not explicitly distinguish the tool from siblings such as wallabag_search, so it falls short of a 5.

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

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

It gives clear operational guidance: use action help with target to inspect parameters, writes require confirm=true plus WALLABAG_ALLOW_WRITES=true, and omitting confirm produces a dry-run preview. It does not say when to choose this tool over sibling tools like wallabag_search, but the usage context is otherwise strong.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds useful context about OAuth2 Bearer auth and password grant, but does not mention rate limits, response format, or other behavioral limits.

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

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

The description is short and mostly front-loaded with scope and auth. It could order the action list before auth details, but there is little wasted text.

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

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

There is no output schema, so the description should ideally explain what actions like get and get_version return. It covers auth and help behavior but leaves the main return values unspecified, making it only minimally adequate for an agent to call confidently.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including action, target, body, query, and params. The description adds little beyond restating the action list and help behavior, which is appropriate baseline when the schema does the heavy lifting.

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

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

The description says it covers the info toolset and names the actions get and get_version, but 'info toolset' and 'get' are vague about the actual resource being retrieved. It does not explicitly differentiate this tool from siblings like wallabag_config or wallabag_entries.

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

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

The only usage guidance is that action=help with target returns one action's parameters. There is no guidance on when to use this tool versus wallabag_config, wallabag_entries, or other siblings, and no exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured context: OAuth2 Bearer via WALLABAG_ACCESS_TOKEN or password grant, and the self-hosted-first deployment note. It still says nothing about what the get action returns or how the search behaves against a live instance.

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

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

It is short, but the sentences are fragmentary and telegraphic ("Self-hosted Wallabag first.", "Actions: get."), and the auth note is front-loaded ahead of any statement of what the tool actually does. Nothing is wasteful, but the ordering and terse phrasing cost comprehension.

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

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

This is a nested-object wrapper tool with five parameters, an action enum and no output schema, so the description carries real burden. It does not explain how to form the query/body/params for a search, what the single get action does, or what comes back, leaving the agent to reverse-engineer from the schema.

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

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

Schema description coverage is 100% and all five parameters, including the action enum, are documented in the schema. The description only explains the help/target pairing, which the schema's target description already states, so it adds little beyond structured data. Baseline 3 applies.

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

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

"covers the search toolset (1 operations)" restates the tool name rather than describing what is searched (entries? annotations? tags?) or what the result is. The only concrete statement is "Actions: get", which is a wrapper artifact, not a purpose. Nothing distinguishes it from siblings like wallabag_entries or wallabag_tags.

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

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

The only usage-like statement is about the meta-action "action help with target returns one action's parameters", which explains a help mode rather than when to call search versus other wallabag tools. No conditions, exclusions, or alternatives are given.

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

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

Substantial context beyond the annotations: auth source (WALLABAG_ACCESS_TOKEN or password grant), the env-flag gate on writes, the fact that a dry-run sends nothing, and an extra warning tier for destructive actions. The one blemish is boilerplate leakage — 'bulk URL lists' and 'user registration' are not among this toolset's actions, which suggests copied text and slightly muddies the destructive-action warning.

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

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

Front-loaded and dense — toolset scope, auth, write gate, and action list in a few sentences, with no filler sentences. It loses a point for generic boilerplate ('bulk URL lists, and user registration') that doesn't apply to this tag-focused toolset and distracts from the real destructive actions.

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

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

For a six-parameter, nested-object, no-output-schema tool, the description covers what an agent needs before calling: auth mechanism, write confirmation protocol, dry-run behavior, destructive-action warnings, and a self-service help path to per-action parameter details. Return values are the only omission, and the help action partly compensates.

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

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

Schema description coverage is 100%, so action, target, confirm, body, query and params are already documented in the schema; the description adds the useful hint that 'help' with a target returns that action's parameters. It adds nothing about what body/query/params each action expects, so baseline 3 is right.

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

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

The description names the resource ('tags toolset') and enumerates the concrete actions (delete_by_id, delete_label, delete_tag_label, get), so an agent knows the domain and the operation surface. It doesn't explain what each action does (e.g. delete_label vs delete_tag_label), leaving ambiguity inside the enum, but the tool is clearly separable from siblings like wallabag_entries or wallabag_search.

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

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

It explains the write workflow (confirm=true plus WALLABAG_ALLOW_WRITES=true, omit confirm for dry-run) and the help/target mechanism for discovering per-action parameters, which is real operational guidance. It never says when to reach for wallabag_tags versus wallabag_entries or wallabag_search, so alternative selection is only implied by the toolset names.

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