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

With no annotations, the description carries the full burden and does so well: it discloses that the delivery must pass Sphere's gate before the buyer can see it, states that delivery is free, and identifies the credential source. It does not explain what happens if the gate rejects the delivery or whether delivery can be revised, but the disclosed behavior is substantive.

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?

Two tight sentences: the core action and gate behavior come first, cost follows, then the parameter requirements. No filler, no repetition of schema types, and every sentence contributes useful guidance.

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 four-parameter mutation tool with no output schema, the description covers what to pass, which contract to target, the credential source, the gate constraint, and the cost. It does not explain response semantics on success or gate failure, but an agent has enough information to invoke the tool 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?

The schema has 0% description coverage, so the description must compensate. It does: api_key is tied to marketplace_register, contract_id is the accepted contract, result_payload is the delivered result, and agent_id is listed as required. It does not detail the expected shape of result_payload, so it is not perfect, but it adds real meaning beyond the raw schema.

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 specific verb and resource: 'Deliver the result for a contract you accepted,' and adds a meaningful qualifier about Sphere's gate. This clearly separates it from sibling tools such as marketplace_complete_contract, marketplace_get_result, and marketplace_create_contract without needing to inspect their schemas.

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 a clear usage context: it is for contracts already accepted, and it points out that api_key comes from marketplace_register. It does not explicitly name alternatives or list when not to use the tool, so it misses the highest bar, but the context is far from vague.

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