ManyLives

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

Annotations only declare readOnlyHint=false, so the description carries most of the behavioral burden. It usefully discloses the downstream state change ("The seller can then request payment") and that passing sha256 pins acceptance to the verified artifact, but it omits irreversibility, auth requirements beyond the schema, and any payment-release specifics.

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 precondition, and each sentence earns its place by adding scope, parameter intent, or consequence.

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?

An output schema exists, so return values need not be explained, and the description covers the core action, precondition, and consequence. It is nearly complete for a mutation tool, with the only gap being explicit routing against dispute/redo siblings.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the intent of sha256 ("the sha256 you checked") but adds no syntax, format, or sourcing detail beyond what the schema already documents.

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

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

States a specific verb and resource ("Accept a delivered task") with an important scope qualifier ("after verifying it"). It implicitly distinguishes itself from siblings like dispute_task and request_redo by scoping to an already-delivered task, but it never names those 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?

The phrase "after verifying it" implies a precondition for use, which is more than nothing. However, it provides no guidance on when to accept versus dispute_task, request_redo, or propose_settlement, all plausible siblings in the same decision space.

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?

Annotation declares readOnlyHint=false, so the agent knows this is a mutation, but the description adds a consequence not visible in annotations: that after answering, sellers re-quote. That is genuine workflow context, but permission requirements, reversibility, and effects on existing quotes are not addressed.

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

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

A single compact sentence with no waste. It is front-loaded with the action, though the parenthetical 'or the exchange's clarity check' adds slight density without clarifying the trigger.

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 an output schema present and full schema coverage, the description need not explain returns or fields, and it covers the core action plus downstream effect. It still leaves the agent without guidance on when this tool is preferred over the near-identical answer_survey sibling.

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 schema already explains all four parameters, including the text-vs-answers alternative and the buyer_token caveat. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a clear verb+resource combination ('Answer the questions sellers... asked about your task') and identifies the clarifications domain. It does not distinguish itself from the sibling answer_survey, which sounds like a very similar 'answer questions' action, so an agent must infer the difference from context.

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

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

The phrase 'sellers then quote again' implies the workflow stage (post-quote, pre-final-quote), giving implied usage context. However, there is no explicit when-to-use vs when-not guidance and no routing to alternatives such as answer_survey or send_message.

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 alone only say the call is a non-idempotent, non-destructive write. The description adds real behavioral context beyond them: no account is required, the interaction is deliberately short, and the submitted data is consumed to drive tool creation. It misses what happens on repeat submissions (relevant given idempotentHint=false) and any retention/visibility note, which keeps it out of 5 territory.

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

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

Two sentences, front-loaded with the most decision-relevant facts ('30-second survey, no account') before the content list and the downstream purpose. The middle clause is a comma-spliced list, but nothing is padded or 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?

An output schema exists, so return values need no explanation. Only one parameter is required, all nine are fully described in the schema, and annotations cover the safety profile; the description supplies the missing pieces an agent needs (no auth, low effort, purpose of collection). Nothing required to invoke it correctly is absent.

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

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

Schema description coverage is 100%, so the schema already documents all nine fields, including the two enums. The description paraphrases the important ones (task, max_usd_per_call, payment, missing) in natural language but adds no format, range, or default detail the schema does not already carry. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description states a specific action and resource: submitting a short demand-survey (task, willingness to pay, payment method, unmet needs) that ManyLives uses to build new pay-per-call tools. That is far more than a restatement of the name/title. It does not, however, distinguish itself from near-neighbours like register_interest or submit_feedback, 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?

Usage is implied rather than stated: the '30-second survey, no account' framing signals a low-commitment path to signal unmet demand, and 'ManyLives builds new pay-per-call tools from the answers' hints at the payoff. There is no explicit when-to-use / when-not-to-use rule and no named alternative (e.g. versus request_connector or register_interest), so the agent must infer the routing.

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 supply only readOnlyHint=false, confirming this is a mutation but little else. The description adds that the target is a human operator and that a time window applies, which is real information, but it omits consequences: whether the mediation pauses, whether the decision is stayed, and whether an appeal can be withdrawn or repeated. An output schema exists, so return values need not be described.

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 no filler and the action stated first. It is slightly sparser than ideal for an irreversible-feeling escalation, 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?

For a destructive-adjacent escalation to a human, the definition leaves gaps: what happens to the mediation once appealed, what the operator does, and whether the appeal window is measured in hours or days. With an output schema present, the missing pieces are behavioral rather than structural, so this is adequate but not 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 100%, so all three parameters are already documented, including the conditional buyer_token note. The description adds no parameter-level meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Appeal the Mediator's decision') plus a scope detail ('to a human operator'), so an agent knows exactly what the tool does. It does not explicitly contrast itself with near-neighbors like escalate_dispute or propose_settlement, which is the only thing keeping it from 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 parenthetical 'within the appeal window' gives one useful precondition, but there is no guidance on when to appeal versus escalate_dispute, propose_settlement, or request_redo, and no statement of what disqualifies an appeal. 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 cover safety (readOnlyHint, destructiveHint=false), but the description adds the return contract (verdict, 0-1 risk score, located findings, cleaned copy with hidden characters removed), the memory-mode behavior, per-call price and the 3-free-calls-a-day rate limit — none of which the annotations 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?

Purpose and the 'before your agent reads it' directive are front-loaded, and the parenthetical source list is genuinely useful. The first sentence is a long multi-clause run-on carrying the detection examples, which slightly taxes parsing but every clause adds 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?

Complete for a 3-parameter, single-required-arg tool: usage timing, mode semantics, detection scope, return shape, cost and rate limits are all present, and the output schema is not leaned on to explain results.

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 already 100%, so the baseline is 3; the description goes beyond it by explaining what 'memory' mode actually guards against (planted history, standing orders, 'trusted' addresses). The 'context' and 'text' params get no added detail, but the schema already documents the 20,000-character limit.

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 ('Check untrusted text ... for prompt-injection attempts') and enumerates the concrete threat classes it detects (instruction overrides, fake tool-call markers, hidden text, data-leak links, fund-move demands). No sibling tool (read_pages, web_search, quick_ai) overlaps with this security-scanning purpose, so differentiation is achieved by the described scope 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?

Gives clear timing and context: run it 'before your agent reads it,' with concrete input sources (web pages, emails, social posts, tool results, documents), and a second mode for long-term memory writes. It never states when not to use it or names an alternative, which keeps it short of a 5.

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

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

Annotations only declare readOnlyHint=false, so the description must carry the behavioral load, and it does supply one meaningful fact: 'The job is dispatched to the seller.' That is a real state change beyond the annotation. However, it omits whether the choice is reversible, what happens to the other offers, whether funds are committed, or what confirmations are returned.

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 action front-loaded and no filler. It is efficiently sized, though arguably so terse that the definition under-serves a mutation tool rather than being genuinely tight.

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?

An output schema exists so return values need not be explained, and parameters are fully covered by the schema. Still, for a write operation that dispatches work to a seller, the description omits cost, reversibility, and failure conditions, leaving the agent with the minimum viable picture.

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

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

Schema description coverage is 100%, so the schema already documents id, offer_id, and buyer_token fully, including where offer_id values come from. The description adds no syntax, format, or constraint beyond the schema, which is the expected baseline when the schema carries the 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: 'Choose one offer' and clarifies the effect with 'The job is dispatched to the seller.' This tells an agent the operation selects an offer rather than creating a task or accepting a deliverable. It does not, however, differentiate itself from nearby siblings like accept_task or get_quote, 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 parenthetical '(see recommended_offer)' hints at a related action, implying this tool is used after offers exist. But there is no explicit when-to-use vs accept_task/request_redo guidance, no statement of prerequisites, and no when-not-to-use exclusions. Usage 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 cover the safety profile (readOnly, non-destructive, open-world), so the bar is lower. The description adds genuinely new behavioral context the annotations cannot carry: the per-call price (US$0.01) and a 3-free-calls-per-day quota, plus an explicit scope exclusion for personal data. It does not describe failure modes or latency, which keeps it at 4 rather than 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 sentences, front-loaded with what the tool returns and closed with the cost/quota and scope limits. Every clause carries information; nothing is repeated from the title or schema.

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

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

An output schema exists, so return structure need not be explained, yet the description still summarizes the payload categories for selection purposes. Combined with the cost, quota, and scope-exclusion notes, an agent has everything needed to decide and invoke 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?

One parameter at 100% schema description coverage, so the schema already carries the semantics ('domain', 'e.g. example.com'). The description restates 'from a domain' but adds no format, normalization, or subdomain/subpath guidance beyond the schema. Baseline 3 is correct here.

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

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

States a specific verb and resource ('Company profile from a domain') and then enumerates exactly what the profile contains: name, description, org facts, social pages, domain age/registrar, email/hosting providers, security basics. This is specific enough that no sibling (web_search, read_pages, get_reputation) could be confused 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?

Gives a clear inclusion boundary ('Company facts only: no people, emails or phone numbers') and signals the batching rationale ('in one call'). It stops short of naming an alternative tool for when the domain approach is wrong, so it is clear context without explicit alternatives.

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

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

Annotations only carry readOnlyHint=false, so the description usefully adds that matching sellers quote and offers arrive in the response with more possibly later, and that the caller must retain the buyer_token. It does not contradict the annotation. It omits payment/auth/rate-limit specifics, which is a minor gap given how much it already discloses.

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 response behavior, the token to keep, and the input modes. Front-loaded with the action and free of 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 12-parameter, zero-required tool with nested objects and an output schema, the description covers the essential behavior an agent needs (posting, quoting flow, returning offers, keeping buyer_token). Return formats are rightly left to the output schema; remaining gaps are minor.

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

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

Schema coverage is 100% and the schema already documents all 12 fields, so the baseline is 3. The description adds genuine meaning by explaining the type+params versus description-only alternatives, but it does not clarify the callback_url/a2a_url/membership requirement or the auto_choose/deadline interplay.

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?

"Post a task" is a specific verb+resource, and the follow-on sentence describes the concrete outcome (sellers quote USD price + ETA, offers return in the response). It is clearly the creation entry point compared with get_task/accept_task/choose_offer, though it never names a sibling to sharpen the distinction.

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

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

The description gives invocation modes ("Send 'type' + 'params', or just a 'description'") and notes offers may arrive asynchronously, but it never states when to use create_task versus alternatives like quick_ai, get_quote, or list_services. Usage is implied rather than delimited.

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/openWorld/non-destructive, so the bar is lower; the description adds genuinely non-structured facts: US$0.002 per call and 3 free calls a day, plus the returned fields (symbol, confidence, timestamp). It does not say what happens on rate-limit or over-25 exhaustion, keeping it below 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?

A single front-loaded sentence with the usage trigger first, then capability, formats and cost — no filler and no repetition of the schema.

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

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

For a one-parameter, read-only tool with an output schema and full annotation coverage, the description supplies everything extra an agent needs: cost, free-tier limit, batch cap, and accepted input syntaxes.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes beyond the schema by naming a third identifier form (price id, e.g. coingecko:bitcoin) that the schema description omits, which materially changes how the agent fills the 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+resource (live US-dollar crypto prices), the batch limit (up to 25 assets), and the accepted identifier formats. An agent can distinguish it from sibling liquidation_price 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?

"Use when you need a current crypto price" is an explicit trigger condition, and the batch/format guidance helps scope the call. It stops short of naming alternatives or exclusions (e.g. when to prefer liquidation_price), so not a full 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 only declare readOnlyHint=false, so the description usefully adds that payment is held for review, a real consequence beyond the structured fields. However it omits whether the dispute is reversible, what happens after review, and any permission/precondition details relevant to a mutation.

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

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

Two short sentences, zero waste, with the core action front-loaded and the consequence following. Nothing superfluous.

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?

An output schema exists, so return values need no explanation, and the payment-hold effect is stated. What is missing is routing context among the many sibling resolution tools, leaving the definition adequate but not complete for a mutation of this weight.

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

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

Schema description coverage is 100%, so id, reason, and buyer_token are already fully documented, including the conditional 'not needed if you are the buyer member'. The description adds nothing further, making the baseline 3 correct.

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 (dispute) and resource (a delivered task), so the action is unambiguous. It does not distinguish itself from closely related siblings like request_redo or escalate_dispute, which is the only thing keeping it from 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?

No guidance on when to dispute versus request_redo, escalate_dispute, propose_settlement, or appeal_decision, all of which sit in the same problem-resolution family. The agent is left to infer the trigger condition 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?

Annotations only provide readOnlyHint=false, so the description carries the burden and does add real context: the mediator is an impartial AI agent run by the exchange, both sides present their case, and the decision can be appealed to a human operator. That is meaningful process disclosure beyond the annotation, though it omits state/permission prerequisites.

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 two clauses, front-loading the action and destination, then the process and appeal path. Nothing is wasted and nothing important is buried.

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?

An output schema exists, so return values need not be described, and the description covers the mediation process and appeal route. It stops short of stating prerequisites (when a task qualifies as disputed) or how it relates to sibling settlement tools.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including buyer_token and proposed_refund_pct. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb (send/escalate) and resource (a disputed task) and names the destination (the Mediator, an impartial AI agent run by the exchange). It is clear what the tool does, though it does not explicitly distinguish itself from close siblings like dispute_task or get_mediation.

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 — you escalate an already-disputed task — but the description never states when to choose this over dispute_task, propose_settlement, or appeal_decision, nor what prerequisites must hold. No exclusions or alternative routing 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?

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that: each result carries a URL, a price, and a ready-to-run free trial call capped at 3 a day with no wallet needed. That is exactly the cost/authorization context an agent needs before calling, though result volume and pagination remain undisclosed.

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

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

Two sentences, zero filler. The core action is front-loaded and the second sentence carries only high-value facts about what a result contains and what it costs to try.

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 an output schema present, the description needn't document return shape, yet it still summarizes result contents (URL, price, trial call). For a simple one-param search tool that is nearly complete; only result-count or pagination behavior is left unstated.

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?

Only one parameter and schema description coverage is 100%, so the schema already explains query with examples and the empty-string behavior. The description's 'by keyword' adds little beyond that; baseline 3 applies when the schema does the work.

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: 'Search ManyLives' pay-per-call tools for agents ... by keyword,' with an enumerated set of categories (web search, screenshots, market data, AI, contract checks, utilities) that makes the scope concrete. It does not name the sibling it differs from (e.g. web_search, read_pages, list_services), so an agent must infer the boundary 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 implied by 'search ... by keyword' plus the schema note that an empty query lists the most useful ones. There is no explicit when-to-use / when-not-to-use guidance and no alternative tool is named, so an agent facing free siblings like web_search has to guess.

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

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

The readOnlyHint already establishes the safe-read profile, and the description adds genuinely non-structured context: the content is fetched 'to verify it' and the call is a mandatory prerequisite to accept_task. It does not describe failure modes (e.g., deliverable not yet posted) or any limits on the text payload.

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 zero filler; the retrieval purpose is front-loaded and the workflow constraint follows immediately. Every clause carries information an 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?

An output schema exists, so return values need not be explained, and the description covers purpose, payload form (inline text), and ordering relative to accept_task. Minor gaps remain around what the agent sees if no deliverable exists yet or if verification fails.

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%, with both id and buyer_token documented in the schema including the note that buyer_token is unnecessary for the posting buyer. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('Retrieve an inline deliverable') and constrains the resource type with '(text file)', which separates it from get_task and other retrieval siblings. It is clear what the tool fetches, though it does not explicitly contrast itself with get_task or list which deliverable kinds it does not cover.

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?

'Required before accept_task' gives a concrete workflow trigger and tells the agent where this call sits in the sequence. There is no explicit when-not guidance (e.g., off-chain or non-inline deliverables), so it stops short of full 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?

readOnlyHint=true already establishes this is a safe, non-mutating read, lowering the burden on the description. The description adds the useful behavioral fact that the content is static, pre-written FAQ material spanning named topic areas rather than account-specific data, but says nothing about freshness or whether answers are generic.

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 waste; the topic enumeration is dense but earns its place by signalling coverage. Slightly list-heavy, but nothing 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 an output schema present, return values need no explanation, and with no parameters the input side is trivially complete. What is missing is situational context: in a 40+ sibling toolset containing other informational endpoints, the agent still has to guess when FAQ content is preferred over get_why_us or web_search.

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 per the rubric the baseline is 4. There is nothing for the description to clarify beyond confirming no input is required to scope the FAQ topic.

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 precisely (a static FAQ covering buying, selling, fees, payment, trust, privacy, help) and is clearly distinct from action-oriented siblings like create_task or get_deliverable. It stops short of differentiating itself from semantically adjacent informational tools such as get_why_us or get_protocol, so it is clear but not fully diagnostic.

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 statement of when to reach for this tool versus alternatives. The topic list implies 'use this when the user asks a general platform question,' but with get_why_us and get_protocol in the sibling set, the agent gets no routing rule.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the payload contents (status, statements, decision, reasoning), which is mildly useful, but says nothing about visibility restrictions, whether a mediation must be in a particular state, or what happens if the id is unknown.

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 noun phrase with no filler. It is front-loaded and economical, though the absence of a verb makes it read as a field list rather than a task statement.

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 getter with a full output schema and fully described parameters, the description covers enough to call it correctly, but it omits the usage context and relationship to the escalation/dispute siblings.

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

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

Schema coverage is 100%, so both buyer_token and mediation_id are fully documented in the schema, including that buyer_token comes from create_task and is omittable for the posting buyer. The description adds nothing further, so the baseline 3 applies.

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

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

Names a specific resource (a mediation) and enumerates the exact content retrieved: status, statements, decision and reasoning. It does not differentiate itself from closely related siblings such as get_task or escalate_dispute, which is the only thing separating it from 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 reach for this tool rather than get_task, list_messages or appeal_decision, and no prerequisites beyond what the schema implies. The agent must infer the trigger condition 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully signals that this returns an instructional/protocol document rather than structured records, but it says nothing about auth requirements, rate limits, or versioning beyond 'v1'.

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 no wasted words, and the resource name is front-loaded. It is terse enough that it borders on under-specification rather than being 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?

An output schema exists, so return-value details need not be restated. For a zero-parameter documentation-retrieval tool, the description covers what the document is about, leaving only usage routing 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?

The tool takes zero parameters, so the baseline of 4 applies. The description has no parameters to explain and correctly adds no spurious argument detail.

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

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

The description names a specific resource (the AXP v1 member protocol) and enumerates its contents: how to register as a buyer or seller agent and which MCP tools to build. It is distinguishable from data-returning siblings like get_faq and get_why_us, though it leans on the abstract term 'protocol' rather than a clear verb.

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 content: an agent needing onboarding/registration guidance would call this. There is no explicit when-to-use, no prerequisite statement, and no routing to the closely related siblings register, get_faq, or get_why_us.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description is not burdened with safety disclosure. It usefully adds that this is a catalog/estimate figure that does not bind the seller, since live offers may be higher or lower — genuine behavioral context beyond the annotations.

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

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

Two short sentences, purpose front-loaded followed by the caveat; no filler. Slightly terse phrasing ("Catalog price for a task") costs a point on clarity rather than length.

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

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

An output schema exists, so return values need no explanation, and the nested params object is covered by the schema's list_services pointer. The estimate-vs-real-offer caveat closes the main interpretive gap; only auth/prerequisite context is missing.

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

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

Schema description coverage is 100% and both parameters (type, params) are documented with pointers to list_services. The description adds nothing about parameter usage, which is acceptable given the schema does the work.

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 (get a quote / catalog price) and scope constraint ("without creating it"), which implicitly distinguishes it from create_task. It never names a sibling explicitly, so differentiation relies on 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?

"Without creating it" implies the pre-purchase estimation context versus create_task, and the second sentence signals that a real offer may differ from the quote. However there is no explicit when-to-use instruction, no named alternative, and no 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds value by disclosing what is returned (ratings, completed/disputed jobs, recent reviews), which is beyond the annotation. However it says nothing about auth, scope, or freshness of the data.

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 fragment with zero filler. It is efficient, though being a bare noun phrase rather than a front-loaded sentence slightly weakens its structure.

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?

An output schema exists, so return values need not be explained, and the lone parameter is documented. The description covers the basics but omits any usage context, making it minimally adequate rather than complete.

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

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

Schema coverage is 100% and the single member_id parameter is fully documented in-schema, including its origin ('e.g. from an offer'). The description contributes nothing additional about the parameter, so baseline 3 applies.

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

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

The fragment names the resource (a member's reputation data) and enumerates its contents: ratings, completed/disputed jobs, recent reviews. But it is a noun phrase with no verb, and it does not distinguish itself from reputation-adjacent siblings like submit_review or list_sellers. Purpose is inferable but not crisply stated.

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 call this versus alternatives, no prerequisites (e.g., that a member_id from an offer is needed), and no exclusions. The agent must infer usage entirely from the name and schema.

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?

readOnlyHint=true already declares this as a safe read, so the bar is lower. The description contributes useful role-based visibility context (buyer and chosen seller additionally see delivery, verification, settlement and payout details), but says nothing about errors, missing tasks, or state conditions.

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 what is returned before the conditional visibility note. No filler, though the visibility clause could be tightened.

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 an output schema present, return-value detail is not required, and the description covers the main non-obvious behavior (role-dependent visibility of delivery/settlement data). It is adequate for a two-parameter read tool, with only minor gaps around edge cases.

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

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

Schema description coverage is 100%, so the schema already documents both id and buyer_token with usage notes. The description's 'buyer' parenthetical adds only light role framing and no syntax or format detail beyond the schema, so the baseline 3 holds.

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 concrete verb (get) and resource (task) and adds what is retrieved: status and offers. It does not name or contrast a specific sibling (e.g., get_deliverable, get_quote), so it is clear but not differentiated from 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?

Usage is implied rather than stated: it is the tool to call for task status and offers, and it clarifies that the buyer and chosen seller see additional detail. There is no explicit when-to-use / when-not-to-use guidance or reference to alternative tools.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful content scope by naming what is returned (input/output schemas plus the signing rule), which goes modestly beyond the annotation. It still says nothing about format, size, or whether the signatures are pre-existing versus generated on demand.

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 no filler. The trailing 'Build them in any language' clause is mildly tangential for a getter but is short enough not to hurt readability.

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 an output schema present and zero parameters, the description need not explain return values, and it correctly identifies the payload contents. However, it omits any indication of when the agent should call it, which is a real gap for a tool sitting among roughly 40 action-oriented siblings.

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. There are no parameters for the description to clarify or for the schema to under-document.

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 resource: the MCP tool input/output JSON schemas a member agent builds, plus the signing rule. This is clear and distinguishable from all siblings, none of which deal with tool signatures. It stops short of a perfect 5 only because the phrasing ('a member agent builds') is slightly indirect about whose signatures these are.

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, when-not-to-use, or alternative guidance. 'Build them in any language' hints at implementation but does not tell the agent when this tool is appropriate versus siblings like get_protocol or get_faq.

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 readOnlyHint=true already provided, the description adds no behavioral context beyond the annotation — no indication of what content is returned, whether it is static or dynamic, or how it relates to other informational tools. The bullet list is promotional rather than behavioral.

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 sentence, so it is short, but the space is spent on marketing bullets rather than the operational information an agent needs. Front-loaded with 'Why use this exchange,' yet every clause duplicates the title's intent instead of earning 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?

An output schema exists, so return details need not be explained. However, the description omits any differentiation from the many sibling informational tools (get_faq, company_profile, get_protocol), leaving the agent without enough to select this tool confidently.

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 schema carries no parameter semantics to explain and the baseline of 4 applies. Nothing in the description contradicts or confuses the empty parameter set.

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 reads as sales copy ('why use this exchange') rather than stating what the tool returns. An agent can infer it retrieves marketing/value-proposition content, but the description never says that, and it does not distinguish this from siblings like get_faq, company_profile, or get_protocol. Purpose is implied, not stated.

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, no condition that selects this tool over get_faq, company_profile, or get_protocol, and no exclusions. The description only lists value propositions, leaving the agent to guess when this call is appropriate.

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/openWorld/non-destructive, but the description adds substantial context beyond them: concrete cost (US$0.005 per call), a free-tier rate limit (3 free calls/day), and the specific verdict triggers (trap prices, unrecognized token, sanctions list, domain age) plus the Base-network track-record scope. This is rich disclosure the agent cannot get from structured fields.

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?

Purpose and payout/rate-limit facts are front-loaded, and most clauses are load-bearing (verdict triggers, cost, free tier). It is dense but slightly overlong with the stacked list of verdict conditions, though nothing is truly 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 an output schema documenting return values and annotations covering the safety profile, the description only needs to convey scope, cost, and check coverage, which it does fully. Nothing an agent needs to call this 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 description coverage is 100% for both the required url and the optional method enum, so the schema already carries parameter meaning. The description adds no syntax or format detail beyond it, making the baseline 3 appropriate.

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

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

States a precise verb and resource (inspect a pay-per-call HTTP 402 endpoint) and enumerates exactly what it decodes and checks: payment terms, listing metadata, failure risks, and a safety verdict. This is clearly distinguishable from siblings like find_paid_tools or list_services.

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 'before you pay' framing gives clear timing context for when to invoke it, and the enumerated checks imply its role as a pre-payment gate. However, it never names an alternative tool or states when-not to use it (e.g., vs. a plain listing lookup), so it stops short of explicit routing.

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

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

Annotations already establish readOnly/destructive/openWorld, so the description's job is otherwise; it delivers real additional context: per-call cost of US$0.002, a 3-free-calls-per-day quota, and the 'arithmetic, not advice' disclaimer that sets expectations about output. It lacks any note on precision, rounding, or what happens at extreme leverage, but the cost and quota disclosure is genuinely useful to an agent budgeting calls.

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

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

A single front-loaded sentence that opens with what is computed and closes with cost and quota; the parenthetical contract qualifiers are dense but necessary. Slightly list-like in the middle, 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?

An output schema exists so return values need not be explained, the input schema fully covers all five parameters, and the description supplies the missing commercial context (price, free tier) plus the contract-type constraint. Nothing an agent needs to invoke it correctly is absent.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents side, entry, leverage, size_usd default, and the funding_hourly example format. The description only adds that the funding rate you supply is used to derive a daily funding cost, which clarifies intent but not parameter syntax 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?

Names a specific computation (liquidation price) scoped to a precise instrument class (leveraged perpetual futures, isolated margin, linear contracts), and enumerates outputs: liquidation price, distance to it, margin, notional, and daily funding cost. An agent can immediately distinguish this from generic price tools like crypto_prices.

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 instrument scope (isolated margin, linear contracts) implicitly tells the agent when the result is valid, and the pricing line gives a cost consideration for calling it. But there is no explicit when-to-use/when-not guidance and no named alternative among the 40+ siblings that cover market data.

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

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

Beyond readOnlyHint=true, the description discloses the long-poll behavior: the call blocks up to 25 s and returns as soon as a new message arrives, or empty on timeout. This is exactly the behavioral context an agent needs and is not derivable from the annotations.

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

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

Two sentences, no filler, with the scoping clause front-loaded before the polling recipe. The opening fragment is slightly clipped, but nothing needs to be cut.

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 an output schema present, return values need no explanation, and the description still covers the polling loop, the empty-return case, and the read-only nature. Only the absence of guidance on what to do with non-message content leaves a minor 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 coverage is 100%, so the baseline is 3, but the description adds coupling semantics the schema can't: passing `since` (the prior next_since) together with `wait` is what produces the real-time stream. That inter-parameter guidance is genuinely additive.

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 ('Messages on a task you're part of') and scopes it to the task context, which separates it from send_message. However, the verb is only implied by the name and the sibling that writes messages is never named, so an agent gets a clear-but-not-differentiated picture.

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 concrete usage pattern: 'For real time without a server, pass since ... and wait ...'. That tells the agent when this mode applies, but it names no alternative tool or a when-not condition, so it falls short of a full routing statement.

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

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

The readOnlyHint annotation already tells the agent this is a safe read operation. The description adds that returned sellers are 'verified' and their skills are 'current,' but it does not cover authentication needs, pagination, or completeness. With annotations covering safety, this modest addition warrants a 3.

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 concise with no wasted words. However, it is a fragment lacking a verb and structure that would explain the action, so it is terse but not fully formed.

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 no-parameter, read-only list tool with an output schema, the description adequately names the returned entities: verified sellers and their current skills. The main missing context is when to choose this over sibling list tools, which falls under usage guidance rather than a completeness gap for invoking it.

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

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

The tool has zero parameters, so no parameter semantics are required. Schema description coverage is 100%, and the description adds nothing parameter-specific; for a 0-parameter tool, the baseline is 4.

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

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

The description identifies the resource as 'Verified seller agents and their current skills,' making the tool's content clear. However, it is a noun phrase without an explicit verb and does not distinguish this tool from siblings like list_services. An agent can still infer that it lists sellers and their skills.

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, no mention of alternatives, and no exclusions. Sibling tools such as list_services and get_reputation exist, but the description does not help route the agent among 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. Beyond that, the description discloses nothing behavioral — no mention of scope, filtering, pagination, or freshness of the catalog. The one added sentence ('Sellers may also quote on any other task type') is a business rule that does not help an agent predict the tool's 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 short sentences, so nothing is bloated, but the first sentence is a comma-spliced fragment whose subject and verb are unclear, and the second sentence is arguably off-topic. Conciseness is fine; clarity per sentence is not.

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 an output schema present and zero parameters, the description need not explain return values, and it broadly characterizes the catalog contents. However, it never confirms this is a read/list operation or what the catalog covers, leaving an agent to guess the operation's nature from the name 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to clarify and no risk of misuse through argument semantics. It does not need to compensate for any 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 verb 'Catalog' is ambiguous — it reads as either 'produce a listing of' or 'register into a catalog', so the actual operation is left to inference from the name and title. The description does specify the subject matter (task types, parameters, pricing, acceptance criteria), which is useful content, but it never clearly states the tool returns this information to the caller. No sibling differentiation against list_sellers or get_task.

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 alternatives such as list_sellers or get_task, nor any precondition for invoking it. The trailing sentence about sellers quoting other task types is a marketplace policy remark, not usage guidance.

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

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

The readOnlyHint=false annotation already signals a non-read operation. The description adds useful domain context: only crypto and free jobs are supported now, and requested options may be added later. However, it does not clarify what the call actually changes, whether it persists a preference, or what side effects occur.

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 support constraint before asking for a preference. The final sentence is slightly conversational, but overall it avoids waste and is easy to scan.

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

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

An output schema exists and annotations cover the write/read profile, so return values need not be explained. The description still leaves the core action ambiguous and provides no usage routing, making it adequate but incomplete for a tool with many siblings.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description indirectly refers to 'preferred' but adds no syntax, format, or meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description conveys that the tool concerns payment preferences and states current support limits, but it never names a clear action verb like 'submit' or 'record'. It asks a question rather than describing what the tool does, and it does not differentiate itself from siblings such as submit_feedback or answer_survey.

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 tool versus alternatives. The phrase 'Tell us' implies a preference should be submitted, but there are no conditions, prerequisites, or named sibling tools to route the agent correctly.

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 provide only readOnlyHint=false, so the description carries most of the burden. It adds the meaningful eligibility constraint (who may propose, on which task states) beyond the annotation, but says nothing about the proposal lifecycle, reversibility, or what happens on acceptance/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?

Two tightly packed sentences: the mechanism first, then the eligibility rule. No filler, and the operative constraint is front-loaded.

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?

An output schema exists, so return values need no explanation, and the schema fully covers parameters. The description covers purpose and eligibility; the only gap is the post-proposal flow, which is arguably handled by respond_settlement.

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

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

Schema description coverage is 100%, so the schema already documents id, note, refund_pct, and buyer_token in detail. The description's restatement of the refund_pct split is redundant with the schema field text, adding no syntax or format information beyond it. Baseline 3 is appropriate.

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

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

States a specific action (offer a partial refund) with the exact split mechanics: refund_pct goes to the buyer, the seller keeps the remainder. It does not name the sibling respond_settlement, so the distinction from the counterpart tool must be inferred, but the action itself 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?

Explicitly states who may call it and in what situation: the buyer on a delivered task, or either side on a disputed one. This is real eligibility guidance, though it never names respond_settlement as the alternative path once a proposal exists.

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, openWorld, non-destructive), and the description adds substantial behavioral context on top: pricing (US$0.001 per call), a free-tier limit (3 calls/day), no account requirement, and hard input (4,000 chars) / output (256 tokens) bounds. These cost and quota details are exactly the kind of context 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?

Two dense sentences with zero waste: purpose and use cases first, then constraints, cost, and quota. Everything is front-loaded and nothing is repeated.

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?

An output schema exists, so return values need not be explained. The description covers model identity, limits, pricing, and account requirements – everything an agent needs to decide and invoke 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 coverage is 100%, so both parameters are already documented. The description's 'up to 4,000 characters in and 256 tokens out' essentially restates the schema's prompt and max_tokens constraints rather than adding new meaning, so the baseline 3 applies.

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

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

States a specific verb+resource ('fast, low-cost AI reply for short jobs') and enumerates concrete use cases (classify, extract a field, rewrite a line, answer a quick question). It names the underlying model (Llama 3.1 8B), which clearly distinguishes it from siblings like talk or web_search.

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 examples give a clear sense of when this tool is appropriate – short, bounded jobs rather than open-ended chat. It never names an explicit alternative tool (e.g. talk) or states when NOT to use it, so it stops short of full 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?

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial behavior beyond them: parallel fetching, per-page failure explanations, robots.txt compliance, and the cost/rate model (US$0.01 per call, 3 free calls/day). Cost and quota are exactly the operational facts an agent needs before invoking a paid, metered 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?

Effectively one dense sentence with semicolons that front-loads the core capability, batch size, and return shape before moving to cost and pairing advice. Every clause carries information, though the packed semicolon chain is slightly harder to scan than distinct sentences.

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 an output schema already exists, the description need not explain return values, yet it does name the returned fields. Combined with batch limits, error reporting, robots.txt, and pricing, an agent has everything required to call this correctly and budget for it.

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

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

Schema description coverage is 100% – both `urls` (1-10 https URLs) and `max_chars` (default 6000) are documented in the schema. The description reinforces the 1-10 URL bound but adds no new semantics such as URL format rules or truncation behavior, so the baseline of 3 applies.

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

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

States a specific verb (read/fetch) and resource (web pages) with the shape of the output (title, description, main text, links) and the batch limit. It is immediately distinguishable from the sibling web_search, which returns URLs rather than page content.

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 says the tool pairs with web search and that callers should pass the URLs it returned, which is a concrete when-to-use rule tied to a named sibling. It stops short of stating exclusions (e.g. when to prefer web_search or a browser tool instead), so it is clear context but not a full decision rule.

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 readOnlyHint=false, so the description carries most of the burden and does well: it discloses the pull-mode fallback when no server is supplied and warns that member_secret is returned and shown once, which is critical since the value cannot be retrieved later. It omits idempotency/re-registration behavior and any auth or rate-limit 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?

Three short sentences, front-loaded with what the tool does, then requirements, then the mode switch, then the return caveat. Every sentence carries information an agent needs; 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 mutating registration call with an output schema already present, the description covers creation semantics, required fields, mode selection, and the one-time secret. It is nearly complete, with only re-registration/duplicate handling and confirmation of what else is returned left unstated.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning by clarifying the minimal required set and by explaining the behavioral consequence of omitting mcp_url rather than just its type. That extra signal lifts it slightly above the schema-only baseline.

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

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

States a specific verb (join/register) plus the resource and the choice space (seller, buyer, or both), which maps exactly to the roles parameter. It is clearly distinguishable from the similarly named sibling register_interest, which is a lighter-weight expression of interest rather than account creation.

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 concrete operating guidance: only roles and name are required, and omitting mcp_url switches the agent into pull mode with a polling explanation. It does not, however, name alternatives (e.g. register_interest) or state when not to register, so it falls short of full 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?

Annotations only declare readOnlyHint=false, so the description carries the burden of behavioral disclosure. It does not say what registering actually does (stores demand? notifies sellers? creates a listing?), whether an account is required, or whether the submission is reversible or visible to others.

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

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

A single front-loaded sentence with no filler, and the essential qualifier ('nobody offers yet') comes first. It is efficient, though arguably terse enough to leave the tool's mechanics unexplained.

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?

An output schema exists, so return values need not be described, and all three parameters are covered. However, for a mutation (readOnlyHint=false) with no further annotation detail, the description omits the post-call behavior an agent would need to set 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 description coverage is 100%, with 'type', 'note', and 'budget_usd' each documented, so the schema already does the work. The description adds no format, example, or constraint beyond what the schema states, so the baseline 3 is appropriate.

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

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

The description states a specific action (register/tell us) applied to a specific resource (a task type nobody offers yet), which is clearer than the bare name. It implies a demand-signal tool distinct from create_task, but never names that sibling, so the distinction must be inferred.

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 'that nobody offers yet' implicitly defines the condition for use, but the description never states when not to use it or points to alternatives such as create_task or request_connector. Usage must be inferred from the qualifier.

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/open-world/non-idempotent profile, but the description adds substantive context beyond them: the request is free, gets screened, and carries a US$10 setup fee plus per-call pricing if accepted. That cost and eligibility disclosure is exactly the kind of value structured fields lack. It does not describe turnaround time or the rejection flow.

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 key hook ('Free to ask') front-loaded, then the screening and cost model. No sentence is wasted and nothing is buried.

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 request-submission tool with an output schema (so return values needn't be explained) and full schema coverage, the description is largely complete: purpose, cost, and eligibility are all present. Minor gaps remain around what happens after acceptance or expected timing.

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 all five parameters are documented there, so the schema carries the load. The description does not add syntax, format, or meaning beyond what the schema already states, making the baseline 3 appropriate.

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

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

States a specific verb and resource: 'request that one public website or registry be turned into a clean JSON endpoint you can call.' An agent immediately understands this creates an API-ification request, distinct from sibling read/search tools like read_pages or web_search.

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?

'Free to ask' sets the entry cost, and the screening criteria (no logins, CAPTCHAs or personal data; robots.txt respected) effectively define when a request qualifies and when it won't. It gives clear qualifying context but does not explicitly name alternative tools (e.g., read_pages, find_paid_tools) for cases that don't qualify.

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

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

The readOnlyHint=false annotation already signals a write/mutating action, so the bar is lower. The description adds useful context that the redo is free and pre-guaranteed so no dispute is required, but says nothing about what happens on success, whether it is reversible, or any auth/permission nuance.

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 enabling condition ('free redo they guaranteed in their offer') front-loaded and the routing hint ('no dispute needed') trailing. Nothing 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?

An output schema exists, so return values need not be explained, and the schema fully documents the parameters. For a simple single-step request action the description is adequate, though slightly more on outcome/behavior after the request would fully close 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?

Schema description coverage is 100%, so all three parameters (id, reason, buyer_token) are already documented in the schema, including the buyer_token auth note. The description adds no further parameter meaning, so baseline 3 applies.

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

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

States a specific verb (ask/request) and resource (a free redo the seller guaranteed in their offer). It draws a meaningful boundary against the dispute path by saying 'no dispute needed', which lets an agent separate this from dispute_task, though it does not name that sibling explicitly.

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

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

Gives a clear precondition (the seller guaranteed a free redo in their offer) and a contrast condition (no dispute needed), so the agent knows this is the lighter-weight path versus disputing. It stops short of an explicit when-not or naming the alternative tool.

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 provide readOnlyHint=false, so the description carries the burden for a high-stakes mutation. It never says what accepting triggers (escrow release, task completion) or what declining does (return to dispute/negotiation), nor whether the action is reversible. The buyer_token note about not needing it as the posting buyer is the only behavioral hint, and that lives in 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?

A single front-loaded sentence with the action and the decision object, zero filler. Nothing is padded or repeated from the schema.

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

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

An output schema exists so return values need no explanation, and parameters are fully documented. However, for a financially consequential accept/decline decision, the description omits any consequence or workflow context, leaving an agent unsure what accepting commits it to.

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 all four parameters are documented in the schema itself, including the buyer_token exception. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (accept/decline) and a specific resource (the other side's settlement offer). This clearly separates it from propose_settlement, which initiates rather than answers an offer, though the description never names that sibling explicitly.

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

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

The phrase 'the other side's settlement offer' implies usage (responding to a received offer, presumably after get_task/propose_settlement), but no explicit when/when-not or alternative path (e.g. countering via propose_settlement) is given. 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 only declare readOnlyHint=false, so the description carries most of the burden and delivers real behavioral value: outbound message content is filtered and contact details are stripped to keep deals on-platform. It still omits delivery/permission/state prerequisites, but the content-moderation disclosure is meaningful.

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

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

Two sentences, zero filler, with the addressee and purpose front-loaded before the constraint. Nothing could be cut without losing information.

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

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

An output schema exists, so return values need no explanation, and the schema covers all four parameters. The description covers purpose, recipient, and content restriction; only state/permission preconditions for sending are absent.

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

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

Schema description coverage is 100% and every parameter (id, body, seller_id, buyer_token) is already documented there, so the baseline is 3. The description adds only a loose echo of 'contact details are removed' for body 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?

The description names a specific verb+resource ('Message the other side of a task') and adds two concrete use cases (clarify the brief, ask questions). It is clearly distinguishable from list_messages and answer_clarifications, though it never names those siblings 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?

It implies when to use the tool via parenthetical examples, but gives no explicit when-not guidance or alternatives (e.g. answer_clarifications vs. send_message, or when to reply vs. open a new thread). 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.

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

readOnlyHint=false already signals this is a write/mutation, so the annotation carries the safety profile. The description adds a genuine auth detail ('No account needed'), which is helpful behavioral context, but it says nothing about rate limits, what happens after submission, or any side 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, front-loaded sentences with zero filler; the core purpose and the acceptance scope are stated immediately.

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?

An output schema exists, so return values need not be explained, and all four parameters are fully documented in the schema. The description covers purpose, accepted categories, and the no-account requirement, leaving only the sibling distinction 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 100% and each parameter (rating, context, message, category) is already documented in the schema, so the description need not carry param detail. The enumerated feedback types loosely mirror the category enum but add no syntax or format meaning beyond the schema.

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

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

States a specific verb ('Send feedback') and resource ('to the ManyLives operator'), and enumerates the kinds of feedback accepted (bugs, ideas, praise, complaints, questions) which map directly to the category enum. It is clearly distinct from submit_review/submit_statement, though it never names those siblings explicitly.

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

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

The description implies when to use it (whenever you have feedback for the operator) and adds a useful condition ('No account needed'), but it never states when to prefer it over siblings like submit_review or submit_statement. Usage is inferable 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?

The readOnlyHint=false annotation already signals a write operation, and the description adds useful context about who reviews whom. However, it does not disclose mutability of a submitted review, deadlines, or consequences of reviewing, which are the behavioral facts an agent actually needs for a write 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?

A single efficient sentence that front-loads the core action and then clarifies the two-sided nature. No wasted clauses, though it packs two ideas (task state and role asymmetry) into one line.

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 an output schema present, return values need not be explained, and the schema fully documents all seven parameters including the buyer_token fallback. The description is adequate for a review-submission tool; only edge-case behavior (editing, deadlines) is 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 100%, so the baseline is 3. The description's mapping of quality/accuracy/timeliness to the buyer role largely restates what the schema already says ('Optional (buyers)'), adding little beyond the structured field descriptions.

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

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

States a specific action (submit a review) on a specific resource (the counterparty of a finished task) and spells out the two sides: buyers rate sellers, sellers rate buyers. That asymmetry meaningfully separates it from siblings like submit_feedback, though no sibling is named explicitly.

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

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

The phrase 'of a finished task' implies the prerequisite (task must be complete) and hints at context, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as submit_feedback or dispute_task when the outcome is contested.

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 supply readOnlyHint=false (a write operation). The description adds no behavioral context: no mention of auth requirements (buyer_token), whether the statement is binding/final, whether it can be edited, or consequences for the mediation. For a write tool this leaves the burden unmet.

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, front-loaded and free of waste. However, the brevity comes at the cost of substance rather than being efficiently informative.

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?

An output schema exists so return values need not be explained. But for a dispute/mediation write action with auth nuance (buyer_token) and a refund proposal field, the description provides too little context for an agent to act confidently.

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

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

Schema description coverage is 100%, so all four parameters (statement, buyer_token, mediation_id, proposed_refund_pct) are already documented in the schema. The description adds nothing beyond that, so baseline 3 is appropriate.

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

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

The description 'Give your side to the Mediator' essentially restates the name/title (submit_statement) in evocative terms without naming the operation clearly. It implies a mediation context but does not distinguish this tool from siblings like propose_settlement, respond_settlement, or escalate_dispute.

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. It does not say when an agent should submit a statement versus proposing or responding to a settlement, nor does it mention prerequisites such as needing an active mediation or buyer_token.

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 readOnlyHint=false, the mutation nature is declared, and the description adds real context: the Brain 'screens and lists the job, gathers quotes, recommends one and assigns it when you agree', plus an auth detail (token needed only for non-members). This goes well beyond the annotation, though it omits state/reversibility of the assigned job.

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?

Purpose is front-loaded in the first clause, and the sentence efficiently covers the flow and continuation mechanics. It is slightly dense but every clause carries information, with no wasted 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?

An output schema exists, so return values need not be explained, and the description covers the interaction model and auth needs adequately. For a conversational entry point to a large sibling set, it is nearly complete, only missing explicit sibling routing.

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

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

Schema coverage is 100%, so the schema already documents message, conversation_id, and token. The description reinforces usage ('Pass conversation_id ... to continue') and clarifies the token is only for non-members, but adds little beyond what the schema properties already state.

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 conversational action ('Talk to the ManyLives Brain in plain words') and sketches the orchestration flow (screens, lists the job, gathers quotes, recommends, assigns). It is clearly distinct from structured siblings like create_task or get_quote, though it never names them explicitly to sharpen the contrast.

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 when to use it ('say what you need, no task type or fields needed') and how to continue a conversation, which suggests it is the free-form alternative to structured tools. But it never explicitly states when NOT to use it or names an alternative tool, leaving the routing to inference.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful non-annotation context: per-call pricing (US$0.02), a daily free-call cap, and the notable guarantee that every returned URL is verified against actual search results with the answer drawn only from those pages.

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

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

Front-loaded with 'Use when', but the phrasing is run-on and redundant ('find pages on the live web: search the live web'), and pricing/limit details are appended in terse fragments. Content mostly earns its place but the structure is cluttered with 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 an output schema present, return values need not be re-explained, yet the description usefully covers the result shape, the answer behavior for questions, cost/limits, and the site filter. For a read-only search tool this is essentially complete, with only alternative-tool routing missing.

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

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

Schema coverage is 100%, so q, max, and site are already documented in the schema. The description only echoes the optional site filter and adds no syntax, format, or default details beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb and resource ('search the live web') and describes the return shape (title, URL, snippet, best-first, plus a short answer for question queries). This is enough to distinguish it from read_pages, but the description never explicitly contrasts the two, so sibling 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?

'Use when you need to find pages on the live web' gives a clear trigger context. However, no when-not conditions or named alternatives (e.g., read_pages for already-known URLs, quick_ai) are provided, leaving the agent to figure out routing on its own.

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