Taste

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

With no annotations provided, the description must fully disclose behavioral traits. It does disclose return values ('approve/reject verdict, reasoning, deliverable quality rating, contract alignment') and neutrality, but it omits operational implications such as cost, latency, or whether the ruling is binding. Thus it provides moderate transparency.

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

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

The description is three sentences with front-loaded purpose, no redundant phrases, and each sentence serves a distinct function: what it does, when to call, and what it returns.

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

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

The description is adequate for a complex tool with 8 parameters and an output schema. It covers the decision context and outcome, while the schema handles parameter details. It could mention any preconditions or asynchronicity, but overall it is sufficiently 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 the baseline is 3. The description's narrative mentions 'deliverable' and 'contract' but does not add meaning beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool's function: 'Get an impartial human arbiter to decide whether a deliverable meets an agreed contract, or to settle disagreements between agents.' This specific verb and resource distinguish it from sibling tools like ask_a_human or consult_domain_expert by emphasizing impartial arbitration with a ruling outcome.

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 explicitly tells the agent when to invoke: 'Call when automated evaluation cannot determine quality, when two parties dispute fulfillment, or when subjective judgment is needed for contract assessment.' This is clear context, though it does not name alternatives or exclusion criteria.

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

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

With no annotations provided, the description carries full burden and does well: it discloses the human is 'vetted', typical response time ('usually within 30 minutes'), scope boundaries ('No scoring, no verdict, no certificate'), and return format ('Returns the human's answer, plus an optional note on who answered'). This adds meaningful behavioral context beyond the schema.

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

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

The description is three sentences, front-loaded with the core action, followed by usage guidance and exclusions/return info. Every sentence adds value with no redundancy or fluff.

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

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

Given the tool's simplicity (one parameter, output schema exists) and the annotations-free context, the description covers purpose, usage, turnaround, exclusions, and return format. It lacks minor details like cost or prerequisites, but these are not critical for a quick Q&A tool, leaving it nearly 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 the baseline is 3. The description adds 'plain-text' and 'vetted human' context that aligns with the schema's 'plain-text question' description, but does not add new semantic constraints beyond what the schema already provides. Thus, it remains at the 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?

The description clearly states the tool's function: 'Ask a vetted human a plain-text question and get a plain-text answer back.' It uses a specific verb ('ask') and resource ('vetted human'), and distinguishes itself from sibling tools by explicitly noting what it does not do ('No scoring, no verdict, no certificate').

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 explicit usage guidance: 'Call when you need a quick human take, gut check, or local/lived-experience answer a model cannot reliably give.' It also provides exclusion criteria ('No scoring, no verdict, no certificate'), making it clear when not to use this tool, even without naming specific 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?

With no annotations provided, the description carries the full burden. It discloses return values ('Returns answer, anonymised role, confidence, first-hand flag'), the certification process ('Approved answers get an on-chain Taste cert'), and timing/domain availability ('Listed domains... Other domains: best-effort 24-48h'). This is substantial behavioral context, though it omits details like authentication or cost.

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 concise and front-loaded with the primary purpose. The domain list is necessary and efficiently presented. Every sentence contributes useful information without redundancy.

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

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

Given the tool's complexity (7 params, output schema present), the description covers core behavior, return fields, domain constraints, and follow-up rules. It does not explicitly address result retrieval or differentiate from similar siblings, but the output schema and existing context signals mitigate those gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying `domain` semantics (listed vs. best-effort domains) and `parentSessionId` follow-up cap, which are practical nuances not fully captured in the field descriptions alone.

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

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

The description opens with a specific verb and resource: 'A vetted human in a named domain answers your question with first-hand knowledge.' This clearly states the tool's function and distinguishes it from sibling tools like ask_a_human by emphasizing domain-specific, vetted experts and listing concrete domains.

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

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

The description gives clear usage instructions: 'Pass `domain` to match an expert' and 'Pass `parentSessionId` for follow-ups (cap 3).' It also explains behavior for listed vs. other domains ('Other domains: best-effort 24-48h'), which helps decide when to use the tool. However, it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It adds meaningful context about async completion ('once the expert ... completes the work') and the full structured deliverable, but does not disclose what happens if the work is not yet complete (e.g., status response), error behavior, or any rate limits. This is adequate but not rich.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no redundant phrasing. Every clause adds information: purpose, return payload, completion condition, and accepted identifiers.

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

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

For a simple two-parameter status tool with an output schema, the description is largely complete: it covers the purpose, identifier types, and return deliverable. It does not explicitly state the behavior when the request is still in progress, which is a minor gap, but the output schema presumably defines the response structure. Overall, the description is sufficient.

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

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

The schema already covers 100% of the parameter descriptions, including the 'always returns the latest revision' behavior for referenceCode. The tool description adds the 'or' relationship between the two identifiers, but this is marginal value beyond the schema's per-parameter explanations. 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 uses a specific verb ('Check the status') and resource ('previously submitted request'), clearly distinguishing it as the retrieval counterpart to ordering/revision tools. It names the two accepted identifier types (sessionId or order reference code), making the tool's scope unmistakable.

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

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

The description implies the tool should be used after a request has been submitted, and it states both supported identifier formats. It does not explicitly name alternative tools or provide exclusions, but among siblings this is the only status-checking tool, so the context is clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds valuable context by noting the tool is free, exposes no per-expert PII, and provides real-time counts and wait estimates. It does not explicitly state read-only behavior, but 'Returns' and the absence of any side effects imply it, so a small gap remains.

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

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

The description is three sentences, front-loaded with the main output, then usage guidance, then a privacy note. Every sentence adds value with no redundancy or fluff.

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

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

The tool is simple: no parameters and an output schema exists. The description fully covers what is returned (taglines, seat count, wait), the nature of the data (pseudonymous, no PII), and the cost (free). There are no gaps in understanding when or why to use 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 the baseline score is 4. There is no parameter information to add, and the description appropriately focuses on outputs and usage. The schema is empty, so nothing is undocumented.

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

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

The description clearly states a specific verb ('Returns') and resource ('expert taglines') along with additional data (online seat count and estimated wait). It distinguishes itself from sibling paid tools by framing itself as a cheap pre-flight check, making the purpose 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?

It explicitly says 'Use this as a cheap pre-flight check before calling a paid tool,' which specifies when to use it and implies not to call paid tools first. This is clear usage guidance, even though specific sibling names are not mentioned.

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

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

With no annotations, the description carries the full burden. It conveys a read-only listing operation and adds the detail that it is 'Free,' which is a useful cost-related behavior. It also specifies the return content (pricing, tool names, certificate status), but does not mention potential side effects like pagination, leaving some gaps.

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

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

The description is a single, well-structured sentence that front-loads the verb and object, then efficiently lists the key included attributes and the cost note. Every phrase earns its place without unnecessary verbosity.

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

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

For a simple listing tool with no parameters and an existing output schema, the description fully explains the tool's purpose, the data returned, and the free cost. It leaves no essential gaps for agents to select and invoke it correctly.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage. The description correctly adds no parameter details, and the baseline for zero-parameter tools is 4, which is appropriate here.

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

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

The description clearly states the tool's function: 'List all available human expert evaluation offerings' with specific attributes (pricing, tool names, certificate issuance). This distinguishes it from sibling tools like list_expert_profiles, which focuses on profiles rather than offerings.

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 the tool is for obtaining an overview of offerings but does not explicitly state when to prefer it over alternatives or when not to use it. It lacks differentiation from similar list-type siblings, so usage guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly conveys that the session is asynchronous (returns IDs immediately, results later), that a free revision is included, and that the deliverable can be retrieved via a wallet address. While it doesn't mention cost or failure modes, it provides substantial behavioral context beyond the bare function.

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 efficient and well-structured. It opens with the core action, explains the key returns, and then provides follow-on guidance for polling and revisions. Every sentence adds value without unnecessary fluff or repetition.

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

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

Given the complexity of an ordering tool for a human expert session, the description covers the key workflow: initiation, immediate confirmation, asynchronous completion, and revision. The presence of an output schema likely covers return detail, so the description doesn't need to. Minor gaps like pricing or cancellation are not addressed, but the overall context is solid.

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 every parameter already has a meaningful description in the input schema. The tool description itself adds little extra semantic value for parameters (e.g., it doesn't elaborate on mediaUrls or requestedDeliverables beyond what the schema states). This aligns with the baseline of 3 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 clearly states the tool's function with a specific verb ('Convene a think tank'), describes the resource (a curated team of human experts), and specifies the 30-minute working session scope. It also distinguishes this from the 60-minute sibling tool by explicitly mentioning '30-minute working session'.

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

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

The description provides clear usage context by explaining the immediate returns (sessionId + referenceCode), how to poll for results using get_result, and how to request revisions using request_think_tank_revision. However, it does not explicitly compare with the 60-minute variant or state when one should choose 30 over 60, so it stops short of explicit exclusions.

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

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

With no annotations provided, the description carries full disclosure burden. It reveals key behaviors: immediate return of sessionId and referenceCode, asynchronous completion requiring polling, and inclusion of 2 free revision turns. It also implies human involvement and a 60-minute working session, setting expectations around latency. It does not mention costs or failure handling, but the critical behavioral traits are well covered.

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

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

The description is three well-structured sentences: purpose and deliverable, immediate return and polling instruction, and revision policy. Every sentence adds actionable information with no repetition or filler. Key details are front-loaded, making it easy for an agent to quickly grasp the tool's behavior.

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

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

For a complex asynchronous tool involving human experts, the description covers the essential workflow: what the session does, what is returned immediately, how to retrieve results, and how to request revisions. It correctly names relevant sibling tools (get_result, request_think_tank_revision) and gives enough context for an agent to select and invoke the tool without seeing the output schema in the description. The external output schema exists to handle return structure, so the description is sufficiently 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?

The input schema already provides thorough descriptions for all four parameters (100% coverage), so the baseline is 3. The tool description itself does not add parameter-specific meaning beyond what the schema states, though it gives high-level context that the inputs will feed a human expert session. Schema is doing the heavy lifting, so no additional credit is warranted.

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

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

The description clearly states the tool's function: convening a 60-minute think tank session with vetted human experts and returning synthesized directions, ideas, and next steps. It distinguishes from sibling order_think_tank_session_30 by explicitly specifying the 60-minute duration, and from other consultation tools by describing the curated team and structured deliverable format.

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

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

The description provides explicit workflow guidance: poll get_result with the returned sessionId or referenceCode, and use request_think_tank_revision for the 2 included revisions. It does not directly compare this tool with the 30-minute variant or other expert services, but the asynchronous workflow and revision path are clearly laid out, giving the agent actionable next steps.

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

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

No annotations are provided, so the description carries the full burden. It discloses the nature of the action (getting a real human to rate), the output (overall rating, criteria scores, qualitative feedback, comparison notes), and the timing (before distribution). However, it does not mention potential latency, cost, or any asynchronous behavior that might be expected from involving a human, which would be valuable behavioral 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?

The description is two sentences, front-loaded with the action and purpose. Every sentence adds value: the first states what the tool does, the second specifies when to call it and what it returns. No unnecessary information or repetition.

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

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

The description covers the tool's purpose, usage timing, and return values. An output schema is present, so the description need not elaborate on return structure. The only minor gap is not addressing practical constraints of using a real human (e.g., latency), but overall the description is complete for a tool of this complexity.

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

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

The input schema provides 100% description coverage for all parameters, so the baseline is 3. The description reinforces the importance of targetDemographic ('matching your target demographic') and content ('your content'), but does not add further parameter-level detail beyond what the schema already provides.

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

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

The description uses a specific verb ('Get a real human... to rate and react') and identifies the resource (a representative audience member matching a target demographic). It clearly distinguishes itself from sibling tools by emphasizing audience reaction prediction before A/B tests, ad spend, or distribution decisions, which is unique among the listed tools.

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

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

The description explicitly states when to use the tool: 'Call before A/B test commits, before ad spend, or before distribution decisions.' This provides clear usage context, but it does not mention when not to use it or explicitly name alternative tools, so it stops short of 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?

With no annotations, the description carries full burden. It discloses the full user flow (user opens URL, connects wallet, pays $15 USDC), states the session is created, names return values (payment URL and price), and clarifies the tool call itself is free. This is rich behavioral 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?

Four sentences, around 85 words, front-loaded with purpose. The details about payment and user flow are relevant, though 'Free' at the end could be more integrated. No fluff, each sentence earns its place.

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

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

Given an output schema exists, the description need not explain return format. It fully covers purpose, use case, user interaction, pricing, and result. It complements the schema by explaining the browser-based workflow and the distinction from sibling tools, making it complete for a tool of this complexity.

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 baseline is 3. The description adds meaningful semantics by explaining the URL is pre-filled with the passed brief, and clarifies the pricing context ($15) which is not in the schema. This elevates it to 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 clearly states the tool gets a humantaste.app URL for placing a consult_domain_expert order, with specific details about wallet connection and payment. It distinguishes itself from direct invocation tools by emphasizing the browser-based flow for clients without wallet integration.

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 'Use this when your MCP client has no wallet integration (Claude Desktop, generic chat UIs)', providing clear when-to-use guidance and an implicit alternative (consult_domain_expert sibling).

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the involvement of a vetted human expert, the specific output (verdict, flagged issues, fix suggestions), and the on-chain certificate. It does not mention latency, cost, or asynchronous behavior, but it is quite transparent about the process and results.

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 four sentences, front-loaded with the purpose, followed by usage, output, and certification. Each sentence earns its place with no redundancy or filler. It is well-structured and concise.

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

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

Given the tool's complexity, the description covers the essential aspects: what it does, when to use it, and what it returns. The output schema exists, so return values are already structured. It lacks information on turnaround time or costs, but for a review tool, it is reasonably 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?

The input schema already provides 100% coverage for both parameters, so the baseline is 3. The description does not add meaningful detail beyond the schema; it mentions 'AI-generated content' but that is not parameter-specific. No additional syntax or format guidance is given.

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

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

The description clearly states the tool's purpose: getting a vetted human expert to review AI-generated content for specific criteria (cultural sensitivity, brand safety, etc.) before publishing. It distinguishes itself from sibling tools like review_content or review_plan by emphasizing the human expert and the prepublish 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 description explicitly says when to use the tool: 'Call before social posts, marketing campaigns, content distribution, or anywhere public-facing.' This provides clear context but does not mention specific alternatives or exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that the tool pauses the workflow, returns 'approved/denied + reasoning,' and mentions optional on-chain enforcement. This gives a clear behavioral contract without requiring the agent to infer 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?

The description is two sentences that front-load the purpose and usage scenarios, then add return behavior and enforcement details. Every sentence earns its place, with no wasted words or redundancy.

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

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

For a tool with 4 parameters, full schema coverage, and an output schema, the description adequately covers when to use it, what it returns, and optional enforcement features. It does not need to explain return structure in detail because the output schema exists, and the schema covers timeout behavior.

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 adds high-level context (e.g., examples of high-stakes actions and the return format) but does not provide detailed semantics for individual parameters beyond what the schema already offers.

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

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

The description clearly states the tool's purpose: 'Pause your workflow for explicit human approval before executing a high-stakes action.' It uses a specific verb and resource, and effectively distinguishes itself from sibling tools like ask_a_human by focusing on approval for irreversible actions.

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

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

The description provides explicit guidance on when to call the tool: 'Call before any irreversible action — large spend, on-chain transaction, public content publish, customer-facing decision.' While it does not list exclusions or name alternatives, the context makes it clear this is for high-stakes approval scenarios.

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

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

With no annotations provided, the description carries the full burden of disclosure. It explains the free/no-payment aspect, that consuming the revision turn is included with the order, the involvement of the same illustrator, and the need to poll get_result for the result. It does not cover failure modes or state validation beyond 'completed illustration order,' but this is fairly thorough for a simple revision 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?

The description is two sentences, front-loaded with the primary purpose ('Spend a free revision turn'), then provides the process and retrieval instructions. The repeated mention of 'free' is slightly redundant but ensures clarity. Every sentence contributes useful information, and no unnecessary detail is included.

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

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

Given the tool's simplicity and the presence of an output schema, the description adequately covers the inputs, the action, the cost (free), and how to retrieve the result via get_result. It does not mention edge cases like invalid reference codes or what happens if the order is not completed, but these are not critical for a basic revision tool. Overall, it provides enough context for an agent to use the tool correctly.

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

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

The schema provides 100% coverage for both parameters: referenceCode is described as the TASTE-... reference code, and adjustments as what the illustrator should adjust. The description essentially restates these concepts ('Provide the reference code' and 'describe the adjustments you want') without adding new meaning, so it meets the baseline for schema-covered 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?

The description clearly states the action: 'Spend a free revision turn on a completed illustration order.' It identifies the resource (illustration order) and distinguishes it from sibling tools like request_think_tank_revision. The outcome is also specified: the same illustrator revisits the brief and returns an updated deliverable.

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

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

The description provides clear context: use on completed illustration orders with a free included turn. It also instructs to poll get_result with the reference code to retrieve the updated deliverable, which guides the agent to the follow-up tool. However, it does not explicitly name alternatives or exclusions, though the illustration-specific wording and sibling tool names imply differentiation.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the operation is free, that the same team revisits the brief, and that the deliverable is retrieved via polling 'get_result' rather than returning synchronously. This adds meaningful context about the async flow and cost.

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 four sentences, each earning its place: the action, the inputs, the workflow, and the cost. It is front-loaded with the primary verb and resource, and there is no redundant or extraneous wording.

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

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

The tool is simple with two parameters and an output schema present. The description covers purpose, when to use, the retrieval mechanism, and the free nature. It is sufficiently complete for an agent to understand and invoke the tool, though it could explicitly mention any revision limits.

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

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

The schema descriptions already cover both parameters fully: referenceCode includes the TASTE-... format and origin, and adjustments explains what to provide. The description repeats these requirements without adding new semantic details, so it does not exceed the baseline expected given 100% schema coverage.

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

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

The description clearly states the specific action: spend a free revision turn on a completed think tank order. It distinguishes from sibling tools like 'request_illustration_revision' (for illustrations) and 'order_think_tank_session_30/60' (for new orders) by explicitly targeting think tank revisions and noting the same team revisits the brief.

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 specifies when to use the tool: on a completed order, with the revision turn included. It also directs the user to poll 'get_result' for retrieval, indicating the workflow. While it does not explicitly list alternatives or exclusions, the context makes it clear this is for revisions rather than new orders.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a vetted human engineer performs the review, what kinds of issues are covered, and the exact output (verdict, correctness score, security findings, architecture notes, suggested changes). It also mentions the on-chain certificate for approved code, which is a notable behavioral outcome. It does not cover cost or turnaround time, but the core behavior is transparent.

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 well-structured and front-loaded, with purpose first, then usage context, then parameters, then outputs. It is denser than minimal but every sentence carries useful information, especially since there is no output schema content shown. It avoids repetition of schema field names and stays focused.

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

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

Given the tool's complexity and the lack of annotations, the description is quite complete: it explains what to pass, when to use it, and what the return value contains. It does not mention potential costs, expected turnaround time, or limitations (e.g., language support), which would be useful for a human-in-the-loop service, but it covers the essential decision-making and invocation context.

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

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

The input schema already provides 100% coverage of all parameters with descriptions, so the baseline is 3. The description adds a small reiteration that code can be inline or a URL and that intent should describe behavior, but it does not meaningfully expand beyond the schema. Thus no extra credit beyond the schema's completeness.

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

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

The description clearly identifies the tool as a human code review service, specifying the resource (code) and the focus areas (correctness, security, structural soundness) beyond mere style. It distinguishes from sibling tools like review_content and review_plan by explicitly targeting code, architecture, and design decisions.

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

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

The description gives clear guidance on when to call the tool: 'before you treat code as done,' particularly for payment flows, auth, data handling, or logic where subtle bugs are costly. It does not explicitly name alternative tools or when not to use it, but the context is strong enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the burden of disclosing behavior. It states that the tool returns a verdict, issues found, and suggested improvements, and mentions the on-chain certificate for approved outputs. It does not disclose potential costs, delays, or failure modes, but for a review tool it provides reasonable transparency about what the user gets.

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

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

The description is three sentences, tightly packed with relevant information: what it does, when to use it, and what it returns. No filler or repetition. Each sentence contributes meaning, making it an ideal length for a tool description.

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

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

Given the complexity of a human review tool and the presence of an output schema, the description covers the essential aspects: purpose, usage timing, and return value. It could benefit from noting that human review may introduce latency or require payment, but the description is otherwise complete for an agent to decide when to invoke 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 coverage is 100%, so the baseline is 3. The description adds some context by clarifying what the reviewer evaluates (hallucinations, factual errors, weak parts, domain mistakes) and that content can be text or a URL. However, the schema already defines the parameters well, and the description does not add significant syntax or format details beyond that.

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

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

The description clearly states the tool reviews AI-generated content across multiple media types, with a specific verb ('review') and resource ('AI-generated content'). It distinguishes itself from sibling tools like review_code and review_plan by focusing on content (text, images, videos, etc.) and by mentioning the on-chain certificate. This provides strong differentiation.

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

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

The description explicitly states when to call the tool: 'before publishing, before forwarding to another agent, or before acting on the content.' This gives clear context for usage. However, it does not mention when NOT to use it or explicitly name alternative tools, so it falls short of a 5.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It openly states the return format (verdict, risks, missing considerations, sequencing notes) and a notable post-condition ('Approved plans receive a Taste content certificate on-chain'). It doesn't mention latency or cost, but the main side effect is disclosed.

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

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

Five sentences, each earning its place: purpose, timing, inputs, outputs, and post-condition. The information is front-loaded and there is no fluff.

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

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

The tool is simple with three clearly described parameters and an output schema. The description fully covers when to use it, what to provide, and what to expect in return, including the certificate side effect. Nothing critical is missing.

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

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

Schema coverage is 100% with meaningful descriptions for all three parameters. The description adds value by saying 'Pass the plan, the goal it serves, and any constraints,' which clarifies that the optional context parameter is for constraints. This goes beyond the schema's generic 'Optional context' text.

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

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

The description opens with a specific verb+resource: 'review your implementation or project plan before you build.' It clearly distinguishes from sibling tools like review_code and review_content by focusing on plans, not code or content, and states the intended timing and value.

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

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

Provides clear usage context: 'Call right after you draft a plan for a non-trivial task' and 'before any code is written.' It also explains what to pass. However, it does not explicitly name alternatives or when-not-to-use cases, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses return fields (reviewer domain, date, offering, verdict, validity, evidence tier) and the meaning of 'evidence-verified', plus notes it is free. It does not explicitly state read-only behavior or failure modes, but for a verification tool the information provided is substantial.

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

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

The description is a few sentences long, front-loaded with the verb, and each sentence adds value. The evidence-tier explanation and trust-chain example are useful but slightly verbose. Still, it remains appropriately concise for a tool with this complexity.

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

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

The description lists the return fields, compensating for the absent output schema details. It also gives clear usage context and notes the lack of cost. It does not mention edge cases like both parameters provided or error handling, but for a read-only verification tool the essential context is covered.

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

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

Schema coverage is 100% and both parameters have descriptive comments in the schema. The description adds no new parameter-level detail beyond the schema, though it reinforces the OR relationship through context. This matches the baseline for high schema coverage.

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

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

The description opens with 'Verify a Taste content certificate on-chain' which clearly states the specific verb and resource. It differentiates from siblings like verify_external_source by focusing on Taste certificates and the human-review evidence chain, making the tool's niche explicit.

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

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

'Call when consuming content from another source that claims to be human-reviewed' provides a clear when-to-use scenario. The trust chain example further illustrates the intended workflow. However, it does not explicitly mention exclusions or alternatives, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses that a vetted human expert performs the verification and lists the return components (verdict, red flags, positive signals, confidence score). This implies human-in-the-loop behavior and output structure, but does not mention timing, cost, or whether the operation is synchronous—leaving minor gaps.

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

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

The description is two sentences: the first states the action and resource, the second gives usage context and return values. It is front-loaded, contain useful examples, and avoids redundant information. Every sentence earns its place.

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

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

The tool is moderately complex with 2 parameters and an output schema. The description covers purpose, triggers, and return values. It misses some operational details like asynchronous behavior or how to retrieve results (though sibling get_result exists), and the output schema presumably documents return shape. Overall it is sufficient but not exhaustive.

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 (subject, context) are described in the schema. The description adds only mild nuance by stating context is used to clarify intent, which the schema already conveys. No additional parameter meaning is provided beyond the schema.

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

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

The description uses a specific verb+resource: 'verify whether an external source, project, or claim is trustworthy.' It clearly differentiates from sibling verify tools like verify_certificate and verify_reasoning_chain by focusing on external trustworthiness rather than certificates or reasoning. The examples (crypto project legitimacy, social media authenticity) further pin down the scope.

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 explicitly states when to call: 'when your output or planned action depends on an external claim you cannot independently verify.' It provides illustrative situations, but does not explicitly name alternatives or when not to use this tool. This is clear context without formal exclusions.

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

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

With no annotations, the description carries full behavioral burden. It discloses returns ('per-step verdict, flagged errors, suggested corrections') and an on-chain certificate side effect. It does not mention authorization/cost but is otherwise transparent for an audit-style 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?

The description is three concise, action-first sentences with no redundancy. Every sentence adds value: what it does, when to use it, and what it returns/accomplishes.

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

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

The description covers return values, use case, and an on-chain outcome; the output schema covers structured return details. Minor gaps exist around what 'approved' means and on-chain mechanics, but the overall guidance is complete enough for an agent.

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 adds tool-level context ('mid-chain errors', '3+ steps'), but this is not parameter-specific and slightly conflicts with the schema's minItems=2.

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 ('Audit') and resource ('your step-by-step reasoning') with a precise scope ('mid-chain errors') and timing ('before producing the final answer'). This clearly distinguishes it from sibling review/verify tools like review_content and verify_external_source.

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 explicitly says when to call: 'when stakes are high and your chain has 3+ steps' and 'before producing the final answer'. It contrasts with 'final-output checks' but does not name specific alternative sibling tools or provide an explicit when-not-to-use statement.

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