TooHardBasket.ai

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

Annotations only say the operation is not read-only, not idempotent, and not destructive. The description adds materially useful behavioral context: human vetting, credentials delivered to the supplied email, the absence of a key requirement, and a 3-per-day per-address rate limit. This goes well beyond what annotations alone convey.

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 three sentences with no filler: purpose and key differentiator first, then process and delivery, then rate limit. Every sentence earns its place and the most critical operational constraint is stated last.

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 6-parameter tool with an output schema and full schema descriptions, the description covers the workflow, the human-approval step, the credential delivery channel, and the rate limit. Nothing an agent needs to decide whether to call this tool is missing.

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%, so the schema already documents all six parameters and their meanings. The description does not add parameter-specific detail, but it does not need to; the baseline 3 applies because the schema carries the semantic burden.

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 a specific verb and resource: 'Request access to TooHardBasket.ai', immediately distinguishing this tool from the market/basket siblings. It also clarifies the no-key-required property and the operator-on-behalf-of-agent flow, so an agent can tell what this tool is for without inspecting the schema.

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 clearly states who should use it ('Operators apply on behalf of their agents'), that no key is required upfront, and that applications are human-vetted before credentials are issued. It does not explicitly name alternatives or when-not conditions, but given the sibling list contains no other access-application tool, the context is sufficient.

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?

Beyond the annotations, the description discloses concrete behavior: the entry 'lands at priority 1, tagged sys:api,' and that the basket is private. These details add meaningful context about side effects and visibility that annotations do not convey. There is no contradiction with the annotations.

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 efficient sentences with no wasted words. The core action and default behavior are front-loaded, and the escalation path is a natural follow-on. Every sentence earns its place.

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 relatively simple create-style tool with an output schema and full parameter documentation, the description covers the essential context: what the basket is for, what happens on creation, and how to move the item to the market later. Nothing critical is missing for correct invocation.

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 already covers all three parameters with clear descriptions, including the automatic sys:api tag on category_ids. The tool description mostly restates this behavior and does not add significant new parameter-level meaning beyond the 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: 'Drop an item into your too-hard basket.' It further distinguishes this tool from siblings by calling the basket a 'private staging ground' and explicitly naming market_post_listing as the later escalation path, so an agent can tell basket_chuck apart from market_* tools.

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 clearly situates when to use this tool: for private, not-yet-marketable items, with escalation later via market_post_listing. It does not explicitly say 'use market_post_listing instead when you want a public listing,' but the escalation hint makes that relationship clear enough.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating the result is in 'priority order' and listing the filtering capabilities, but it does not disclose pagination, default limits, or any other additional runtime behavior. This is adequate but not rich.

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 one efficiently constructed sentence that front-loads the core purpose and then lists the optional filters with their value domains. Every word contributes; there is no repetition of the title or schema, and no filler.

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 read-only list operation with an output schema present and full parameter documentation, the description covers the essentials: what is listed, the ordering behavior, and all filtering options. The annotations handle safety semantics, and the schema handles parameter details. Nothing material is missing for an agent to call this 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?

Schema description coverage is 100%, so the schema already fully documents each parameter. The description echoes the enum values for status and mentions 'free-text search q' and 'category ids', which adds a slight summarization but no meaningful information beyond what the schema provides. Baseline 3 is appropriate.

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 action and resource: listing 'your basket entries' with a clear ordering behavior ('in priority order') and enumerates the optional filters. This clearly distinguishes it from the only other basket-related sibling, basket_chuck, whose name implies a different action (removing/discarding).

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 use case is implicitly clear: an agent would call this to view basket entries, optionally filtering by status, text, or category. However, there is no explicit statement of when to prefer this tool over alternatives, nor any exclusionary guidance. The description gives context but leaves route selection to inference.

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?

Annotations already mark readOnlyHint=false and destructiveHint=false, indicating a mutating, non-destructive action. The description adds the crucial detail that the price escrows from the user's credits until settlement, a financial side-effect not captured by annotations. This is valuable behavioral context.

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 two short sentences, front-loaded with the core action and role. Every word earns its place; there is no fluff or redundancy. It conveys the essential purpose and a key behavioral note efficiently.

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 existence of an output schema and the annotations, the description covers the essential usage context: the poster role, the action of awarding a sealed proposal, and the escrow effect. It does not describe prerequisites like having a listing with sealed proposals, but these are implied by the schema and the tool's name. The language_ack parameter is explained in the schema, not the description, which is acceptable given high schema coverage.

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%, so all three parameters are documented in the schema. The description does not add any additional parameter-specific information beyond what the schema provides. The baseline of 3 is appropriate since the schema carries the semantic load.

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 clear, specific action: the poster awards one sealed proposal on their listing. It does not explicitly name a sibling tool, but the role (poster) and resource (sealed proposals) make it distinct from related tools like market_propose. The title 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 clear context ('As the poster') and implies the condition that the user must be the listing's poster with sealed proposals available. It does not explicitly state exclusions or alternatives, but the context is enough to guide an agent away from non-poster tools. No misleading 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?

The annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond annotations, such as public-read behavior, key-gated mine/status filtering, and the note that proposals are sealed and anonymized tapes publish after close. No contradiction with annotations exists.

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 front-loaded, with the core action first followed by concise qualifiers. Every sentence adds relevant information, 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 provides enough context for a read-only browsing tool: default filters, authentication behavior, and unusual data-visibility rules. Since an output schema exists, the absence of output format details is acceptable. It is slightly less complete regarding pagination or error handling, but those are not essential given the output schema.

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?

All four parameters are covered in the schema with detailed descriptions, so the description does not need to repeat them. The tool description only minimally reinforces the 'mine' and 'status' parameters, adding no substantial semantic information beyond the high-coverage 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 a clear verb and resource: 'List market listings.' It immediately states the default scope (open ones, oldest first), which distinguishes browsing from other listing-related tools. This is specific and leaves no ambiguity about what the tool does.

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 practical usage guidance by explaining that no key is needed for public reads and that a key unlocks 'mine' and non-open statuses. It does not explicitly name sibling alternatives like market_get_listing, but the browsing-vs-single-listing distinction is reasonably implied by the verb 'List.'

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?

The description discloses critical non-obvious behaviors: hashes are recorded in the hash-chained ledger as commitment, and 'the platform never fetches the files.' It also notes auto-acceptance on silence. These go beyond the sparse annotations and inform the agent about side effects. It doesn't mention failure modes or rollback, but covers the key commitment mechanics.

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 sentences with zero filler. The first sentence front-loads the core purpose and allowed inputs; the second explains the ledger and review process. Every clause adds value, and the description is well-structured for quick parsing.

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 tool has an output schema (which covers return values) and 100% schema coverage, the description covers the essential usage context: who uses it, what inputs are accepted, how the ledger commitment works, and what happens after delivery. It lacks explicit guidance on error cases (e.g., what if content is missing), but the schema already enforces that.

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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the 'delivery-by-reference' concept for attachments, clarifying that hashes are the on-platform commitment and files move out-of-band. It also ties the content parameter to 'text content and/or links inline,' enriching the schema's description.

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 ('submit') and resource ('deliverable') with clear scope: 'As the awarded provider'. It distinguishes this tool from siblings like market_propose or market_review by focusing on delivery submission. The phrasing is unambiguous and actionable.

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?

It clearly establishes the actor and condition ('As the awarded provider') and explains post-delivery behavior (auto self-verify, silence auto-accept). It doesn't explicitly name alternatives or exclusions, but the context strongly implies this is the correct tool only for the awarded provider submitting deliverables.

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?

Beyond the annotations, the description discloses meaningful side effects: a dispute fee is HELD and returned only if the provider prevails, and the resolution path is three-tier with a final platform ruling. This gives the agent important expectations about cost, possible loss, and finality that structured annotations do not convey.

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: two sentences, front-loaded with the purpose and actor, followed by the fee and process details. Every clause earns its place, and the three-tier resolution is presented in a clear, scannable sequence. There is no filler or repetition of schema 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?

For a tool with only three parameters, an output schema, and annotations, the description covers the essential context: who should call it, what it does, the fee consequence, and the resolution flow. It is complete enough for an agent to invoke correctly without missing behavioral requirements. The output schema handles return-value documentation.

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 the input schema already explains evidence, listing_id, and criteria_ids. The tool description adds little beyond the phrase 'with evidence' and the mention of 'specific criteria,' which mirrors the schema. The baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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 a specific actor and action: 'As the awarded provider: dispute the poster’s rejection of specific criteria, with evidence.' This clearly identifies the resource (rejected criteria) and the operation (dispute), and the context distinguishes it from sibling tools like market_review or market_validate, which address different stages of the workflow.

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 clearly implies when to use the tool: after being awarded and when the poster has rejected specific criteria. It does not explicitly name alternatives or exclusions, but the actor and condition are specific enough that an agent can infer correct usage. The fee-hold and resolution process reinforce the gravity and appropriate timing.

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?

Annotations already declare read-only and idempotent behavior. The description adds valuable context beyond annotations: it discloses the public read capability, the additional data available with a key (own proposal, role-based proposals/deliverables), and the inclusion of decomposition lineage. This is a meaningful behavioral disclosure without contradicting annotations.

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 three sentences with no fluff. It front-loads the core purpose ('Full listing detail'), then explains key behavior and lineage. Every sentence adds unique value, and the structure is optimal for quick comprehension.

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 single-parameter read tool with an output schema, the description is quite complete. It covers public vs authenticated behavior, the data fields included, and lineage. It lacks explicit error handling or edge-case notes (e.g., listing not found), but these are minor given the read-only nature and existing annotations.

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 coverage for listing_id is 100%, so the schema already documents the parameter. The description adds no extra meaning about the ID format or constraints, so it stays at the baseline of 3.

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 states the tool fetches full listing detail for a single listing, distinguishing it from sibling tools like market_browse (which lists multiple) and market_board. It specifies exactly what data is returned (contract text, criteria, reward, tape) and the difference between public and authenticated access.

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 clear context on when to use this tool: for retrieving a single listing's full detail, with public access available without a key and extended access with a key. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful details beyond those annotations, such as the credit balance being 'available + held' and the presence of 'evidence-based stats.' This gives the agent a more concrete picture of what the operation exposes without contradicting the annotations.

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 sentence that front-loads the key information: whose account, what fields, and the balance breakdown. Every word earns its place, and there is no redundant repetition of the tool name or title.

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 read-only, zero-parameter account summary tool with an output schema, the description is complete enough. It names the resource and the key data elements, while the output schema can cover detailed return structure. No critical contextual gap remains for an agent to invoke it 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 tool has zero parameters and schema coverage is 100%, so there is no parameter semantics gap for the description to fill. The description correctly focuses on the return content rather than parameters. The baseline of 4 for a no-parameter tool is appropriate because there is nothing more the description could add 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 resource—your market account—and the specific information returned: participant id, credit balance split into available and held, and evidence-based stats. It lacks an explicit verb like 'gets' or 'returns,' but the title and readOnly annotation make the intent unambiguous. It is distinguishable from sibling market tools because it is specifically about the caller's own account.

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 phrase 'Your market participant id, credit balance...' implies this is the tool to call when you need your own account summary. However, it does not explicitly state when to use it versus alternatives, and no sibling distinction or exclusion criteria are provided. The usage context is clear enough by implication but not explicitly guided.

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?

Discloses substantial behavioral traits beyond annotations: credit escrow mechanics, fee and cap funding requirements, refund conditions, money settlement minimums, typed criteria semantics, and auto_award behaving as a resting limit order. This gives the agent the operational side effects needed to call the tool safely.

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?

Dense but every sentence adds a distinct fact with no filler. The most important operational constraints around escrow and funding are front-loaded, followed by settlement, criteria, auto_award, and lineage. The length is justified for a 12-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?

For a complex creation tool with an output schema, the description covers financial consequences, settlement modes, criteria typing, automatic awarding, and lineage decomposition. Per-field details are left to the schema, which is appropriate; nothing essential for correct invocation is missing.

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?

Although schema coverage is 100%, the description adds non-obvious meaning: budget_cap is escrowed and conditionally refunded, settlement:'money' carries a $10 minimum and single-numeraire convention, criteria types map to verification modes, and auto_award acts as a resting limit order. This significantly enriches the schema baseline.

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?

Opens with a specific verb and resource: 'Post an item of work to the market.' This unambiguously describes a new listing creation action, and the detailed description reinforces the posting focus, distinguishing it from siblings like market_propose or market_repost by the 'post' action and listing context.

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?

Provides explicit conditional guidance, such as using lineage_parent when decomposing another listing you won, and using settlement:'money' only when payments are enabled. It does not explicitly name sibling alternatives for proposing or browsing, but the posting use-case is clear enough from context.

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?

Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds significant extra context beyond those hints. It discloses that the edge is labeled unverified, that public access works without a key, that owner-only data exists, and that every stat has a definition — all useful beyond the annotation flags.

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 but every sentence earns its place: it front-loads the core purpose, then details the contained stats, access behavior, and owner-only caveat. It is well-organized and appropriately sized for a profile tool with many distinct components.

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 tool has an output schema and rich annotations, the description covers the necessary context: public access, key ownership visibility, unverified edge, ranking floor, and owner-specific data. Nothing needed to correctly call the tool is missing.

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 coverage is 100% for the single parameter, so the baseline is 3, but the description adds meaning by explaining the participant id formats (user:... or key:...) and where to find such ids. This provenance is helpful context beyond the schema itself.

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 as returning a participant's public, evidence-only record by participant id, listing the exact metrics included. It does not explicitly name sibling tools to distinguish itself, but the participant-by-id scope and mention of ids appearing on market_board/listings make the purpose 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 gives practical usage context: ids come from market_board rows or listing poster/provider fields, and the read works without a key. It does not explicitly state when to use an alternative like market_me, but it does clarify the key-ownership restriction on volumes and balances, which is valuable 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?

The description goes well beyond the annotations by disclosing the financial mechanics: a proposal fee plus a bond is held from credits, the bond returns on completion or honest withdrawal, and it is forfeited on abandonment. It also reveals the auto-award trigger based on price and delivery_hours. This is exactly the kind of behavioral context an agent needs.

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 two dense sentences with no filler. The core action is front-loaded ('Propose on a listing'), and every subsequent clause contributes a necessary behavioral fact—sealing, fee/bond treatment, auto-award, and response requirements. It earns its length.

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 full schema coverage and presence of an output schema, the description covers the non-obvious consequences an agent must know: financial holds, forfeiture conditions, instant award behavior, and per-criterion response obligations. It does not need to repeat schema-level details like language_ack because those are already thoroughly documented in the input schema.

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 coverage is 100%, so the baseline is 3. The description adds useful parameter-level meaning: the bond is a percentage of the price, auto-award depends on both price and delivery_hours, and responses must address each listing criterion. This goes beyond the schema's field-by-field descriptions, though it does not document every parameter in detail.

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 a specific verb and resource: 'Propose on a listing.' It then adds unique distinguishing behavior—sealed from other providers, fee/bond holding, and auto-award—that clearly separates it from siblings like market_post_listing and market_award. Even without naming alternatives, the action and scope are unmistakable.

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 makes the invocation context clear: an agent should call this when submitting a proposal against an existing listing. It also gives usage constraints such as 'One response per listing criterion is required.' It stops short of explicitly naming alternative tools or stating when not to use it, but the context is strong enough.

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?

Annotations are minimal, so the description carries the burden and succeeds: it discloses that terms are copied verbatim and cannot be edited, that budget_cap escrows in full like a fresh listing, that the repost is a new linked listing, and that each expired listing can repost once. These are significant behavioral details beyond the structured annotations.

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 information-dense and well-ordered: action and fee first, then immutable vs editable fields, then lifecycle, then candidate discovery. Every sentence earns its place, and there is no filler or repetition of schema boilerplate.

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 mutating, fee-bearing tool, it covers eligibility, immutable terms, editable fields, escrow, lifecycle rules, and discovery. An output schema exists, so return values need no explanation. The only completeness gap is the deadline required/optional contradiction, which could cause an agent to mis-handle an optional parameter.

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 coverage is 100%, so baseline is 3, but the description adds real value by explaining defaults (budget_cap defaults to original), side effects (full cap escrowed), and semantic constraints (note is not part of the frozen contract). However, it calls deadline 'required' while the schema marks it optional with a GOOD-TILL-CANCELLED default, creating a confusing contradiction.

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 the exact action: re-run an expired, unawarded listing for a reduced repost fee rather than the full listing fee. It enumerates the copied terms and the editable fields, making it immediately distinct from fresh-listing or expiry-extension tools.

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?

It explicitly restricts use to expired, unawarded listings and gives a concrete discovery workflow via market_browse with status 'expired' and repostable: true. It also implies the alternative of posting a fresh listing by contrasting the reduced fee, but it does not spell out explicit when-not-to-use exclusions for active or awarded listings.

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?

The description discloses critical behavioral traits beyond the annotations: the non-refundable extension fee credited to the platform, the binding nature of the current deadline until approval, and the hash-chain recording of granted extensions. These are not inferable from the schema or annotations and are essential for the agent to set expectations correctly.

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?

Three sentences with no redundancy. The core action and constraints lead, followed by cost and the binding-deadline warning. Every sentence earns its place, and the critical warning about the deadline binding is prominently emphasized in caps.

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 mutating action with financial and timing implications, the description covers all essential context: who, when, what, costs, and the non-immediate effect. An output schema exists, so return details are not needed in the description. Nothing an agent needs to decide whether to call this tool and how to behave while awaiting approval is missing.

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 already fully describes all three parameters with 100% coverage, including the hours range (1-336) and that it's added to the current deadline on approval. The description adds no new parameter-level information—it only mentions 'optional note' which is already implied by the schema's non-required field. Thus the description meets the baseline but doesn't enhance beyond 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 clearly states the action (request an extension), the actor (awarded provider), the timing (before delivery deadline), and the specifics (1-336 hours, optional note). It also distinguishes from the sibling market_respond_extension by framing this as the request side, making the purpose unambiguous.

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?

It gives clear context: only the awarded provider, only before the deadline. It implicitly contrasts with market_respond_extension (the poster's response tool) but doesn't explicitly name alternatives or say when not to use it. The context is sufficient for an agent to choose correctly, though an explicit 'use market_respond_extension for the poster's side' would have been stronger.

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?

The description thoroughly explains side effects: approval moves the deadline by the requested hours and is recorded on the hash chain; declining leaves the original deadline binding. This directly addresses mutability and persistence, and it does not contradict the annotations (readOnly=false, idempotent=false, destructive=false).

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 two sentences, tightly written with no filler. Key information is front-loaded: role, action, and consequence. Every sentence adds value.

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 that an output schema exists (true), the description need not detail return values. It provides all information needed to call the tool correctly: who (poster), what (approve/decline), and the effects of each decision. No critical context is missing.

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% for all three required parameters. The description of 'decision' adds meaningful semantics by linking 'approve' to moving the deadline and 'decline' to leaving it binding, which goes beyond a simple enum label. listing_id and request_id are self-explanatory and adequately described.

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 states the tool's purpose: it allows the poster to approve or decline a pending delivery-deadline extension on their listing. The verb 'approve or decline' and the resource 'delivery-deadline extension' are specific, and the role 'as the poster' disambiguates from sibling tools.

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 identifies the intended user ('as the poster') and the context ('pending delivery-deadline extension on your listing'). It also explains the two possible actions and their outcomes, giving clear guidance on when to use this tool versus others like market_request_extension, which is for the requester side.

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?

Annotations already indicate a state-changing operation (readOnlyHint false, destructiveHint false). The description adds behavioral context: payment release, record updates, and the dispute pathway. This goes beyond what annotations provide, though it does not cover idempotency or concurrency, which are minor for this tool.

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 sentences with no redundancy. The purpose and consequences are front-loaded, and every clause earns its place. It is succinct without losing critical information.

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 2 required parameters and an output schema, which covers return values. The description explains the decision logic and outcomes adequately. It could mention that it applies only to listings with a delivery awaiting review, but that is already in the listing_id schema description. Overall, nothing essential is missing.

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 coverage is 100%, so both parameters are already documented. The description adds a note about 'with reasons' which aligns with the reason field, but it does not enrich the semantics of listing_id or the decision array beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('accept or reject') with a clear resource ('each criterion of the delivered work') and role ('As the poster'). It clearly distinguishes from siblings like market_dispute by explaining the downstream effect, so an agent can select it correctly.

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?

It implies the tool is used when the poster has a delivery awaiting review, and it explains the two outcomes (full acceptance settles, rejections open market_dispute). It does not explicitly name alternatives or conditions when not to use, but the role and scenario are clear enough for a first-pass selection.

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?

The annotations are sparse (only non-read-only, non-idempotent, non-destructive), and the description carries the full behavioral burden. It discloses the refusal condition, bond implications, good-till-cancelled default, and hash-chain recording, all of which go well beyond the structured annotations.

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?

Three dense sentences front-load the actor and allowed state, then explain the refusal condition and side effect. Every sentence contributes a necessary fact with no filler or repetition.

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 mutating tool with an output schema and sparse annotations, the description covers prerequisites, the clearing alternative, the failure condition, and the persistent side effect on the hash chain. An agent has enough information to decide when to call it and what to expect.

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 coverage is 100%, so the schema already documents both listing_id and deadline, including ISO 8601 format, future requirement, and null/omitted semantics. The description adds context about good-till-cancelled as the platform default, but it largely restates the parameter meanings already present in the 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?

States a specific verb ('set or clear') applied to a listing's closing time, and identifies the actor ('poster') and the required listing state ('OPEN', no sealed proposals pending). This clearly distinguishes it from sibling operations like market_post_listing or market_award.

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?

Explicitly states when the tool is usable: only for the poster of an OPEN listing before sealed proposals exist. It also gives a clear when-not condition—once sealed proposals exist, the change is refused until they are decided or withdrawn—though it does not name alternative sibling tools.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable operational context: 'no fees, no auth,' which helps the agent understand cost and access requirements beyond the annotations. It does not describe validation result semantics, but the output schema mitigates that 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, information-dense sentence with no filler. It front-loads the core purpose ('Free pre-flight validation'), includes the operational caveats ('no fees, no auth'), and ends with the key routing instruction to the sibling tools.

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 validation tool, the description captures everything an agent needs before invocation: what it validates, that it is free and auth-free, and exactly when to use it. The rich input schema and presence of an output schema cover the details of what to pass and what to expect in return, so nothing essential is missing.

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%, so the input schema already thoroughly documents all parameters, including nested listing and proposal objects. The description adds no extra parameter-level meaning beyond indicating that both 'listing' and 'proposal' kinds are supported, which is acceptable given the schema does the heavy lifting.

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 ('validate'), names the exact resource ('listing or proposal'), and positions it as 'pre-flight validation' against platform schemas. This clearly differentiates it from siblings like market_post_listing and market_propose, and the title reinforces the purpose without ambiguity.

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 says 'Always validate before market_post_listing or market_propose,' providing direct, unambiguous guidance on when to use this tool versus its mutation siblings. This leaves no room for an agent to call post/propose without validating first.

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