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

Annotations only declare readOnly=false, destructive=true, idempotent=false; the description adds substantial context beyond that — the audit side effect, the score threshold that gates issuance, the signing format (W3C VC, Ed25519, JWS compact), and a monetary cost. It does not say what happens on a sub-70 score (error vs. silent no-op) or whether re-issuing for the same skill is safe, and the destructiveHint=true is left unexplained since nothing described is actually destroyed.

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 core behavior, threshold, and payment requirement are front-loaded in three tight sentences. The trailing 'Args:' section is pure duplication of the input schema and is the one part that does not earn its place.

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 no explanation, and both required parameters are fully covered. What remains thin is failure-mode behavior and idempotency semantics for a non-idempotent, money-consuming issuance operation.

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 both parameters fully. The 'Args:' block repeats the schema descriptions verbatim and adds no new semantics (no format validation, no allowed URL schemes, no DID resolution caveats). 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?

States a specific verb+resource ('Issue a VerifiedSkillCredential for an AI agent skill') and enumerates the internal pipeline (fetch SKILL.md, audit, sign with Ed25519). It does not name the near-siblings it must be distinguished from (mt_skill_audit for audit-only, mt_skill_verify for verification), so the agent still has to infer the boundary.

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?

Gives a clear triggering context: a credential is issued only if the audit score is >= 70, and payment of $5 USDC is required when the paywall is active. That is real prerequisite information, but there is no explicit exclusion or 'use X instead when...' routing to mt_skill_audit / mt_skill_verify.

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