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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the description's 'no side effects, deterministic' lines largely restate them. It does add genuinely new behavioral context: the security caveat that Basic auth is base64, not encryption, and requires HTTPS, plus concrete limits (64 KB input, 1 s per call, 1 MB result). Those additions are real but modest for a pure-function 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?

Purpose is front-loaded and the security caveat is well placed, but the entire body is duplicated in Spanish and English, roughly doubling length for zero added information. The trailing '[EN completo / full EN: inputSchema.description]' pointer is noise that points at text the agent already has.

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?

An output schema exists, so return values need not be explained, and both params are covered by the schema. Purpose, security posture, determinism, and resource limits are all stated, which is ample for a two-string pure function. The remaining gap is that the 'When' section is generic boilerplate rather than describing real usage scenarios.

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 both parameters are fully documented and the no-colon username constraint lives in the pattern. The description adds the RFC 7617/UTF-8 framing, which affects how the output is encoded, but no additional per-parameter meaning. Baseline 3 applies 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?

Names a specific verb and resource — 'Builds an HTTP Basic Authorization header value from a username and password (RFC 7617, UTF-8)' — so an agent knows exactly what it produces. Sibling differentiation is thin: the only named alternative is jwt-sign-hmac, which is far from the nearest neighbors (base64-encode, url-build), and the 'When' clause lists unrelated resources.

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 'When:' clause is boilerplate that does not describe this tool's use case — it talks about parsing URLs, IP ranges, and HTML/Markdown documents, which this tool does not do. The only real routing signal is 'Not for: signing a JWT with an HMAC secret (jwt-sign-hmac)', which is accurate but points at a distant sibling. An agent gets no guidance on when a Basic header is the right thing versus e.g. base64-encode.

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