wallabag_config

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.