docs_auth

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

No annotations are provided, so the description carries the full burden. It adds one valuable behavioral fact — stored credentials are automatically applied during API fetching — but omits key traits for a mutation tool: whether 'remove' is irreversible, where credentials are stored, what 'get' exposes, and any error behavior for missing hosts.

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

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

Three short sentences with the core purpose front-loaded and the action inventory second. No filler, and the automatic-use fact is placed last where it functions as context rather than definition; the parenthetical action glosses are slightly redundant but cheap.

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 five-parameter tool with no annotations and no output schema, the description covers purpose and the auto-use behavior but leaves the return shape of 'list'/'get' and the destructive consequences of 'remove' unaddressed. It is workable to invoke correctly but not complete.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including per-action requirements (host/type/value for add, host for remove/get). The description's action list is largely redundant with the schema's own action enumeration, adding only the 'save/show/delete' glosses, so 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 a specific verb-and-resource purpose ('Manage authentication credentials for documentation sources') and enumerates the four supported actions with parenthetical glosses, so an agent knows exactly what the tool covers. It distinguishes itself from the content-oriented siblings (docs_add_swagger, docs_search, etc.) by domain, though it never explicitly names a sibling it is not.

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 closing line, 'Credentials are automatically used when fetching APIs,' implies when this tool matters (before fetching a host that needs auth), which is genuinely useful context. However, there is no explicit when-to-use versus when-not, no statement of prerequisites or ordering relative to the fetch tools, so usage remains inferred rather than stated.

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