SOLVED — buy work already done

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

With no annotations, the description carries full weight for behavioral disclosure. It explicitly notes that opening a listing is recorded as deliberate interest (a side effect) and that the artifact arrives only after payment. This adds meaningful context beyond the simple 'get' operation, though it doesn't cover error cases or authentication.

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 short paragraphs with front-loaded purpose. The first sentence is clear and specific; the second and third sentences add essential behavioral details (payment timing, recorded interest). No wasted words.

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?

An output schema exists, so return values don't need elaboration. The description covers core purpose, the side effect, and the payment timing. However, the unmentioned agent_id parameter is a notable gap. For a simple two-parameter tool, it is mostly complete.

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. While 'one listing' implies listing_id, the agent_id parameter is completely unexplained. The description adds minimal value for one parameter but leaves the other entirely undocumented.

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 explicitly states it returns full public details for one listing, listing concrete fields (price, verification, bond, refund window, seller record, URL). This clearly distinguishes it from sibling tools like market_stats (aggregate stats) and search_solved (search-focused).

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: you use this when you need detailed information for a specific listing. However, there are no explicit statements about when to use it versus alternatives like search_solved or standing_demand, nor any when-not-to-use guidance.

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

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

With no annotations, the description carries the burden and does so excellently. It discloses that totals include the operator's own seed-agent trades and verification runs, and that the organic split is stated separately. It also warns about potentially misleading demand reporting—valuable behavioral context beyond basic read-only/write labeling.

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 moderately sized and largely front-loaded with the key output categories, but the final sentence ('A marketplace that reports its own seeding...') is rhetorical and does not help an agent select or invoke the tool. Somewhat over-written for a zero-parameter tool.

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 the output schema exists and there are no parameters, the description sufficiently conveys what data the tool returns and how to interpret it. However, it omits explicit usage context relative to siblings, which prevents a perfect score.

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 tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the stats contain rather than parameter syntax, which is irrelevant here.

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 clearly identifies the tool's resource (market statistics: published indexes, recent trade tape, windowed volume) and conveys that it provides aggregate venue numbers. It lacks an explicit verb like 'get' or 'list', and does not directly contrast with sibling tools, so it falls short of 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?

No when-to-use or alternative guidance is provided. The only instruction is to 'Read the organic figures, not the totals,' which is interpretive advice for the output, not guidance on selecting this tool over siblings like standing_demand or search_solved.

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

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

With no annotations provided, the description carries the full burden. It adds useful context like 'Free, no wallet,' which is beyond the schema. However, it doesn't explicitly state the read-only nature or describe what the response contains, leaving some ambiguity about behavioral traits. It is not misleading, but not fully transparent.

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 succinct, with the main verb and resource in the first sentence. It then provides immediate usage guidance in a compact second paragraph. Every sentence adds value, and there is no redundant or filler content.

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?

The description is complete enough for a search tool with an output schema: it explains the tool's purpose, when to use it, and the cost (free). It doesn't explain return values, but the output schema covers that. Minor gaps include not mentioning any limitations or behavior with no results, but overall the context is sufficient.

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 covers 100% of parameters with clear descriptions, so the baseline is 3. The tool description does not add parameter-specific details, but it provides context about the types of problems (e.g., 'a reference table, a parser') that indirectly helps understand the 'problem' parameter. This matches the baseline without exceeding it.

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 uses a specific verb ('Search') and resource ('work already done'), clearly stating the tool's function. It distinguishes itself from sibling tools by explicitly focusing on finding pre-existing solutions rather than listings, stats, or demand. The context 'before you recompute it yourself' reinforces the 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 provides explicit guidance on when to use the tool ('when you are about to solve something a stranger has plausibly already solved') with concrete examples. It does not explicitly mention when not to use it or alternatives, but the clear use-case framing is strong enough to score above average.

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

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

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the bids are resting and already escrowed, selling at or under a bid results in immediate payment, the gap between best bid and asking price represents the opportunity, and an empty list is an honest 'no bids' answer. This is solid behavioral context, though it doesn't discuss response ordering or pagination.

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 compact and well-structured, starting with a clear value proposition, then explaining the operational meaning and edge case. Every sentence adds useful information without redundancy. It is appropriately sized for a simple tool.

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?

The tool has an output schema, so return-field details are not needed here. The description covers the core behavior, the meaning of the data, and the empty-list case. It could be more complete by mentioning the `limit` parameter's effect, but for a one-parameter tool with an output schema, it is sufficiently complete.

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 input schema has one parameter, `limit`, with a default of 10 and 0% schema description coverage. The description does not mention `limit` at all, nor does it explain how to control the number of results. While the parameter name is self-explanatory, the description fails to compensate for the low schema coverage, so this dimension is under-served.

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 clearly identifies what the tool does: it lists standing bids with money already escrowed, providing the sell-side view of what the city will pay for right now. It distinguishes this from a generic listing by explaining the bids are resting and funded, and by noting the tool's relevance to sellers. The sibling tools (get_listing, market_stats, search_solved) are contextually different, and this description makes the tool's specific resource and perspective clear.

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 explicitly states when to use the tool: "If you produce anything, read it," and explains that the sell-side view shows immediate payment opportunities. It also clarifies the meaning of an empty list. However, it does not explicitly mention alternative tools or when not to use this one, so it stops short of a perfect score.

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