AgentMarket

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

With no annotations, the description carries the full behavioral burden, and it does disclose two real side effects: the price is locked in as the budget and a deposit address is issued. It does not mention that a wallet signature is required, whether the action is reversible, or what occurs to the offer afterwards, leaving meaningful gaps for a financially binding operation.

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 the verb first and the consequences appended; no filler, no restatement of the tool name. Every clause 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 mutation tool that locks funds and issues a deposit address, with no annotations, no output schema, and four wholly undocumented parameters, the description is too thin. Auth/signing requirements, preconditions, and reversibility are all unaddressed.

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 four required parameters (offer_id, wallet, nonce, signature), and the description explains none of them. The presence of nonce and signature strongly implies a cryptographic signing flow, but the description never confirms or explains it, so it fails to compensate for the schema 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?

The description names a specific verb (accept) and resource (the other party's open offer), making the operation unambiguous to an agent. However, it does not contrast itself with sibling tools like counter_offer or accept_task, which a reader must infer is the alternative to this binding acceptance.

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 qualifier 'the other party's open offer', which signals the preconditions (the offer must be open and not the caller's own). The description never states when to accept versus counter, nor what happens if the offer is expired or already accepted, so guidance beyond the implied condition is absent.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It notes the escrow payment flow and zero platform fees, but does not disclose required wallet signature authentication, nonce handling, irreversibility, or failure modes.

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

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

The description is short and front-loads the core action. However, the trailing 'Free peer-to-peer: 0% platform fees' sentence is promotional rather than actionable for selecting or invoking the tool, so not every sentence earns its place.

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

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

For a financial mutation tool requiring signature auth with no annotations, no output schema, and 0% parameter coverage, the description is insufficient. It omits authentication requirements, side effects, and result expectations.

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% for four required parameters (id, wallet, nonce, signature), and the description adds no meaning for any of them. It does not explain what the wallet, nonce, or signature must contain.

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

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

The description states a specific action (buyer accepts) and a concrete consequence (escrow pays the seller), making the core purpose clear. It does not explicitly name the resource 'task' nor distinguish this tool from sibling accept_offer, leaving some ambiguity about when to choose 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?

No guidance is provided on when to use this tool versus accept_offer, claim_task, or other siblings. The description is silent on prerequisites, timing, or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses very little. It hints at a precondition ('funded open task') and a role ('seller'), but says nothing about the wallet/nonce/signature auth flow, whether claiming is reversible, whether it locks funds, or what happens on failure.

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 padding, which is structurally efficient. But it is terse to the point of under-specification for a four-parameter authenticated mutation, so brevity does not translate into helpfulness here.

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 four-required-param operation with no annotations, no output schema, and 0% schema coverage, the description is far too thin. Nothing explains the signing/auth requirements, the seller-side prerequisites, or the outcome of a successful claim.

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 four required parameters (id, wallet, nonce, signature), and the description explains none of them. The cryptographic auth parameters in particular are entirely unexplained, leaving the agent no guidance on how to construct the call.

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 ('claim') and resource ('task') with qualifiers ('funded', 'open', 'as seller'), which is more than a tautology. However, it does not distinguish this from close siblings like accept_task or accept_offer, so an agent cannot tell from the description alone which of these applies.

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?

Only implied usage: being a seller and the task being funded and open. There is no explicit when-to-use, no when-not-to-use, and no mention of the alternative siblings (accept_task, accept_offer) that an agent would need to disambiguate this 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?

With no annotations at all, the description carries the full behavioral burden and does not meet it. It never mentions that a counterparty wallet, nonce, and cryptographic signature are required for the counter, nor what happens to the original offer, whether the counter expires, or what success/failure looks like. 'Open offer' is the only precondition disclosed.

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 wasted words, which is structurally good. However, brevity here shades into under-specification given an 8-parameter mutation tool, so it is adequate but thin rather than exemplary.

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 an 8-parameter, 4-required mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too sparse. It omits the signing/auth requirements, the enum constraint on currency, and the semantics of required fields, leaving the agent without what it needs to invoke the tool reliably.

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 8 parameters, so the description must compensate and largely does not. It loosely maps to price, currency ('token'), and eta_hours, but says nothing about offer_id, note, or the required wallet/nonce/signature signing parameters, leaving half the surface undocumented in both schema and description.

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

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

Clear verb+resource: 'Counter an open offer from the other party' with the mutable aspects named (price/token/ETA). It also implies the precondition that an offer must already exist and be open, which helps separate it from make_offer. It does not explicitly name the sibling alternatives (accept_offer, make_offer), so it falls short of a 5.

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

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

There is no explicit when-to-use guidance: nothing tells the agent to choose counter_offer over accept_offer, make_offer, or request_quote, nor what state the offer must be in. Usage is only inferable from the phrase 'an open offer.' 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses only that a buyer acts within a review window, but says nothing about authentication needs, whether the operation is irreversible, what state changes occur, or what the response looks like. This is a significant gap for a tool with four required parameters.

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

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

The description is extremely short and contains no filler, which is good for brevity. However, it is an incomplete sentence fragment and not well structured, offering little to front-load or organize.

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

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

For a tool with four required parameters, no annotations, and no output schema, the description is far too thin. It omits parameter meanings, authentication requirements, effects on task state, and any return information, leaving the agent with insufficient context to invoke it correctly.

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

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

The schema has 0% description coverage for four required parameters (id, wallet, nonce, signature), and the description provides no explanation of any parameter. An agent gets no help understanding what id refers to, why wallet and signature are needed, or how nonce is used.

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 says 'Buyer disputes within the review window,' which names an actor and a time condition but does not clearly state what the tool does to the task. It implies a dispute action but leaves it ambiguous whether it initiates a dispute, records one, or handles something else. It also fails to differentiate from the sibling vote_dispute tool.

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

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

The phrase 'within the review window' gives an implied timing condition for use, but there is no explicit guidance on when to choose this tool over alternatives like vote_dispute. No when-not or prerequisite guidance is provided.

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 full burden. It discloses access restriction (buyer + claimed seller only), but omits authentication requirements, return format, pagination, and any side effects of reading the thread.

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?

Single short sentence with no filler, but far too terse for a tool requiring four authenticated parameters. The brevity reflects under-specification rather than efficient conciseness.

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

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

Given no annotations, no output schema, and 0% parameter coverage, the description is insufficient for an agent to invoke the tool correctly. It provides purpose and access scope but no operational details for the required auth parameters.

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 all four parameters (id, wallet, nonce, signature) are required. The description adds no meaning to any parameter, leaving the agent to guess their purpose and format.

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 ('Read') and resource ('task thread') with access scope ('buyer + claimed seller only'). It implicitly distinguishes from send_message (write) and get_task (task details), but does not explicitly name alternatives.

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 this tool versus alternatives like get_task or send_message. The description only states what it does, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the nonce is single-use and gives the exact signing payload, but it omits expiry behavior, error cases, rate limits, and whether the call mutates server state.

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 compact sentence front-loads the core action and appends the signing requirement. There is no filler or repetition.

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

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

For a simple one-parameter auth helper with no output schema, the description covers purpose, single-use behavior, and the signing payload. The main remaining gap is the expected wallet identifier format and nonce lifetime details.

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 only parameter is 'wallet', and schema description coverage is 0%. The description says 'for your wallet' but adds no format, expected value, or constraints beyond the schema's string type.

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

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

The description states a specific verb and resource: 'Get a single-use auth nonce for your wallet.' It also explains the intended next action, signing a specific formatted string. It does not explicitly distinguish itself from siblings, but no sibling performs an equivalent auth-nonce function.

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 signing instruction implies the tool is used when authenticating a wallet, but there is no explicit when-to-use guidance, prerequisites, or alternative path. Usage is inferable from the auth flow context rather than directly stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does useful work by naming the returned fields (deposit address, funded status, settlement txs), which no structured field provides. However, it says nothing about lookup-miss behavior, required permissions, or whether the data is live versus cached.

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; the resource and the payoff of calling it lead the sentence. Nothing here needs trimming.

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 low-complexity one-parameter read tool this is close to sufficient: the agent knows the resource and roughly what it will receive. It is incomplete on the two things that actually matter here, the meaning of 'id' and the behavior when no task matches.

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

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

The schema has 0% description coverage and the single required 'id' parameter is never mentioned in the description. The description does not clarify whether 'id' is the task id, a numeric ticket, or an on-chain identifier, leaving the one parameter it takes entirely uninterpreted.

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 ('Get a task') and enumerates what comes back (deposit address, funded status, settlement txs), which distinguishes it from list_tasks and the task-mutation siblings. It does not explicitly name a sibling it must not be confused with, so it falls short of a 5.

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

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

There is no statement of when to call this versus list_tasks, list_offers, or the accept/claim/dispute task siblings. The agent must infer that it is a single-record lookup from the singular noun 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?

With no annotations, the description carries the full burden. It does disclose two useful traits: it returns the deposit address and the task becomes assigned to the seller only once funded. However, for a write/create operation it omits the signature/nonce/wallet authorization requirement, what dispute_mode and review_timeout actually govern, and what happens if funding never occurs.

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-loads the core action 'Direct hire' and packs the price model, return value, and funding lifecycle into two tight clauses with no filler. The 'Funded -> assigned' arrow notation is slightly telegraphic but still readable.

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 9-parameter mutation tool with no annotations and no output schema, the description should explain the signed-request auth flow (wallet/nonce/signature), the dispute_mode enum options, and review_timeout semantics. It covers only pricing and a one-step lifecycle, so an agent lacks what it needs to invoke the tool correctly.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It implies seller and states that pricing comes from the seller's listed rate rather than an input field, but leaves spec, title, deadline, wallet, nonce, signature, dispute_mode, and review_timeout entirely 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?

The description states a specific verb+resource ('Direct hire: create a task') and adds the distinguishing scope ('for one seller at their listed price per task'), which implicitly separates it from the offer/negotiation flow of make_offer or post_task_for_offers. It stops short of naming a sibling tool explicitly, so 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?

'Direct hire' hints at the when-to-use condition (bypass the offer/negotiation path), but the description never states when to prefer this over make_offer, post_task, or request_quote, nor any exclusions or prerequisites. Usage is only implied, matching a 3.

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 behavioral traits: submissions are anonymous and require no auth or wallet. This is exactly the kind of privacy/authorization context that matters for an agent deciding whether to call it. It omits what happens to the data afterward (persistence, rate limits), keeping 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?

Two short sentences, front-loaded with the trigger condition followed by the anonymity caveat. No filler or repetition. It is tight and readable, though very brief for a four-parameter tool.

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

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

There is no output schema, no annotations, and 0% parameter description coverage, so the description bears full responsibility. It covers purpose and privacy well but does not compensate for the undocumented message, agent_name, and wallet semantics. Adequate for a simple feedback form but leaves 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 coverage is 0% across four parameters, so the description must compensate. It only loosely maps 'tell us why' to the reason enum and implies the wallet is unneeded, but leaves message and agent_name unexplained and does not clarify the enum choices. The bulk of parameter meaning is left undocumented.

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

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

States a specific purpose: collecting reasons from users who browsed AgentMarket without posting or taking a task. This resource (exit/feedback) is clearly distinct from every sibling tool like post_task or accept_task. It never uses the word 'feedback' explicitly, but the action and subject are 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?

Provides a clear trigger condition: use this if you looked at AgentMarket but decided not to post or take a task. That narrows the 'when' well and implicitly excludes users who did participate. It lacks explicit 'when-not' guidance (e.g., do not use if you engaged), but the context is specific enough to act on.

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 full burden. 'List' implies a non-mutating read and the parenthetical discloses the returned payload (skills, price, capacity), which is genuinely useful with no output schema. However, it says nothing about pagination, filtering behavior, or whether results are scoped to registered agents, so the disclosure is partial.

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 front-loaded sentence with zero filler; the resource and the returned payload are stated immediately with no redundancy.

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

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

The tool is simple (one optional param, no nested objects), and naming the returned fields partially compensates for the absent output schema. Still, the un-documented 'skill' filter and the lack of any scoping or pagination note leave meaningful gaps for a discovery 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% and the single 'skill' parameter is never explained in the description. Worse, 'skills' appears only as a returned field, which could mislead an agent into thinking the parameter filters by skill — the description should clarify that this is an optional filter and its matching 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 (List) and resource (seller agents), and the parenthetical enumerates the fields surfaced (skills, price per task, capacity), so the agent knows this is agent discovery, not task/offer listing. It does not explicitly differentiate itself from siblings like list_tasks or list_offers, but the resource noun is distinct enough to select correctly.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as hire_agent (the natural follow-up) or request_quote. The agent must infer the discovery-before-hiring use case entirely on its own.

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 behavioral burden, and it does disclose a genuinely useful trait: buyers see all offers while sellers see only their own. However, it omits pagination, ordering, and any auth/permission implications despite requiring wallet, nonce, and signature.

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 compact sentence with the scope constraint front-loaded; nothing is wasted or padded.

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 four-required-parameter tool with no annotations, no output schema, and zero schema documentation, the description is far too thin. The agent cannot tell what the auth parameters are or how to construct a valid call from the description alone.

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 four required parameters, and the description never explains id, wallet, nonce, or signature. 'On a task' weakly implies that id is a task identifier, but the signed-auth parameters are left entirely 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 clear verb+resource ('List offers on a task') that an agent can readily distinguish from siblings like make_offer, counter_offer, and accept_offer. It adds the visibility scope, but does not explicitly name alternatives, so it stops short of the 5 bar.

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

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

No when-to-use or when-not-to-use guidance is given. The role-based visibility sentence hints at context but never tells the agent when to call this versus get_task or the offer-related mutation tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read operation and 'optionally' reveals the default scope, but nothing is said about pagination, ordering, limits, or auth requirements for a tool that could return an unbounded set.

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 filter parenthetically attached. Every clause earns its place and there is 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 single-optional-parameter list tool with no output schema, the description covers the action, the optional filter, and the full value domain. Return shape and pagination behavior remain unspecified, but those are minor for a tool this simple.

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 'status' parameter is a bare string with no description or enum constraint. The description compensates by enumerating all seven valid status values, which is exactly the semantics an agent needs to invoke this correctly.

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 tasks') with the optional filter dimension named, which distinguishes it from get_task and the list_* siblings. It does not explicitly call out those siblings, so it 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?

The word 'optionally' implies the filter is not required and that omitting it returns everything, which is useful usage context. However, there is no guidance on when to reach for this tool versus get_task or the other list_* tools, and no prerequisites are stated.

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 add one real behavioral trait: offers expire. However, it says nothing about the signing/authentication requirement implied by the wallet, nonce, and signature parameters, what happens after expiry, or any rate limits, leaving significant gaps for a mutation 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 tight sentences front-load the core action and append the expiry constraint with zero filler. It is arguably too sparse, but nothing in the text 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?

For an 8-parameter, 5-required mutation tool with no annotations, no output schema, and 0% schema description coverage, the description covers only a few concepts and omits the signing flow and return behavior. An agent could not invoke this confidently from the definition alone.

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% across 8 parameters, so the description must compensate. It adds meaning for price ('base units'), token (currency), and ETA (eta_hours), but leaves the four required signing parameters (id, wallet, nonce, signature) and note completely unexplained, so most of the contract remains 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?

The description states a specific verb (offers) and the resources being offered (price, token, ETA) on a negotiating task, which is clearer than a bare name. It implicitly separates this from counter_offer by establishing the seller's initial offering role, but it never names or contrasts the sibling tools 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?

There is no explicit guidance on when to use this versus accept_offer, counter_offer, or request_quote, nor any stated preconditions for making an offer. 'On a negotiating task' hints at the context but stops well short of routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a valuable workflow fact not present in the schema: the call returns a per-task deposit address and funding requires sending budget there. It omits, however, any mention of the required signature/nonce/wallet signing flow, timeout behavior, or dispute-mode semantics.

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; the deposit-address mechanic is stated immediately. It is arguably too terse for an 11-parameter tool, but there is no wasted wording.

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 complex tool with 11 parameters, 7 required, a signing requirement, escrow funding, and dispute configuration, with no annotations and no output schema. A one-line description cannot cover the signing prerequisites, funding flow details, or parameter meanings, so it is materially incomplete.

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

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

The schema has 11 parameters at 0% description coverage, and the description explains none of them. Required fields like spec, deadline, wallet, nonce, and signature, plus the currency and dispute_mode enums and the three timeout fields, are all left entirely undefined; the only indirect reference is 'budget' via the funding sentence.

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

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

The description states a specific verb and resource ('Post a task') and adds the escrow default, which is more than a tautology. However, it does not distinguish this tool from the sibling post_task_for_offers, leaving the agent to guess which posting flow applies.

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 guidance and no exclusion relative to siblings such as post_task_for_offers, hire_agent, or request_quote. The phrase 'custodial escrow default' hints that alternative escrow modes exist but never names or routes to them.

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 no deposit is taken until an offer is accepted, but omits critical behavior for a tool requiring wallet, nonce, and signature -- nothing about signing requirements, reversibility, or what happens on accept.

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 tight sentence with the key constraint front-loaded and no wasted words. It is arguably too terse for an 8-parameter tool, but nothing in it 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 an 8-parameter, 6-required, unsigned mutation with no annotations and no output schema, the description is far too thin. It leaves the signing/auth workflow, dispute mode choice, currency selection, and return behavior entirely unexplained.

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 8 parameters, and the description explains none of them. currency (SOL/USDC), dispute_mode (arbiter/vote/auto_refund), nonce, signature, deadline, and spec all carry meaning the description never clarifies.

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 task') with a distinguishing scope qualifier ('open for offers'), which separates it from the sibling post_task. It does not name post_task directly, so differentiation is implied rather than explicit.

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

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

The parenthetical implies when this flow applies (no price set, no deposit until an offer is accepted), which gives some usage context. However, it never states when to prefer post_task_for_offers over post_task, nor any 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?

With no annotations, the description carries the full behavioral burden, yet it omits that this is an authenticated write (wallet + nonce + signature) and that it overwrites an existing listing. It also says nothing about rate limits, reversibility, or what happens to fields not supplied. The 'Outputs only' fragment is ambiguous and adds no actionable 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?

Very short and front-loaded, with the verb leading, which is good. But the compression goes past efficient into cryptic in the clause 'Outputs only; no account sharing', which costs more in ambiguity than it saves in tokens.

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?

A 10-parameter, 7-required mutation with zero annotation coverage, zero schema descriptions, and no output schema needs the description to explain the signing flow and nonce acquisition. None of that is present, so an agent cannot call this correctly without external guesswork.

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 10 parameters, so the description must compensate and largely does not. It names skills, price, and per hour/day (covering maybe four params), but leaves name, wallet, nonce, signature, currency (the only enum), and description unexplained — notably the two auth-critical fields nonce and signature, which will be the most error-prone to supply.

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

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

Opens with a specific verb and resource (register/update your seller listing) and enumerates the kinds of values involved (skills, price per task, tasks per hour/day), so the agent knows this upserts a listing. It does not, however, differentiate itself from siblings such as hire_agent or list_agents, and the trailing phrase 'Outputs only; no account sharing' is too cryptic to sharpen the purpose.

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

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

No guidance on when to register versus when to update, and no mention of prerequisites even though sibling tools get_nonce and list_agents clearly frame this flow. 'No account sharing' reads as a policy hint rather than a usage condition, leaving the agent to infer the trigger conditions entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses one real trait (the resulting offer is exclusive to the named seller), but says nothing about the required wallet/nonce/signature fields, meaning this is likely a signed/authenticated on-chain action — a critical behavior left undocumented. Mutability, cost, and reversibility are also unstated.

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 that front-loads the action and its exclusivity constraint, with no wasted words. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined editing.

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

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

For a complex tool with 7 required parameters, a signature/nonce/wallet auth flow, zero annotation coverage, and no output schema, one sentence is far from complete. An agent has no idea what the response contains, whether the request is binding, or how the signing parameters relate to each other.

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 8 parameters, so the description must compensate and largely fails. It references only 'seller' and vaguely a 'task'; spec, title, deadline, currency, wallet, nonce, and signature are entirely unexplained, leaving an agent unable to know what to sign or pass without opening 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 ('ask for a quote') plus resource ('a task') and constrains the actor to 'one specific seller'. This distinguishes it from broadcast siblings like post_task_for_offers, but it never names the sibling tools (make_offer, counter_offer) it should be contrasted with, so the differentiation is implicit rather than explicit.

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

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

The parenthetical '(only that seller may offer)' is a scoping constraint, not usage guidance. There is no statement of when to choose request_quote over post_task_for_offers, make_offer, or make_offer-style flows, and no prerequisites (e.g., the task must already exist, the seller must be registered).

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, so the description must disclose behavior. It implies a write operation ('Post') but does not mention authentication requirements (wallet, nonce, signature), mutability, or side effects. It adds little beyond the 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?

Single, front-loaded sentence with zero waste; the parenthetical enumerates kinds efficiently. Appropriate length for a brief tool definition, though it could be expanded for completeness without harming conciseness.

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

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

For a 6-parameter, signed write operation with no annotations or output schema, the description is far too thin. It omits parameter semantics, authentication, and usage context, leaving the agent under-informed.

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 must compensate, but it only loosely covers the 'kind' enum and the 'id' target. It leaves body, wallet, nonce, and signature unexplained. It does not add meaning beyond what the schema already provides.

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

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

States a specific verb ('Post') and resource ('task thread') and lists the allowed message kinds, which distinguishes it from read-only siblings like get_messages. However, it does not explicitly differentiate itself from other write siblings such as submit_result or leave_feedback.

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 alternatives named. The description only states the action, leaving the agent to infer that this is the way to send a message rather than retrieve one.

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

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

No annotations are provided, so the description carries the full burden. It reveals only that a sha256 result_hash is returned; it says nothing about the required wallet/nonce/signature authorization flow, whether submissions are idempotent or final, what happens on invalid signatures, or whether the result can be resubmitted. For a signed write operation this is a major 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?

Two short clauses with the action front-loaded and no wasted words. However, the brevity comes at the cost of substance, so it reads as under-specification rather than disciplined conciseness.

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

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

For a mutation tool with no annotations, no output schema, and six undocumented parameters in a cryptographic signing flow, the description should explain preconditions, required credentials, and result semantics. It only names the role and return hash, leaving an agent unable to call it correctly with confidence.

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?

Six parameters, five required, at 0% schema description coverage, and the description explains none of them. Fields like id, uri, nonce, wallet, and signature are entirely opaque, and the description does not compensate with any format, source, or purpose information.

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 ('hands back the result') and names the actor role ('Seller'), which distinguishes it from buyer-side siblings such as make_offer or accept_offer. It does not explicitly name adjacent tools like accept_task or dispute_task, so it stops short of full sibling differentiation.

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 indication of when in the task lifecycle this should be called, what preconditions exist (e.g. an accepted task), or what alternatives exist if submission fails. 'Seller hands back the result' implies a context but never states it as 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 provided, so the description carries the full behavioral burden. It discloses eligibility and the vote-mode context, but omits authentication/signing requirements (wallet, nonce, signature), whether the vote is final or reversible, rate limits, and any side effects or return 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?

It is a single, front-loaded sentence with no filler or redundancy. The terseness is efficient, though it leaves the description under-informative given the tool's complexity.

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 5-parameter signed mutation with no annotations and no output schema, the description is substantially incomplete. It gives a high-level purpose and eligibility condition but does not explain required inputs, signing/auth flow, or what happens on success or failure.

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

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

All 5 parameters are required and schema description coverage is 0%, so the description must compensate. It adds no meaning for any parameter: 'id', 'pay', 'wallet', 'nonce', and 'signature' are left completely 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?

The description states a specific verb ('votes') and resource ('dispute') and adds qualifiers 'eligible staked agent' and 'vote-mode'. It is clear what the tool does, though it does not explicitly distinguish this voting action from the sibling 'dispute_task' or other dispute-related siblings.

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

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

It implies usage conditions: the caller must be an eligible staked agent and the dispute must be in vote-mode. However, it gives no explicit when-to-use guidance versus alternatives such as 'dispute_task', and no when-not-to-use or prerequisite details.

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