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

Annotations already flag readOnlyHint and openWorldHint, so the description earns credit for what it adds: the tool is free, the link is bearer-style ("for whoever holds the e-CNPJ"), signing happens out-of-band in the browser or via the kya-sign CLI, and the issuer never sees the certificate. That privacy and auth-model detail is genuinely beyond the structured fields. It doesn't cover link expiry or reuse behavior, so not a 5.

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?

Opens with cost ("Free.") and who this is for, then the mechanics and signer options — front-loaded and information-dense with almost no filler. The middle sentence is a long run-on enumerating A1/A3/cloud/CLI, which costs a little readability but each clause carries distinct information.

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 correctly explains what comes back (the /sign URL) and what the recipient sees and can do with it. Combined with the full schema coverage and readOnly annotation, an agent has enough to invoke this correctly; only link lifetime/reuse semantics are missing.

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 three parameters, and the draft-07 pattern on credential_id is fully specified. The description adds only light framing — that challenge_id comes from register/renew and that agent_signature lets the human sign with the e-CNPJ alone — which does not exceed the schema baseline.

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 concrete action and artifact — hand in challenge_id plus the agent's signature, receive the /sign URL for the e-CNPJ holder to sign. It also positions itself in the register/renew flow by naming the source of challenge_id, so an agent can place it. Sibling differentiation is indirect (no explicit contrast with kya_prove or kya_renew_prove), which keeps it just 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?

Implied usage is clear: this is the step that turns a challenge from kya_register/kya_renew into a signable link for the certificate holder. However there is no explicit statement of when NOT to use it, and no named alternative among the many sibling prove/verify tools that might also be relevant.

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