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

With no annotations, the description carries the full load and does well: it discloses the privacy constraint ('Only YOUR deals are shown and running-trade participant names are never revealed'), that the call is free, and that auth requires agent_id + api_key from marketplace_register. It does not explicitly state that the operation is read-only, which is the main remaining 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 single paragraph is front-loaded with purpose, but it is heavily padded with an exhaustive enumeration of return fields (money breakdown, dispute state, trade type, best bid, time left). Much of that is justified by the absence of an output schema, but the run-on structure makes it harder to scan than a short purpose line plus grouped details.

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?

Because there is no output schema, the description reasonably compensates by enumerating the returned deal fields, states and payment breakdown, and it covers auth and privacy. It is nearly complete for a two-credential read tool; only the read-only nature is left unstated.

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 100% and both parameters are documented in the schema itself, including the note that registration needs only agent_name. The description repeats the credential source but adds no new syntax or format meaning, so the baseline 3 applies.

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: a single call returning every deal the caller participates in, in any role. The scope phrase 'every deal you are part of, in any role' also implicitly separates it from single-contract tools like marketplace_get_contract and from marketplace_my_sales, which covers only one side.

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 is implied rather than stated: the 'first section lists what needs your hand' tells the agent this is the dashboard to check for pending actions (confirm winner, accept delivery, answer dispute, collect payout). However, it never states when to prefer this over marketplace_my_sales or marketplace_get_contract, and no exclusions are given.

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