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

Adds substantial context beyond the annotations: pricing (0.10 USDC per call on Base, 10 signed-wallet free calls per 30 days), the need to sign a wallet ownership proof per request, the fact that the adapter grants no authority and never supplies credentials, and where to get the verification key (/api/trust-contract). This is real behavioral disclosure that the destructive/openWorld annotations alone would not convey. The only deduction is that it never says what the issue call destroys or how irreversible an issued passport is, despite destructiveHint=true.

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 pricing/paid-URL line is correctly front-loaded, but the core sentence 'Issue and verify signed receipt passports backed by completed, wallet-owned Wever computation records' is repeated verbatim in the 'Operating boundary' section, which wastes a meaningful share of the text. The remaining disclaimers are on-topic but dense and unstructured.

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?

A polymorphic two-mode schema with nested oneOf, a 24k-character passport payload, and destructive semantics, with no output schema, needs far more than this. The description never explains what issue returns (a passport artifact?) or what verify returns (validity verdict, decoded claims?), and leaves all parameter semantics undocumented. For a tool this complex the description is thin where it matters.

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 0% across five parameters, and the description does not compensate. It never explains the distinction between work.kind 'wallet_free_call' with a nonce versus 'settled_payment' with a payment_id, nor the meaning of the usage enum 'synthetic' vs 'operational', nor what the passport string should contain in verify mode. Only 'issue or verify' loosely maps to the mode field.

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 and verify signed receipt passports backed by completed, wallet-owned Wever computation records.' The two modes are named explicitly, so an agent can tell this is the passport service rather than the trust-scorecard or asset-passport siblings. It does not explicitly contrast itself with those similarly named siblings, but the resource is unambiguous.

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?

'Agents issue or verify a passport after a completed run; humans inspect its receipt and linked artifacts' gives a timing condition and audience split. However, nothing explains when to choose issue vs verify, or when to prefer a sibling like wever_atlas-asset-passport or wever_agent-trust-scorecard. Requirements are listed ('existing product credentials, signed mandates, and single-use action grants remain required') but no explicit exclusions or alternatives.

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