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

With annotations already declaring destructive=true and readOnlyHint=false, the description adds substantial behavioral context beyond them: nonfinancial single-unit reservation semantics, credential-binding of usage/attribution, idempotency requirements, immutability of records, and explicit non-execution/non-delivery boundaries. This is exactly the value-add structured fields cannot carry.

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?

Front-loaded and information-dense, but repetitive: the non-execution/non-delivery/non-payment boundary is stated at least three times across the paragraph. Several sentences restate the same operating limit, diluting signal.

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?

For a complex multi-mode control-plane tool with no output schema, the description covers the lifecycle, credential requirements, and safety boundaries well. It leaves the eight distinct modes to the schema, which is defensible, but an agent still lacks an at-a-glance mode map.

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?

Reported schema coverage is 0% for the top-level `mode` parameter, but the description conveys the semantic model (issue, approve, consume) without mapping to the specific enum modes. The oneOf branch descriptions in the schema do the per-mode heavy lifting. The description compensates partially but does not enumerate or explain the mode values, so a baseline 3.

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 concrete verb+resource: issue signed mandates and operator-approved action grants, then let credentialed agents consume them to create immutable work-order records. It also cleanly scopes what the tool is NOT (no work execution, delivery, or payment). It does not explicitly differentiate itself from siblings like wever_agent-work-order-rail or wever_ap2-mandate-gateway, so a 4 rather than 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?

Usage context is explicit: operators issue mandates and approve exact action grants with an idempotency key; only the bound credentialed agent may consume a grant; public drafts remain unsigned_dev and cannot execute. It gives required headers per role (X-Wever-Operator-Key, Idempotency-Key, X-Wever-Agent-Key). It stops short of naming alternative sibling tools to route to, so no 5.

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