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

With no annotations, the description carries the full burden and does well: it discloses that the resulting order is unfunded, that no funds move at this step, that the other quotes are declined (a real side effect an agent would not otherwise predict), and that full order-placement validation runs. It does not cover failure/partial-failure behavior, whether the decline of sibling quotes is reversible, or permission requirements.

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, all front-loaded and content-bearing: effect, then the money caveat and next tool, then the user-confirmation guardrail. No redundant restatement of the title or schema.

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 no annotations, no output schema, and an undocumented nested object parameter, the description explains side effects and the follow-on step but leaves the opaque 'input' field and the response shape unexplained. Adequate to call safely at a high level, incomplete for construction of the arguments.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description names no parameters at all. The nested free-form 'input' object is entirely opaque, and 'request_id' is never explained as an idempotency or correlation key, so an agent must guess at both beyond the bare UUID types 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 and result: 'Creates an unfunded order at the quote's price and delivery time, on the quoted service's rail.' The 'unfunded' qualifier and 'No money moves' explicitly separate it from payment siblings like agoreum_pay_order, and 'with every check placing an order runs' links it to the place-order family.

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?

Gives an explicit follow-up path ('Pay it next with agoreum_pay_order, where the spend limits apply') and a prerequisite ('Confirm the provider, price and delivery with the user first'). It does not state when to prefer this over agoreum_place_order or agoreum_start_order, so the routing among order-creation siblings is left partly implicit.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: an optional on-chain write signed locally, relayed by Agoreum, no funds moved, and a result flag onchain_delivery. It omits idempotency, required order state, failure modes, and permission requirements for a mutation tool, so it is informative but incomplete.

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, front-loaded with the core action, with the on-chain caveat and result field following in logical order. The parenthetical 'signed here, relayed by Agoreum, no money moves' is dense but earns its place by resolving a key safety question.

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 state-mutating, three-parameter tool with no annotations and no output schema, the description covers the action and the conditional side effect but leaves out order-state prerequisites, idempotency behavior, and error cases. Mentioning the onchain_delivery result field partly offsets the missing output schema, but not fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters, so the description must compensate. It labels note as optional and output as structured, and implies order_id, but never says what note is shown to whom or what the structured output is for (e.g., proof-of-delivery payload), leaving the nested object unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('mark an order delivered') plus the actor ('Provider side'), which tells an agent exactly what the call does. It does not, however, distinguish itself from the sibling agoreum_record_delivery, leaving an agent to guess which delivery tool to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'Provider side' and the conditional on-chain clause, giving some sense of who calls this and when. There is no explicit guidance about when to prefer this over agoreum_record_delivery or how it relates to agoreum_settle_order, and no stated preconditions on order state.

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

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

With no annotations supplied, the description carries the full burden, and it does disclose a meaningful behavioral fact: the caller must be a participant in the order (buyer or provider). It says nothing about what happens when the ID is unknown or the caller is not a party, nor about what data comes back, leaving the mutation/safety profile to be inferred from the word "Read".

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?

One short, front-loaded sentence with no filler; the verb, resource, cardinality, and access scope all land immediately. Nothing in it could be cut without losing 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?

For a one-parameter read tool this is close to adequate: the operation and access scope are clear. But with no output schema and no annotations, an agent gets no signal about the response shape or about not-found versus unauthorized outcomes, which are the main failure modes for an ID lookup.

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?

There is a single parameter, order_id, and the description adds nothing about it — not where to obtain it (from a list_orders result, a quote acceptance, etc.) nor that it must be the order's UUID. The schema's format and pattern do enforce a UUID shape, so the gap is partly covered by structured data.

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?

"Read one of your orders" states a specific verb and resource, and the added "as buyer or provider" clarifies the viewer's role, which distinguishes it from agoreum_place_order or agoreum_deliver_order. It does not explicitly contrast itself with agoreum_list_orders, so the read-one-vs-list distinction is only implied.

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 word "one" implies fetching a single known order rather than enumerating, which hints at when to prefer this over agoreum_list_orders. However, there is no explicit when-to-use statement, no named alternative, and no prerequisites such as needing the order ID from a prior call.

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

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

No annotations exist, so the description carries the whole behavioral burden. It does disclose ordering, the exact returned fields, that max_budget already includes the fee, and a genuinely valuable security constraint about untrusted buyer-authored content. It says nothing about pagination behavior for the 3 params or any access requirements, so meaningful gaps remain for an unannotated 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 front-loaded sentences with no filler: purpose and payload first, then the safety caveat. The first sentence is a dense comma list that takes a second read, but nothing is wasted.

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 no output schema, the field enumeration usefully substitutes for one, and the injection warning covers a real risk. The gap is the input side: three optional parameters with no meaning given anywhere, so an agent cannot confidently use tag filtering or paging.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain tag, limit, and offset. It never mentions filtering by tag (only 'tags' as a returned field) and never addresses limit/offset paging, so the parameters are effectively undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Requests still taking quotes'), the sort order ('newest first'), and enumerates the returned fields (title, brief, max_budget with fee included, delivery time, tags). An agent can distinguish this from agoreum_list_orders or agoreum_list_request_quotes (quotes attached to one request) without opening any 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?

Explicitly routes the agent to the follow-up action ('Quote with agoreum_quote_request'), which clarifies what this list is for. It does not state when to prefer this over sibling listings or any exclusions, so it stops short of full when/when-not 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?

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It conveys one behavioral fact — the default role is buyer — but says nothing about read-only safety, authentication, pagination, result ordering, or what an empty result looks like. For a listing tool with zero annotation coverage this leaves significant gaps.

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?

A single compact sentence with no filler, and the default behavior is stated up front alongside the alternative. Nothing is repeated from the schema beyond what is needed to give the enum meaning.

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 one-parameter, zero-required, read-style listing tool with no output schema, the description covers the parameter well but omits result shape, volume, and pagination expectations. It is adequate to invoke the tool correctly but thin on what to expect back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter is an undescribed enum, so the description is the only source of meaning — and it does define both enum values and the default. However, it adds no further detail such as what happens with an invalid value or whether omitting role is equivalent to passing 'buyer'.

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 identifies the resource (orders) and the two scopes it returns — orders placed as a buyer versus orders received as a provider — which is more precise than the bare title 'List your orders'. It does not explicitly contrast itself with the sibling agoreum_get_order (single order) or agoreum_list_open_requests, so sibling differentiation is only partial.

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 tells the agent which role value yields which result set and that buyer is the default, which implies usage for the two cases. It gives no explicit when-to-use versus when-not guidance, and never mentions that agoreum_get_order is the tool for fetching a single specific order.

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

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

With no annotations supplied, the description carries the full burden and does add real behavioral context: a three-tier sort order (live first, then provider's paid/settled evidence, then lower total) and an access-scoping rule that silently narrows results on requests owned by others. It also explicitly flags provider-authored content as untrusted data, which is a meaningful safety disclosure. It stops short of covering pagination, result limits, or the shape of a returned quote.

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?

Sort order is front-loaded, followed by the visibility rule, then the trust warning – a sensible priority order for an agent. The provider-authorship point is stated twice in slightly different forms ('Quote messages are written by providers' followed by 'Titles, summaries and descriptions are written by providers, not by Agoreum'), which is mild redundancy rather than wasted space.

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 no annotations and no output schema, the description covers the things an agent could not otherwise know: ordering, cross-organization visibility, and that returned text is provider-authored and untrusted. What remains missing is return-shape and volume information (pagination, whether quotes include prices, timelines, or attachments), which matters since no output schema exists to fill that gap.

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?

There is one required parameter with 0% schema description coverage, so the description must compensate. It does implicitly convey that the identifier refers to a request that may be owned by you or by someone else, which is useful context the raw UUID schema cannot give. However, it adds no naming, format, or error-behavior detail for request_id, so compensation is only partial.

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 resource and scope: 'Every quote on a request you posted', which is distinguishable from sibling tools that post requests (agoreum_post_request), submit quotes (agoreum_quote_request) or accept quotes (agoreum_accept_quote). It never names those siblings explicitly, but the resource is unambiguous. A reader can tell this is a read/list operation over quote records rather than an action on them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the visibility rule ('On someone else's request, only your own organization's quote') hints at two calling contexts but never says when to call this versus, say, agoreum_get_order or agoreum_accept_quote. There are no explicit exclusions or prerequisites. An agent can infer the context but is not routed deliberately.

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

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

With no annotations, the description carries the full burden and delivers: keys stay local, gas is paid in ETH, funds are escrowed rather than paid out until release, retries are idempotent against double payment, and encoding mismatches are refused. The main omission is what happens on failure or what the call returns, which matters for a money-moving tool with no output schema.

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?

Front-loaded with the action, then rails, then preconditions, then the preview pointer. It is dense and long but every clause conveys a distinct behavioral fact; little could be cut without losing safety-relevant 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?

For a three-parameter mutation tool with no annotations and no output schema, the definition covers signing paths, gas, escrow custody, idempotency, balance and amount validation, and sequencing relative to the preview tool. Only the return payload is undescribed, which is a minor gap given the rest of the 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 0%, so the description must compensate, and it does: order_id drives the payment-instruction rebuild, and expected_amount_usdc and expected_chain_id are explained as optional assertions checked before signing. It stops short of stating the expected format of expected_amount_usdc beyond the schema pattern, but the semantic guardrail role of each parameter is clear.

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?

Names a specific verb and resource (pay an order) and immediately distinguishes the two rails it can take: x402 signing versus direct escrow with approve plus createEscrow. An agent knows exactly what operation is performed and can separate it from sibling tools such as agoreum_preview_payment or agoreum_settle_order.

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 tells the agent to call agoreum_preview_payment first, defines preconditions for use (order must still be awaiting payment, no escrow may already exist), and states refusal conditions for chain/amount mismatches and encoding differences. The when-to-use and when-it-will-refuse guidance is unusually complete.

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

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

With no annotations provided, the description carries the full burden and discloses the most important and non-obvious trait: 'No money moves; the price is frozen' – preventing the agent from assuming this is a charging operation. It also surfaces a concrete validation constraint (x402 minimum 0.50 USDC). It omits order expiry, idempotency, and what the call returns, which are meaningful gaps for a state-creating mutation.

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 short sentences, front-loaded with the action and the money semantics, then the sequencing and the constraint. No filler and nothing repeated from the schema.

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 workflow and payment model are well covered, which is the hardest part for a no-annotation, no-output-schema tool. However, with three undocumented parameters and no described return value, an agent still cannot confidently construct the call or know what it receives back.

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 0% and the description adds no meaning for any of the three parameters – service_id, quantity, and requirements go entirely unexplained in both places. The agent knows the minimum order total but not that quantity multiplies a unit price or what 'requirements' should contain. The description should compensate for the coverage gap and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Place an order for a service') and immediately separates itself from the payment step by naming agoreum_pay_order as the follow-up. An agent can distinguish this from agoreum_pay_order, agoreum_start_order, and agoreum_preview_payment without opening any 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 sentence 'Pay it next with agoreum_pay_order' gives the agent the correct workflow sequence and the sibling to call afterwards, which is exactly the guidance needed here. It stops short of stating exclusions or prerequisites (e.g. must the service already be selected via agoreum_search_services, must the wallet be funded).

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

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

With no annotations, the description carries the full burden. "Moves no money" is a genuinely useful disclosure that this is not a payment step, and "fee included" clarifies the budget ceiling. It omits auth requirements, whether a posted request can be cancelled or amended, and whether anything is returned (e.g. a request id the agent needs for later calls).

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 short sentences, no filler. The budget constraint is front-loaded and the workflow routing follows immediately, so the agent gets the essentials first.

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 six-parameter creation tool with no annotations and no output schema, the description covers purpose, money-safety, and next steps adequately. It leaves the two timing parameters and any post-creation identifier or cancellation behavior undocumented, which is a meaningful gap for an agent that must construct a valid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across six parameters, so the description must compensate. It does add real meaning for max_budget (USDC, fee inclusive) and loosely for title/brief via "describe work you need", but delivery_time_hours and quotes_close_in_hours — both with non-obvious semantics and tight ranges — are completely unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: posting a work request that providers quote on. The mention of agoreum_list_request_quotes and agoreum_accept_quote as downstream steps separates it cleanly from agoreum_quote_request (the provider side) and agoreum_place_order (the direct-buy path).

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 sketches the full workflow: post here, read quotes with agoreum_list_request_quotes, accept with agoreum_accept_quote. It tells the agent what to do next but never states the when-not case, e.g. that agoreum_place_order should be used when the agent already knows the service and doesn't want to solicit bids.

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

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

With no annotations, the description carries the safety burden and does so with 'without signing anything' plus a full list of returned values, making clear this is a non-mutating inspection. It does not state auth/prerequisite requirements (e.g., whether a wallet connection is needed to read the USDC balance) or whether the spend-limit figure is advisory versus reserved.

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, front-loaded with the key non-obvious fact ('without signing anything') before the field list. The field enumeration is long but each item is decision-relevant for confirming a payment; only the 'today's spend limit' clause edges toward surplus 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?

There is no output schema and no annotations, so the description correctly compensates by enumerating the return payload and declaring the no-signing behavior. Missing pieces are prerequisites/error behavior for an unknown order_id, but nothing an agent needs to invoke it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning, and it never mentions order_id at all — no statement of whether the order must be in a payable state or what happens for an invalid/unknown id. The param is a single self-explanatory uuid, and the output enumeration implies the input is an order reference, so the gap is real but limited.

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 ('Shows exactly what agoreum_pay_order would authorize') and immediately names the sibling it mirrors, so an agent can distinguish preview from the actual payment without opening either schema. The enumerated payload (amount, network/chain id, escrow, provider, release/reclaim times, balance, spend limit) reinforces exactly what is being previewed.

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?

'Use it to confirm the network and recipient before paying' gives a clear trigger condition and implicitly routes the agent to agoreum_pay_order after confirmation. There is no explicit when-not guidance (e.g., don't call for already-paid or cancelled orders), which keeps it short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose meaningful economics: the price is USDC net of the platform fee, the buyer pays a grossed-up amount that must fit their budget, and the provider receives the full price. It also states the one-live-quote-per-agent-per-request rule. It does not say what happens when the grossed-up price exceeds the buyer's budget, whether a quote can be withdrawn or revised, or what permissions are required.

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 tight sentences, front-loaded with the actor and action, followed by the pricing mechanic and the uniqueness rule. Every sentence conveys a distinct fact with no redundant restatement of the tool name.

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 five-parameter mutation tool with no annotations and no output schema, the description covers the pricing model well but is incomplete. It leaves open what a successful quote returns (quote identifier, visibility to the buyer), what the optional message field is for, and the failure mode when the fee-inclusive price exceeds the buyer's budget.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across five parameters, so the description must compensate. It adds real meaning for 'price' (USDC denomination, exclusive of the platform fee) and touches 'delivery_time_hours', but 'message' (2000-char optional field), 'request_id', and 'service_id' are left entirely to the schema's type/pattern declarations.

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 ('quote'), an explicit actor ('Provider side'), the target resource ('one of your published services' against an open request), and the two values being supplied (price and delivery time). An agent can distinguish this from sibling tools like agoreum_accept_quote or agoreum_post_request without opening any 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?

Usage is implied by 'Provider side' and by the constraint 'One live quote per agent per request', which usefully tells the agent a second concurrent quote is not allowed. However, no alternatives are named — it never points to agoreum_list_request_quotes to review competing quotes, to agoreum_accept_quote for the buyer's follow-up, or to agoreum_list_open_requests for finding targets.

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

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

With no annotations supplied, the description carries the burden and does well: it discloses that no funds transfer, that signing uses the local wallet, that the relay to the contract is done by Agoreum, and that the call is effectively idempotent (nothing is signed if already recorded). It does not cover what happens on deadline expiry or what the call returns, but the core mutation profile is clear.

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 short sentences, front-loaded with the actor and operation, followed by the financial non-effect, the timing constraint, and the sibling overlap. No filler; the only slight cost is that the final sentence about deliver_order requires the reader to infer its implication.

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 one-parameter, no-output-schema mutation tool with no annotations, the description supplies the essential context: safety (no money moves), precondition (before deadline), idempotency, and the overlapping sibling. Only failure/success reporting is unaddressed, which is a minor gap at this complexity level.

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 single order_id parameter has 0% schema description coverage, and the description never mentions it — the reader must infer that the order is identified by order_id from the schema's required field and UUID pattern. Baseline 3 is appropriate since the schema still constrains the type and format, but the description adds no meaning 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?

Names the actor (provider), the action (sign the delivery statement with the local wallet) and the mechanism (Agoreum relays it to the contract). It also separates itself from the sibling agoreum_deliver_order by framing this as the explicit provider-side primative, so an agent can tell the two apart without opening either 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?

Gives real usage conditions: it must happen before the delivery deadline, it is a no-op when delivery is already recorded, and agoreum_deliver_order already performs this when a wallet is configured. The last sentence stops just short of stating the decision rule explicitly (e.g. 'prefer deliver_order unless you need to sign outside that flow'), which keeps it from a 5.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the default ranking algorithm, the 90-day escrow-settlement window behind 'evidence', the meaning of an x402 settlement rail (payable with one signature, no gas), and a prompt-injection warning about provider-authored text. It stops short of stating pagination behavior, result count limits, or that this is a non-mutating read, leaving some gaps for a no-annotation 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 dense sentences, front-loaded with the action and its default behavior, then the payment-capability note, then the security caveat. Each sentence earns its place, though the trust warning could be tightened and the definition mixes result-field semantics with parameter guidance.

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?

This is a zero-annotation, zero-coverage, no-output-schema tool, so the description needs to do more than it does. It ably covers ranking and the trust/payment model but omits the shape of results beyond the `evidence` field, result caps, and how the query, tag, and price filters actually behave.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all five parameters, but it only clarifies `sort` — its default value and the meaning of the `evidence` option. The parameters `q`, `tags`, `limit`, and `max_price` receive no explanation of matching semantics, format, or effect anywhere.

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 ('Search published services'), immediately distinguishing it from the order/request lifecycle siblings. It goes on to define the default ranking behavior, but never explicitly contrasts itself with the adjacent discovery tool agoreum_list_open_requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the entry point for finding providers to buy from, and the sort explanation hints at 'find trustworthy sellers' vs 'find cheap/new' workflows. There is no explicit statement of when to call this versus agoreum_list_open_requests or agoreum_quote_request, and no prerequisites or exclusions are given.

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

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

With no annotations, the description does the heavy lifting: it discloses that the dispute reason is written on chain publicly and permanently, that the wallet pays gas in ETH, that the call is rebuilt from the escrow id and rejected on mismatch, and that release/refund settle conditionally. It omits the reversibility of a completed release or refund and any error/return shape, so the mutation profile is strong but not fully closed.

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 text is dense but front-loaded: action semantics come first, then gating, then the deterministic calldata check and gas note. Every sentence carries information, though 'the call is rebuilt from the escrow id and refused if anything differs' is compressed enough to be slightly cryptic.

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, unannotated, output-schemaless mutation tool this is above average, covering risk, cost and preconditions. Gaps remain on reason requirements, on what a successful call returns, and on whether completed settlements can be undone — meaningful omissions given the entire specification burden falls on 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?

Schema description coverage is 0%, so the description must compensate, and it does well for the action enum by defining all three values and their preconditions. It does not clarify whether 'reason' is mandatory only for dispute, is ignored for release/refund, or why it must be 10–1000 characters, nor does it add anything about order_id beyond the schema's uuid constraints.

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 names the resource (an order's escrow in the local wallet) and spells out three distinct verbs — release, refund, dispute — with what each does to the funds. This distinguishes it cleanly from siblings such as agoreum_pay_order, agoreum_deliver_order and agoreum_get_order without any schema inspection.

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?

Each action is paired with the condition that enables it: release when the buyer accepts work (or anyone once auto-release is due), refund on provider decline or buyer after an undelivered deadline, dispute to freeze for the arbiter. It also says the system reports whether an action is open to you and why not, but it never contrasts against sibling tools that move money, so the routing guidance stops short of explicit alternatives.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It conveys only the state transition (accept, then begin work) and omits whether funds are escrowed or released, whether acceptance is reversible, what permissions are required, and what happens if the order is not yet funded — all material for a money-touching mutation.

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?

A single front-loaded sentence with no filler and the role qualifier placed first where it matters. It is efficiently written, though the terseness is part of what leaves the behavioral questions unanswered.

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 no annotations, no output schema, and an undocumented required parameter, a state-changing order-acceptance tool needs more than one clause. The description gives no success semantics, no funding/escrow implications, and no ordering relative to the surrounding lifecycle tools.

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?

There is one required parameter at 0% schema description coverage; the schema only declares it as a UUID. The description says nothing about order_id (where it comes from, whether it must be the order offered to this provider), so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("accept a funded order") plus the actor role ("Provider side") and the immediate consequence ("begin work"), which separates it from buyer-side siblings like agoreum_place_order. It never names the easily-confused siblings agoreum_accept_quote, agoreum_wait_for_funding, or agoreum_deliver_order, so the differentiation stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"funded" hints at a precondition, but the description never states when to call this versus agoreum_wait_for_funding (to get to funded) or agoreum_deliver_order (the next step). There are no exclusions, no prerequisite checks such as being the awarded provider, and no error path for an unfunded order.

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

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

With no annotations, the description carries the full burden, and it does real work: it explains the trust semantics ('a valid signature proves Agoreum made the claim') and that the named transaction, not the signature, is what proves payment. It omits failure modes (missing receipt, key rotation, unverifiable order) and never explicitly confirms the call is side-effect free, but 'fetch' plus local key verification strongly implies read-only.

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 tight sentences with the action and the verification target front-loaded. The closing clause 'the result says which to check' is slightly cryptic but points the reader at the interpretation guidance rather than wasting words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description is the only source of truth about the response – yet it only vaguely says 'the result says which to check' without describing the fields returned (valid/invalid, transaction reference). For a verification tool whose entire value is the response, that is a notable gap, though the input side is adequately covered.

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 0% – the single order_id parameter has format and pattern constraints but no textual description. The description compensates partially by indicating the ID must reference a *completed* order, which is meaningful scoping information not in the schema, but it adds nothing about ID format or lookup behavior.

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 compound action (fetch the signed receipt, verify against Agoreum's published keys) on a specific resource tied to a completed order. This clearly separates it from generic siblings like agoreum_get_order or agoreum_settle_order, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'a completed order's receipt', which signals the order must already be completed before calling. There is no explicit when-to-use guidance, no statement of what to do when verification fails, and no pointer to a sibling for the non-verifying case.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the call blocks and polls, what ends the wait, and that timeout_seconds caps the wait. It does not say what is returned or raised on timeout, whether it short-circuits if already funded, or how often it polls — meaningful gaps for a blocking 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?

One sentence, front-loaded with the verb and resource, with the termination condition and the bounding parameter in the same clause. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and no annotations means the description must cover results and failure modes, and it omits the timeout outcome and already-funded behavior. For a blocking, poll-based tool that is a real gap, though the core semantics are conveyed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains timeout_seconds as an upper bound on waiting but gives no default or behavior at expiry; order_id is only implied as the thing being polled, with format left entirely to the schema. Partial compensation for a two-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — polling an order until its payment is confirmed on-chain — and names the concrete termination condition (status leaves pending_payment). An agent can distinguish it from the one-shot agoreum_get_order, though it never names that sibling explicitly.

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 usage is only implied: the tool is for waiting after an order has been placed and payment submitted. There is no explicit statement of when to prefer this over agoreum_get_order polling, nor when not to use it (e.g., order already funded).

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

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

With no annotations, the description carries the full burden, and it does imply a read-only status query by describing returned state rather than an action. It adds real context by scoping authorizations to 'today (UTC)', but says nothing about auth requirements, currency denomination of the limits, or whether the limits are per-transaction or rolling daily.

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?

A single sentence with no filler; the three returned data points are the whole content and each earns its place. The UTC qualifier is placed tightly next to the thing it scopes.

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 no output schema, the description usefully enumerates the three return fields, which is the most important compensation. However, for a wallet/limits tool an agent still cannot tell limit units or windows, or whether calling it has any side effects, so it is adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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?

Names the specific resource (the paying wallet) and enumerates what it exposes: address, spend limits, and today's authorizations in UTC. That is enough to distinguish it from every sibling, which are all order/payment-flow tools. It loses a point only because it is a noun phrase with no verb, so the agent must infer this is a read/retrieve operation.

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?

There is no when-to-use guidance at all: it never says to call this before agoreum_place_order or agoreum_pay_order to check whether funds or limits allow the transaction, which is the obvious reason the tool exists. No exclusions or alternatives are named.

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