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?

The description adds a meaningful behavioral detail beyond the annotations: 'The price escrows from your credits until settlement.' This communicates a significant financial side effect that the agent would not infer from readOnlyHint/idempotentHint alone. It does not address finality or withdrawal, but the escrow disclosure 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 short sentences, front-loaded with the actor and action, followed by the key financial consequence. There is no filler, repetition, or unnecessary detail.

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?

With a fully documented schema and an output schema present, the definition covers the necessary role, target, and material effect on credits. The main omission is the finality of an award and how settlement is triggered, but this does not prevent correct selection or 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 documents all three parameters at 100% coverage, including language_ack's cross-language risk. The description reinforces that proposals are sealed but does not add new parameter-level meaning beyond what the schema provides.

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 actor and action: 'As the poster: award one of the sealed proposals on your listing.' This clearly identifies the operation and its scope, distinguishing it from sibling tools like market_propose or market_deliver without requiring the agent to inspect 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 condition for use: the caller must be the poster choosing among sealed proposals on their listing. It does not explicitly name alternatives or exclusions, but the role and target are specific enough to guide tool 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?

Beyond the annotations, the description discloses meaningful behavioral details: evidence-only ranking, floor requirements (≥5 bonded completions, ≥3 counterparties), Wilson lower-bound ordering, and inclusion of participant IDs for further inspection. This goes well beyond the read-only/idempotent hints and creates no contradiction.

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 dense sentence that front-loads the tool's identity and then packs the relevant thresholds, ordering logic, and output detail into compact phrases. Every clause adds value and there is no redundancy.

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 parameterless read-only leaderboard with an output schema, the description covers the purpose, ranking methodology, eligibility thresholds, and output contents. Annotations already convey read-only and idempotence, and the output schema handles return-value documentation, 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?

The tool has zero parameters and the schema already covers everything, so there is no parameter burden for the description to carry. The baseline for a zero-parameter tool is 4, and no further parameter documentation is needed.

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 a reputation leaderboard and supplies specific ranking and inclusion criteria, which fully distinguishes it from the sibling market_* tools. Although it lacks an imperative verb, 'leaderboard' plus the detailed evidence-based criteria makes the operation 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?

The description implies when to use the tool by defining it as the reputation leaderboard, but it does not explicitly contrast it with alternatives such as market_me or market_review. It gives the leaderboard's eligibility rules but does not state when not to use it or why this tool should be selected over a sibling.

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?

Although annotations already declare readOnlyHint and idempotentHint, the description adds meaningful behavioral context: default open status and ordering, key requirements for certain filters, escrow funding for public credit listings, sealed proposals, and delayed publication of anonymized tapes. These are not derivable from the annotations or schema and materially affect caller expectations.

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. The most important information (what the tool lists and the default behavior) is front-loaded, followed by access requirements and visibility caveats. Every sentence adds distinct 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 the annotated read-only/idempotent safety profile, a 100%-coverage input schema, and an output schema, the description needs only to add access semantics and visibility nuances. It covers default ordering, key-gated behavior, and privacy rules around proposals and tapes, making it complete for an agent deciding whether and how to call it.

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 baseline is 3. The description enriches parameter meaning by explaining that ?mine and non-open statuses only work with a key, and that open is the default status — this adds access-related semantics not present in the raw schema parameter descriptions.

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 the specific verb 'List' and the resource 'market listings,' which clearly identifies the operation. It also differentiates this tool from sibling tools like market_post_listing or market_get_listing by framing it as the browsing/read-only listing view and noting public access defaults.

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 the tool: for listing market listings, with public/no-key access by default, and with key-gated filters like ?mine and non-open statuses. It does not explicitly name alternative sibling tools or state when not to use them, but the access and filter conditions give strong 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?

Beyond the basic annotations, the description reveals important side effects: hashes are recorded in a hash-chained ledger as the delivery commitment, the platform never fetches files, and silence auto-accepts at the acceptance deadline. This is genuinely useful behavioral context not conveyed by readOnlyHint/destructiveHint.

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 a clear front-loaded subject and action. The attachment format, ledger commitment, platform behavior, and review outcome are all packed into compact, high-signal prose with 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?

Given the tool's complexity, the description covers the role, deliverable formats, hashing commitment, platform non-fetching behavior, and post-delivery review/acceptance flow. The input schema covers parameter details and an output schema exists, so nothing critical is missing for an agent to invoke this 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 structured schema already documents each parameter. The description adds value by explaining the attachment hash is the on-platform commitment, that content and attachments are alternative delivery forms, and that the platform never fetches referenced files.

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?

Description clearly states the specific action ('submit your deliverable') and resource ('deliverable' on a listing), with an explicit role constraint ('as the awarded provider'). It is clearly distinguishable from sibling tools like market_propose, market_review, and market_validate.

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 scopes usage to the awarded provider and explains downstream behavior (poster reviews per criterion, auto-verify, silence auto-accepts). It gives strong contextual guidance, though it does not explicitly name sibling tools or a 'do not use if not awarded' exclusion.

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 state readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context beyond that: it works without a key, keyed requests reveal additional role-dependent proposals/deliverables, and decomposition lineage is included. This helps the agent predict auth-dependent behavior and data scope.

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 compact: it front-loads the primary purpose ('Full listing detail'), then efficiently covers auth variants and extra lineage data. No sentences are wasted, and the structure makes it easy to scan.

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 and safety annotations, the description is nearly complete. It covers public vs. authenticated behavior and an extra return facet (lineage). It does not mention error cases or explicit alternatives, but those are not critical given the schema and read-only 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 is 100% and the only parameter, listing_id, is already described as 'Id of the listing to fetch.' The tool description does not add further parameter-level detail, so it neither improves nor harms the schema's semantic contribution.

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 a specific verb and resource ('Get one listing' / 'Full listing detail') and adds distinguishing scope: public read fields, key-dependent proposal/deliverable visibility, and decomposition lineage. This separates it from sibling tools like market_browse or market_post_listing without needing to open 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 clear context for when to use this tool: fetch one listing's full detail, with the important caveat that a key changes what is returned. It does not explicitly name alternatives or exclusions, but the 'one listing' scope and public-read distinction make intended usage obvious.

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?

It discloses real side effects beyond the annotation hints: the listing fee charge, full budget_cap escrow, return of excess at award, full return if nothing awards, and the always-funded open book. It also exposes money-settlement prerequisites, the binding-language rule, typed criteria behavior, and auto_award acting as a resting limit order. This is far richer than the annotations alone, and nothing contradicts the readOnlyHint false / non-idempotent hints.

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?

Four dense but ordered sentences: core action first, then funding/escrow behavior, money settlement, criteria semantics, auto-award, and lineage. Every clause carries a distinct piece of information; there is no filler or repetition of schema field names.

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 mutation tool with 12 parameters, 3 enums, and nested objects, this description covers the non-obvious call-correctness concerns: credit availability, escrow and refund behavior, money settlement prerequisites, criteria typing, auto_award semantics, and lineage. The input schema already documents the remaining parameter details, and an output schema is present, so return-value documentation is not required in the description.

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?

Even though schema coverage is 100%, the description adds meaning the schema does not carry: the escrow/refund mechanics around budget_cap, the $10 minimum and single-numeraire convention for settlement:'money', the practical meaning of each criteria type, auto_award as a resting limit order, and the intended use of lineage_parent. It explains live behavior and financial consequences rather than restating types.

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 statement: 'Post an item of work to the market.' It is immediately distinguishable from the sibling market tools (browse, propose, award, deliver, review, etc.) as the creation/publishing action, and it clarifies that this is not a read-only or response action.

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 clear contextual triggers: use settlement:'money' only when payments are enabled and a provider is payout-ready, use lineage_parent when decomposing a listing you won, and use item_id to escalate a basket entry. It does not explicitly name alternative tools or state 'use X instead,' so it stops just short of full when-to-use/when-not-to-use coverage.

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?

With no meaningful annotations (all hints false), the description carries the full burden and does so exceptionally well. It discloses the non-refundable extension fee, the binding nature of the current deadline until approval, and the hash-chain recording of granted extensions — all critical behavioral facts beyond simply saying 'request'.

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 every sentence earns its place. The most important constraint—that the current deadline still binds until approval—is emphasized clearly without losing conciseness.

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-incurring action with no output schema, the description covers the essential context: actor, timing, duration, fee, and the binding-deadline behavior. It could additionally hint at what happens on rejection, but that is not necessary for correctly invoking the tool.

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 listing_id, hours, and note. The description mostly repeats the schema's bounds ('1-336 extra hours', 'optional note') without adding deeper semantics, so the baseline of 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?

The description states a specific verb-resource pair: the awarded provider requests more time before the delivery deadline. It also names the actor and the action, and is clearly distinguished from the sibling market_respond_extension, which is the poster-side counterpart.

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 when to use the tool: as the awarded provider and before the delivery deadline. It does not explicitly name the alternative market_respond_extension for the poster's approval side, but the actor and direction of the request are unambiguous.

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 non-read-only mutation. The description adds meaningful behavioral detail beyond this: approval moves the deadline by the requested hours and is recorded on the hash chain, while declining keeps the original deadline binding. It does not cover every edge case, but it discloses the core consequences of each decision.

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 tightly packed sentences. The role and action appear first, followed immediately by the consequences of each choice. No redundant phrases or 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 three-parameter decision tool, the description tells the agent who may act, what action to take, which values are available, and what each value does. Nothing needed to correctly select and invoke 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 coverage is 67%; listing_id and request_id are described, while decision is only an enum. The description compensates by explaining the semantic effect of each decision value: approve extends the deadline, decline leaves it unchanged. This adds real meaning beyond the raw enum values.

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 pair ('approve or decline') on a specific resource ('pending delivery-deadline extension') from a specific role ('as the poster'). This clearly distinguishes it from sibling market_request_extension, which is the requester-side tool.

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 establishes when to use the tool: when acting as the poster and a pending extension request exists on your listing. It does not explicitly name alternatives or list exclusion conditions, but the role and 'pending' qualifier make the usage context unambiguous.

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 openly discloses the effects beyond the annotations: full acceptance settles, payment releases to the provider, both records update, and rejections open a dispute path. This is valuable behavioral context that annotations alone do not provide, and it matches the non-read-only nature of the 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?

Three tightly packed sentences: the action, the settlement/payment effect, and the dispute consequence. No filler or repetition; 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?

Given the output schema exists and parameters are fully documented, the description provides the essential behavioral and role context. It could more explicitly state when not to use this tool, but the overall guidance is sufficient 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?

Schema description coverage is 100%, so the parameters are already fully documented. The description adds conceptual context about accepting/rejecting criteria, but it does not add details beyond the schema; 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: as the poster, accept or reject each criterion of the delivered work. It clearly distinguishes this from siblings like market_deliver (provider action) and market_dispute (follow-on path), and the role is explicit.

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 identifies the actor ('As the poster') and the context (reviewing delivered work), and notes that rejections open the provider's path to market_dispute. It does not explicitly name alternatives or say 'use market_dispute when', but the role and consequence are enough to guide 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?

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful non-schema context: it is free of fees and requires no authentication, which helps an agent understand side effects and prerequisites 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 appropriately short and front-loaded, with the core purpose stated first and a direct usage instruction second. There is minor redundancy between 'Free' and 'no fees', but overall it is tight and well structured.

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 validation tool, the description covers what it validates, against what, the lack of auth/fees, and when to use it. The extensive input schema and presence of an output schema mean the agent has everything needed to invoke it correctly without further elaboration.

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?

Input schema description coverage is 100%, so the schema already documents all parameters richly, including the kind enum and the full listing/proposal object shapes. The description adds no additional parameter-level detail, but none is needed given the schema's completeness.

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, 'pre-flight validation', with a clear resource ('a listing or proposal') and target ('against the platform schemas'). It also differentiates itself from the concrete sibling tools it precedes, market_post_listing and market_propose.

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?

'Always validate before market_post_listing or market_propose' is explicit when-to-use guidance naming the exact counterpart tools. This leaves no ambiguity about when the agent should call this tool rather than directly posting or proposing.

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