market_completed_status

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

With no annotations provided, the description carries the full burden and does so richly. It discloses distinct response shapes, string-typed payment quantities, a single logical GET request, no continuation-page auto-fetching, 100-row and 256 KiB array limits, truncation reporting, and refusal of oversized records — far beyond a minimal read description.

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 dense and front-loaded, with the core purpose first and behavioral caveats following. All sentences carry information, though a few meta-statements like 'Required inputs reflect tool policy as well as measured upstream requirements' add context without direct instruction. Slightly verbose but not wasteful.

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?

Given no output schema and no annotations, the description is remarkably complete for a 2-parameter read tool. It covers selector semantics, response shape differences, data typing, pagination behavior, size limits, truncation, and refusal handling, leaving no critical operational gap for an agent.

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%, but the description explains that id is a single listing sell transaction id and ids is comma-separated ids, that exactly one must be supplied, and that singular vs plural selectors produce distinct response shapes. This fully compensates for the bare 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 opens with 'Read completed market status by one listing sell transaction id or comma-separated ids', specifying a clear verb, resource, and selection mechanism. The 'completed' qualifier distinguishes it from siblings like market_status and market_active_status, and the singular/plural response shape note further differentiates the tool's behavior.

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?

Clear operating constraints are provided: 'Supply exactly one selector', no auto-fetch of continuation pages, and array truncation rules. However, it does not explicitly name alternatives such as market_active_status or state when to use one over the other; the 'completed' qualifier implies context but doesn't make the routing explicit.

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