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

No annotations are provided, so the description bears the full burden of behavioral disclosure, and it fails to carry it. The word 'execute' implies a mutating, side-effectful operation, yet the description never states what happens: it does not disclose the payment implications (payment_credential and max_cost_cents strongly suggest a charge is made), whether the action is irreversible, what resources are consumed, or how idempotency_key affects repeated calls. For an execution tool with zero annotation coverage, this is a significant transparency gap.

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 description is a single concise sentence with no wasted words, and the verb is front-loaded. However, the brevity is achieved through under-specification rather than efficiency — one dense sentence packs jargon ('server-driven Capability Exchange order') that would be better spent on plain explanation. It is not bloated, but the single-sentence structure gives the agent nothing to scan or latch onto.

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 tool with 10 parameters, nested objects, no output schema, no annotations, and 35 siblings, the description is grossly incomplete. An agent cannot determine the input contract, the return value, whether money is charged, or when to invoke it. There is no explanation of what 'resolving' produces, what a 'Capability Exchange order' is, or how this relates to the purchase/quote/escalate cluster. This is severely inadequate for the tool's complexity.

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 only 10% — just supply_policy has a one-line description, while rail, prompt, order_id, max_cost_cents, capability_code, idempotency_key, payment_credential, required_responses, and expected_value_cents are all undocumented. The description text itself explains none of the 10 parameters. With coverage this low, the description was obligated to compensate but adds nothing, leaving the agent with nine unexplained parameters on a complex, payment-adjacent tool.

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 offers a verb ('resolve') and a resource ('standard request or reserve... Capability Exchange order'), but the terminology is dense domain jargon that a generalist agent cannot parse. 'Resolve' is ambiguous — it could mean fulfill, settle, process, or route — and 'server-driven Capability Exchange order' is never explained. It does not clearly distinguish itself from the 35 siblings, several of which (me_quote, me_purchase_execute, me_escalate) plausibly overlap with 'resolving an order.' It is not a pure tautology, but it is vague enough to fail at establishing a concrete, usable purpose.

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 gives zero guidance on when to use this tool versus alternatives. It names no sibling, states no exclusions, and offers no conditions or prerequisites. Given the large sibling set with overlapping-sounding operations (me_compare, me_quote, me_purchase_execute, me_escalate, me_approval), an agent has no basis to choose me_resolve over any of them. This is a clear absence of usage direction.

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