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

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description carries the rest: it discloses that each mint is a billable proof, that an over-long lifetime is rejected rather than truncated, that the result carries both the publishable token and the DERIVED effective_status/is_valid, and that this pair is stable across verbs. These are non-obvious operational traits an agent must know before calling.

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 action and its constraints are front-loaded, and the ACCESS block is clearly separated at the end. The middle sentences ('nothing more; it says nothing about the artifact or the business behind it') are somewhat discursive for a tool description, but they do carry semantic boundaries rather than filler.

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?

No output schema exists, yet the description explains the return payload (publishable token plus derived effective_status/is_valid). Combined with auth requirements, billing implications, lifetime rejection behavior, and nested-object parameter meaning, an agent has everything needed to invoke this correctly.

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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by framing scope as 'capability scopes' tied to the delegation's authorization semantics and by clarifying that the control proof belongs to the caller's active domain control proof. The explicit invalid_scope note partially duplicates the scope schema description, so the added value is real but moderate.

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?

The description states a precise verb+resource ('Create a delegation (Proof of Delegation)') and immediately defines the resulting semantic: a control-proven domain authorizes a typed url/purl artifact for capability scopes and returns a signed token. It also scopes the meaning ('the domain's controller authorized this artifact — nothing more'), which prevents an agent from over-reading the artifact. It references the sibling list/get tools whose output shape it shares, giving light disambiguation.

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?

Prerequisites are explicit and actionable: a Proof account is required, the client must be authenticated, and the description warns that start_login does not open this tool. It also gives the rejection rule for over-long lifetimes. It stops short of contrasting against other create_* siblings (e.g. create_authorization), so an agent has clear context but no explicit when-not guidance.

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