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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description usefully adds that the credential is anchored on Base L2 — an on-chain, likely irreversible write. However it never explains cost/gas, whether re-issuing the same track creates a duplicate credential (annotation says non-idempotent), or why issuance is flagged destructive. Those are the behaviors an agent most needs before invoking a write 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 and compliance framing are front-loaded in the first two sentences, then parameters follow in a scannable list. The Args section is redundant with a fully documented schema, which is the only real waste, but the description is appropriately sized for an 8-parameter issuing tool.

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 an output schema present, the description needn't explain return values, and it covers the substantive gaps: what the credential attests, the anchoring chain, and the regulatory basis. Missing pieces are operational (cost, duplicate handling on re-issue), which keeps it just short of 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 every parameter is already documented, and the Args block largely restates the schema text verbatim. The one meaningful addition is the DID format example, but the enum-like values for human_oversight are already in the schema. 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 and resource ("Issue a VerifiedMusicCredential for an AI-generated music track") and immediately clarifies what the credential proves: provenance, originating tool, human involvement, and rights. This clearly distinguishes it from mt_verify_music_credential and mt_get_track_provenance, which read rather than issue.

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 establishes context (provenance attestation, EU AI Act Article 50(2), Base L2 anchoring) that implies when to use it, but never names an alternative or a when-not-to-use condition. An agent must infer from the sibling names that verification/provenance lookup happens elsewhere.

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