dollarr

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

Goes beyond the annotations by disclosing the concrete effect (funds released from escrow to the seller), the auth requirement (API key), and reinforcing irreversibility. The destructiveHint already flags the mutation, but the description adds meaningful financial and access context on top of it.

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, front-loaded sentences: the action, the consequence, the irreversibility, and the prerequisite. Zero filler and the most decision-relevant facts come 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 destructive, irreversible payment-release tool with no output schema, the description covers the consequence, irreversibility, and auth need. It omits prerequisite state (e.g., order must be delivered) and error behavior, but an agent has enough to invoke it knowingly.

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 never mentions order_id, its format, or where to obtain it. The single parameter is largely self-evident from its name and the UUID pattern in the schema, so the gap is not severe, but the description does nothing to compensate.

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 delivered work) and the concrete effect: releasing escrowed USDC to the seller. It's clear what the tool does, but it never names the sibling alternatives (request_revision, open_dispute) that occupy the same decision point, so differentiation is left to inference.

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?

"Accept the delivered work" implies the triggering condition (work has been delivered), which is useful context. However, it offers no explicit guidance on when NOT to use it or how it compares to request_revision or open_dispute, which are the natural alternatives at this stage.

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?

Goes beyond the annotations by disclosing the side effect (an order is created), the required OAuth scope (buy), and API-key auth. It does not address the non-idempotent hint (e.g. what happens if a bid is awarded twice), which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action before the follow-up and auth requirements. 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 two-param mutation with no output schema, it covers the action, the resulting object, the next step and auth. Nothing about failure modes or the fate of competing bids, but adequately 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?

Schema coverage is 0%, so the description carries the burden, but it says nothing about job_id or bid_id. The names and UUID formats are largely self-explanatory, so this is the minimum-viable baseline rather than a failure.

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?

Specific verb+resource: 'Accept a bid on your job', plus the resulting side effect ('Creates an order'). It routes the agent to the sibling build_payment and is clearly distinct from place_bid/approve_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?

States the context for use (you are the job owner accepting a bid) and the follow-up action (pay with build_payment). No explicit when-not-to-use guidance or comparison against approve_order/start_order, so not 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?

Adds value beyond annotations by disclosing the auth requirement (API key), the intended follow-up action, and the memo format. The readOnlyHint is consistent with a tool that only builds an unsigned transaction without submitting it, so there is no contradiction. It doesn't mention expiry, replay, or error behavior, keeping it at 4.

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, front-loaded with the return value and flow, with zero filler. Every clause carries information the agent needs.

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?

Although there is no output schema, the description fully describes the return (unsigned base64 transaction), the required follow-up steps, and the auth prerequisite. Nothing needed to call it correctly 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 50% (buyer_wallet documented, order_id not), and the description compensates by tying order_id to the order price and the memo dollarr:<orderId>, and clarifying that buyer_wallet signs and pays the fee. This adds genuine meaning over the raw 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 precise verb+resource (builds an unsigned Solana USDC-to-escrow transaction), names the exact return format (base64), and distinguishes itself from the sibling confirm_payment by describing the two-step flow. An agent can tell this apart from confirm_payment 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 clear sequencing: sign with buyer_wallet, send it, then call confirm_payment. It tells the agent where this sits in the workflow. It stops short of explicit when-not-to-use guidance (e.g., don't call once payment is confirmed), so it doesn't reach 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?

Annotations already disclose destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds value beyond them with an auth requirement ('Requires an API key') and a state precondition (unpaid only), though it doesn't state reversibility or downstream effects.

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, zero filler, with the precondition and auth requirement front-loaded after the core action. Nothing is redundant.

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 destructive mutation with annotations already covering safety and no output schema, the description supplies the key missing context: the precondition and the API-key requirement. It could go further on what cancellation implies for the order afterwards, but it is largely 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?

Schema description coverage is 0%, but the single parameter is named order_id with format=uuid and a regex pattern, making its meaning effectively self-evident. The description adds nothing about the parameter, so it does not compensate for the coverage gap, but the gap is minimal for one self-describing param.

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 ('Cancel an order') and adds a scope constraint ('that has not been paid yet'). It is clearly distinguishable from siblings like approve_order, deliver_order, or open_dispute, but it does not name any sibling as the alternative 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?

Gives a usable precondition (order must be unpaid), which implies when the tool applies. However it offers no explicit alternative guidance for paid orders — e.g., whether open_dispute is the right sibling in that case — so the agent must infer the fallback.

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 the safety profile (not read-only, not destructive, not idempotent, closed-world). The description adds genuinely useful context beyond that: the seller is notified as a side effect, and an API key is required. It does not address the non-idempotent behavior declared in annotations, which matters for retries.

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, each earning its place: the action, the side effect, and the auth requirement, with the core action front-loaded. No filler or restatement of the 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 mutating, non-idempotent tool with no output schema and sparse parameter documentation, the description covers the outcome and auth but omits failure behavior, whether a duplicate call is rejected, and what the buyer_wallet parameter must match. Adequate but with clear gaps.

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?

With three required parameters and only 33% schema description coverage, the schema documents just 'signature' as a Solana transaction signature. The description adds no meaning for order_id or buyer_wallet, leaving the linkage between the payment and the order, and whose wallet must be supplied, to inference.

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 gives a specific verb and resource: 'Verify a sent payment on-chain and mark the order paid.' That is far more informative than the title alone and implicitly distinguishes it from build_payment, which only constructs the payment. It stops short of explicitly naming the sibling it complements, so it is clear but not fully differentiated.

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 'a sent payment' implies this is the step that follows sending funds, giving an implied position in the order flow, but no explicit when-to-use, prerequisites, or alternatives are stated. An agent must infer that build_payment/sending must happen first.

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 cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new context: the server sets the price, the order lands in a pending state, and buy scope plus an API key are required. It doesn't warn that repeated calls create duplicate orders, but the idempotentHint annotation already flags that.

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, zero filler, front-loaded with the action and state, then workflow, then prerequisites. Every sentence carries distinct 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 mutation tool with no output schema and only 33% schema description coverage, the description covers workflow and auth well but leaves the parameters and the shape of the created order largely unexplained. It is workable but has clear gaps.

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 only 33% (just 'requirements'), and the description adds nothing about gig_id, promo_code, or the requirements payload format. With a low-coverage schema the description is expected to compensate, and it does not mention a single parameter.

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 ('Create a pending order for a gig') and names the resulting state (pending), which is more than a restatement of the title. It does not, however, differentiate itself from close siblings like start_order or place_bid, which an agent could easily confuse it with.

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 explicit downstream context ('Next: build_payment, sign and send the transaction, then confirm_payment') plus prerequisites ('Needs buy scope. Requires an API key.'), so an agent knows where this sits in the workflow. It never states when NOT to use it or how it differs from start_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?

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds useful operational context: sell scope and API key authentication. It does not explain the consequence of the non-idempotent hint (e.g., what happens on a duplicate delivery) or whether this is reversible.

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 core action and input-mode constraint front-loaded, followed by auth requirements. No filler or repetition.

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

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

With 0% schema coverage, no output schema, and five parameters, the description should explain the required identifiers and the role of mime_type. Instead it covers only the two file-content parameters, so an agent must infer what order_id/file_name are and what the call returns.

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 carries the load for the file inputs and does clarify that file_url and file_base64 are alternatives ('either ... or'). It says nothing about order_id, file_name, or mime_type, leaving three of five parameters uninterpreted beyond their names.

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 ('Deliver the finished work as a file') and constrains the delivery mode to one of two inputs (file_url or file_base64). It clearly occupies the delivery slot in the order lifecycle, but never names the neighboring steps (request_revision, approve_order) it is distinct from.

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 prerequisites ('Needs sell scope. Requires an API key.') which helps the agent confirm it can call the tool at all. However, it never says when to deliver versus request a revision or how delivery interacts with approve_order, so the routing guidance is only implied.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the notion that the response is the 'full details' of the entity, with no notes on auth, error behavior, or missing-gig handling.

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 short sentence with the resource and lookup key front-loaded; every word 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 one-parameter read-only lookup with no output schema, 'full details' adequately signals the return. The absence of an output schema means slightly more could be said about what is returned, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100% and the single parameter is documented in the schema as 'Gig slug (from its URL) or id'. The description's 'by its slug or id' merely restates that, adding no new semantics.

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 with scope ('Full details of one gig') and identifies the lookup key. It does not explicitly distinguish itself from the sibling search_gigs, so it falls just 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?

There is no guidance on when to use this versus search_gigs or get_order, and no stated prerequisites. Usage is only implied by the phrase 'one gig'.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the non-obvious auth requirement ('Requires an API key') and scopes the content to buyer-seller on an order, but says nothing about pagination, ordering, or return shape.

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 with the resource front-loaded and zero filler. It is arguably terse rather than wasteful, which is the right call for a single-parameter read.

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 exists, and while the rich annotations cover safety, the description omits how results are returned or bounded (pagination, ordering) and offers no routing vs send_message. Adequate but thin for a messaging read 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 0%, but the single parameter's type/format/pattern (uuid) is fully declared structurally. The description partially compensates by tying the messages to 'an order,' implying order_id is an order identifier, though it adds no format or origin detail 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 names a specific resource (the buyer-seller message thread on an order), which is clear enough to distinguish it from get_order (order details) and send_message (writing). It lacks an explicit verb like 'retrieve' and never names the sibling it is not, but the resource is 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?

There is no when-to-use guidance and no reference to alternatives such as send_message for the write counterpart. 'Requires an API key' is an auth prerequisite, not usage guidance, so an agent gets no help deciding when to call this.

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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description's only addition is the API-key auth requirement, which is useful but thin; it says nothing about not-found behavior or error modes for an invalid order_id.

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 terse sentences with no filler and the returned data listed up front. The terseness borders on under-specification, 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 and no annotations covering return values, the description should describe what comes back and failure modes. It gestures at returned fields but omits structure, and gives no indication of behavior when the order_id does not exist.

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 only one parameter and schema coverage is 0%, but the schema itself encodes the format and UUID pattern. The description never mentions order_id, so it adds no semantics beyond the identifier's self-evident purpose, leaving the schema to carry the load.

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

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

The description names the resource (a single order) and the data it returns (status, price, payment, delivery details), which implicitly contrasts with the plural list_orders sibling. However, it omits an explicit verb like 'retrieve' and does not directly name or differentiate itself from any of the 20+ siblings that operate on orders such as get_gig or list_orders.

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

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

No guidance on when to use get_order versus alternatives like list_orders or whoami; the only stated condition is 'Requires an API key,' which is a credential prerequisite rather than usage routing. An agent must infer that this is the single-order lookup by name alone.

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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety bar is met. The description adds real value beyond that by disclosing the auth requirement ('Requires an API key') and the role-dependent result scoping, which annotations cannot 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?

Very short and front-loaded, with the core action stated first. The parenthetical seller clause is slightly awkward but earns its place by altering the returned data.

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-only list tool with rich annotations and no output schema, the definition covers purpose, auth, and view scoping adequately. Missing only pagination/ordering and error behavior for an invalid job_id, which are minor gaps here.

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 schema itself gives no meaning to job_id beyond a UUID pattern. The description implies 'a job you posted' but adds no format, ownership, or error semantics for the parameter, so it only partially compensates.

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 clear verb+resource (lists bids on a job) and scopes it by viewer role. An agent can distinguish it from siblings like place_bid and award_bid, though the phrasing 'Bids on a job you posted' is slightly telegraphic rather than a clean declarative sentence.

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?

Adds useful role context: it returns bids on a job you posted, or only your own bid if you are a seller. However, it never states when to use this versus alternatives or prerequisites beyond the API key mention, leaving usage largely implied.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuinely useful behavioral context absent from the annotations: the return shape includes slug and id values consumed by other tools. It does not mention that the call takes no arguments or how large the result set is, so it adds some value but not rich context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single terse clause with zero filler, and the resource name appears first. It is grammatically a noun phrase rather than a full sentence, which slightly weakens the front-loading of intent, but every word 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 parameterless read tool with no output schema, the description supplies the one piece of missing context an agent needs: what the returned identifiers are for. Annotations carry the safety profile, so nothing critical is absent, though a note on the full result shape or static nature of the list would round it out.

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 takes zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to disambiguate, and it introduces no misleading parameter language. It could have stated that no arguments are needed, but the empty schema already conveys this.

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 a specific resource (gig and job categories) and even characterizes the payload ('the slug and id'), so an agent knows exactly what this returns. It does not explicitly distinguish itself from siblings like list_open_jobs or get_gig, but the resource itself is unambiguous. A fragment rather than a verb-led statement, yet the purpose reads clearly.

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 explicit when-to-use or when-not-to-use guidance. The phrase 'the slug and id other tools accept' implies this is a lookup to run before calling tools that take category references, which is useful implied context but not a stated instruction or alternative. Usage must be inferred.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful context the annotations cannot: results are ordered newest first and each entry carries budget range and bid count. It omits pagination/boundary behavior (limit cap 50) but is solid for this tool type.

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 zero filler. Ordering and returned fields are front-loaded, and the sibling reference closes the sentence efficiently.

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

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

No output schema exists, and the description partially covers returns (budget range, bid count), which is appropriate. However it leaves filtering semantics (budget filters, category filter, limit default) entirely to the schema, and half of the parameters are undocumented anywhere.

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 only 50%: limit and category_id are described, while min_budget_usd and max_budget_usd have no schema description. The description does not compensate — it mentions 'budget range' only as returned data, never as a filter, so the agent gets no guidance on how to use the budget parameters.

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 (list open job briefs), names the poster (buyers), and discloses ordering and returned fields (budget range, bid count). An agent can distinguish it from list_bids, list_orders, and search_gigs 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 reference to place_bid implies the workflow (browse then bid) but never states when to call this versus list_bids, list_categories, or search_gigs. Usage is inferable rather than explicit, with no exclusions or prerequisites.

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 destructiveHint=false, so the safety profile is covered. The description adds two things the annotations do not: the result ordering ('newest first') and an authentication requirement ('Requires an API key'). It omits pagination/default-limit behavior, which keeps it from a 5.

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 resource and scope, no filler or repetition of the title. Every clause carries 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?

With three undocumented parameters, no output schema, and no explanation of what a returned order looks like or how 'limit' paginates, the description leaves significant gaps for a filtering tool. Only the auth and sorting facts are supplied.

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 carries the full burden, yet it only partially explains the 'role' parameter ('buyer, seller or both') and says nothing about 'limit' or the eight-value 'status' filter. Two of three parameters remain semantically opaque.

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+resource ('list ... orders') with the scope qualifier 'as buyer, seller or both' and an ordering guarantee ('newest first'). This is clearly separable from the singular get_order sibling, though it never names an alternative explicitly, which keeps it just 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?

Usage is only implied: an agent can infer this is the bulk-retrieval counterpart to get_order, and 'as buyer, seller or both' hints at the role parameter's purpose. There is no explicit when-to-use rule, no when-not-to-use, and no mention of siblings, so it stays at minimum-viable.

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 only declare the write/non-idempotent/non-destructive profile, so the description meaningfully adds two behavioral facts: funds remain held in escrow during the dispute and an API key is required. It does not say whether the dispute can be withdrawn, who resolves it, or how long it takes, which keeps it short of a 5.

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, each carrying a distinct piece of information (action, funds behavior, auth), with the core action front-loaded. No filler or 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 two-parameter, no-output-schema tool the description covers purpose, escrow behavior, and auth, which is reasonable. However, with zero schema description coverage it omits any explanation of the reason field (whether it is required, what content is expected) and gives no sense of what the call returns or what happens next.

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 carries the burden of explaining parameters, yet it names neither order_id nor reason. It conveys nothing about the optional free-text reason or the UUID format of the order identifier, leaving both parameters documented only by type hints 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?

The first sentence states a specific verb ('escalate') and resource ('an order to dispute review'), making the operation unambiguous and clearly distinct from sibling actions like cancel_order or request_revision. It stops short of explicitly naming or contrasting with an alternative, so it is clear but not sibling-differentiating at the top level.

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 guidance on when a dispute is the appropriate action versus alternatives such as request_revision, cancel_order, or approve_order. The verb implies a problem-resolution scenario, but the agent gets no exclusions, prerequisites, or selection criteria.

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 this is a non-idempotent, non-destructive write in a closed world. The description adds real behavioral value on top by naming the required authorization surface: sell scope, a seller account with a wallet, and an API key. It stops short of describing failure modes such as duplicate-bid rejection.

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 then the preconditions. No filler, though the repetition of 'Requires an API key' after listing other auth needs is slightly redundant.

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 and no annotations covering errors, the description should say what a successful bid yields and what happens on failure (job closed, duplicate bid, insufficient wallet). Prerequisites are covered but the mutation's contract is not.

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 explains none of the four required parameters. An agent gets no sense of what pitch should contain, whether price_usd must beat an existing bid, or how delivery_days is interpreted, despite the schema carrying only structural 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?

States a specific verb+resource ('Bid on an open job'), which an agent can distinguish from siblings like list_bids and award_bid. It doesn't explicitly name a sibling alternative, but the action is 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 supplies prerequisites (sell scope, seller account with wallet, API key) rather than when-to-use-vs-alternatives guidance. It never says what to do if the job is already closed, has been awarded, or how this relates to list_open_jobs/get_gig.

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 this a non-read-only, non-idempotent write, so the safety bar is low. The description adds auth/scope requirements ('buy scope', 'API key') that annotations do not carry, which is genuinely useful context. It stops short of describing side effects such as duplicate-post behavior or what the caller gets back.

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 its purpose, then prerequisites. No filler; every clause carries information, though the final two clauses are terse to the point of being 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 6-parameter mutation tool with no output schema and 17% schema coverage, the description covers purpose and auth but not validation rules, the category/deadline parameters, or what a successful post yields. Adequate to call it, incomplete for calling 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?

Schema description coverage is only 17% (only deadline carries 'ISO 8601'), so the description must compensate. It hints at the budget range (budget_min_usd/budget_max_usd) and the 'brief' (title/description), but leaves deadline, category_id, and the min/max relationship and length limits unexplained 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 ('Post a job brief with a budget range') and names the intended audience/effect ('so sellers and their agents can bid'). It is clearly distinct from bid-side siblings like place_bid or read-side ones like list_open_jobs, though it never names a 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?

Usage is implied by the effect statement (post so sellers can bid), and it adds two prerequisites ('Needs the buy scope. Requires an API key.'). However, it gives no when-to-use-vs-alternative guidance and no exclusions, so an agent still has to infer the surrounding workflow.

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=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered. The description adds one genuinely useful behavioral fact, the API-key requirement, but says nothing about what the revision does to the order (deadline, escrow, state transition) or whether repeated calls are rejected.

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, no padding, with the core action front-loaded. Every clause carries 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 state-changing tool with no output schema and no annotation detail about side effects, the description is thin: it omits what happens to the order after a revision request and any conditions that would cause failure. It is minimally usable but leaves real gaps.

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% for both required parameters, so the description carries the burden — yet it only obliquely gestures at them ('feedback', 'delivered work'). It adds no meaning about the feedback length limit, format, or how order_id should be supplied beyond the schema's UUID pattern.

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 concrete verb+resource ('Send delivered work back to the seller with feedback'), which is specific enough to separate it from approve_order or open_dispute. However, it never names or contrasts with those siblings, leaving the agent to infer the routing itself.

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 by the phrase 'delivered work' — the agent can infer this applies after a delivery when the work is unsatisfactory. There is no explicit when-to-use vs. approve_order/open_dispute, and no statement of prerequisites beyond the API key.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the payload contract (title, USD price paid in USDC, delivery time, URL), which is genuinely useful given there is no output schema, though it says nothing about pagination or empty-result behavior.

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: the first front-loads what the tool returns, the second handles routing. No filler, no restatement of the 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?

With five optional params, no output schema and no required arguments, the description covers the essentials (result fields, sibling routing). Minor gaps remain: sort ordering semantics and whether results are paginated or capped by 'limit'.

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 60%, with sort and max_price_usd carrying no inline description. The description only implies a price constraint via 'fixed-price' and USD; it adds no syntax or constraints for sort ordering or price bounds, so the schema remains the primary source.

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 ('Search') plus resource and scope ('fixed-price gigs (services) on dollarr'), which cleanly separates it from list_open_jobs (jobs) and get_gig (single-item detail) without the agent needing to open a 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: 'Use get_gig for full details and create_order to buy.' This names two alternatives with the condition that selects them. It does not clarify search-vs-list_open_jobs or list_categories, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=false, so the mutation profile is covered. The description adds one genuinely useful non-annotation fact — 'Requires an API key' — but says nothing about who receives the message, notification behavior, or whether a message can be edited/retracted.

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, front-loaded sentences with no filler, so the purpose lands immediately. The brevity is close to under-specification rather than padding, but nothing wasteful is present.

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 and no parameter documentation, the description should carry more: it never states what a successful send returns, whether the recipient is notified, or what errors occur for an invalid order. For a mutation tool with an undifferentiated 'other party' concept, that is a real 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?

Schema description coverage is 0%, and the description adds no meaning beyond the parameter names: it does not say what 'body' supports (plain text vs markdown, the 4000-char cap, length limits) or what 'order_id' must refer to (an order the caller participates in). The self-explanatory names alone keep this above a 1.

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 gives a specific verb and resource ('Message the other party on an order'), so the agent knows this sends a message tied to a single order. It does not explicitly name the counterpart sibling get_messages, so the read-vs-write split must be inferred from the tool names.

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

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

No when-to-use guidance, no prerequisites tied to order state, and no mention of alternatives such as get_messages for reading the thread or open_dispute for escalation. The only implied usage is that an order must exist.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds two things annotations do not carry: the sell-scope permission requirement and the API-key requirement. It still omits what happens on an unpaid order or a repeat call, so the added context is useful 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?

Three short, front-loaded sentences with no filler: action first, then authorization requirements. Nothing is redundant with the title. It is efficient, though the auth notes could be merged into one clause without loss.

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 non-idempotent mutation with no output schema, the description covers the precondition (paid order) and the auth requirements, which is the minimum an agent needs to avoid a failed call. It does not describe the resulting state, side effects on the buyer/seller, or failure behavior, leaving meaningful gaps given the tool's mutating nature.

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 there is one required parameter, so the description carries the full burden. It only indirectly implies the order_id must reference a paid order; it never identifies the argument, its UUID format, or where the value comes from. This is a clear gap for a 0%-coverage schema.

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

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

States a specific verb + resource + state transition: 'Mark a paid order as in progress.' That distinguishes it from nearby siblings like confirm_payment, deliver_order, and cancel_order, which move an order to different states. It stops short of naming an alternative explicitly, so it lands at 4 rather than 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?

It gives a precondition ('a paid order') and an authorization gate ('Needs sell scope'), which is real usage context. However, it never says when to choose this over siblings such as confirm_payment or approve_order, nor what to do when the order is not yet paid. Usage is implied rather than spelled out.

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, non-destructive and closed-world, so the safety profile is covered. The description adds context annotations cannot express: the authentication requirement ('Requires an API key') and the shape of what comes back (account, scopes, wallet).

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 statement with the return content front-loaded and the auth prerequisite last. It is grammatically a fragment (no verb such as 'returns'), which costs a point, but there is no wasted text.

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 tool with full annotation coverage and no output schema, the description covers what matters: identity, scopes, wallet, and the API-key requirement. Minor omissions (e.g. behavior on an invalid/expired key) are not decisive here.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level confusion is possible.

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 specific resource returned — the account tied to the API key, plus its scopes and wallet — which is far more informative than the bare name 'whoami'. It is a noun fragment with no explicit verb, but the returned artifact is unambiguous and none of the siblings (order/bid/payment/gig operations) overlap with it.

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 explicit when-to-use statement or named alternative, but 'Requires an API key' gives a precondition that implies the tool is for verifying the current credential's identity and permissions. Usage is inferable rather than stated.

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