Taste

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

The description discloses the tool's behavior: it involves a human arbiter and returns a verdict, reasoning, quality rating, and contract alignment. While no annotations exist, the description adequately explains what the tool does, though it could mention potential delays due to human involvement.

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, comprising four short sentences that cover purpose, usage, and output. Each sentence adds value without redundancy, achieving efficiency without sacrificing clarity.

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 presence of an output schema and full parameter descriptions, the description covers purpose, usage, and output well. However, for a human-in-the-loop tool, it lacks context on expected response time or potential limitations, making it slightly less 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% with detailed parameter descriptions. The tool description adds minimal extra meaning beyond summarizing the input schema; it repeats the essence but does not significantly enhance parameter understanding.

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: obtaining an impartial human arbiter to decide if a deliverable meets a contract or to settle disputes. It distinguishes itself from siblings like request_human_approval and consult_domain_expert by specifying its unique role in subjective quality assessment and dispute resolution.

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?

Explicit usage conditions are provided: 'Call when automated evaluation cannot determine quality, when two parties dispute fulfillment, or when subjective judgment is needed for contract assessment.' This clearly guides the agent on when to invoke this tool versus 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 that the expert is vetted, provides anonymised role, confidence, and first-hand flag, and mentions on-chain certification. It also notes a follow-up cap and best-effort sourcing for unlisted domains. Missing details like cost or precise turnaround for listed domains are acceptable 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 concise and well-structured. It front-loads the core purpose, then provides parameter guidance and behavioral notes. Every sentence adds unique 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 seven parameters (100% schema coverage) and an output schema, the description covers purpose, usage, output, and special behavior (certification, follow-up caps). It lacks details on expert selection or prerequisites but is largely complete for its 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 description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the follow-up cap (parentSessionId), the 'best-effort 24-48h' for unlisted domains (requireListedDomain), and the on-chain certification (buyerWalletAddress). This enriches understanding.

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: 'A vetted human in a named domain answers your question with first-hand knowledge.' It specifies the verb (answers) and resource (expert), and distinguishes it from sibling tools like 'order_think_tank_session' by focusing on individual expert consultation.

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 explains how to use the tool: pass 'domain' to match an expert and 'parentSessionId' for follow-ups (cap 3). It also lists supported domains and mentions fallback behavior. However, it does not explicitly state when not to use this tool or compare it to alternatives like 'order_think_tank_session' or 'list_expert_profiles'.

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, description bears full burden. It discloses that the tool returns a deliverable once work completes and that referenceCode always returns latest revision. Could add idempotency or auth details, but sufficient for this simple tool.

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

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

Three sentences, no wasted words. Front-loaded with main purpose. Each sentence adds unique information.

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

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

For a retrieval tool with output schema, description covers purpose, parameters, and return behavior. No gaps given the 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 covers both parameters at 100%. Description adds value by explaining the distinction: sessionId for paid calls, referenceCode for think tank/illustration orders with always-latest-revision behavior.

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

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

Description clearly states the tool's purpose: 'Check the status of a previously submitted request' and 'Returns the full structured deliverable...'. Verb+resource is specific and distinguishes from sibling tools that are for ordering or consulting.

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?

Description implies when to use (after submitting a request) and explains the two parameter options with their contexts. Lacks explicit exclusions or alternatives, but 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?

Describes return values and clarifies that taglines describe expertise kinds, not individuals, with no PII exposed. Also notes it is free. No annotations were provided, so description carries burden and does well.

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 concise sentences, front-loaded with the core return info. Every sentence adds value with no waste.

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 zero-parameter tool with an output schema, the description explains all key return fields and the privacy aspect. There is no ambiguity.

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?

No parameters exist; baseline is 4. Description adds value by explaining the output, which helps understand what the zero-param call returns.

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?

Specifically states it returns expert taglines, online seat count, and estimated wait. Clearly distinguishes from paid tools by labeling it a 'pre-flight check'.

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 advises using it as a cheap pre-flight check before calling a paid tool. Could be improved by mentioning when not to use, but the guidance 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?

No annotations provided, so description must stand alone. It states the tool lists offerings with details and is free, but does not disclose rate limits, data freshness, or that it is read-only. Adequate but lacks depth.

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

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

Single sentence that is very concise and front-loads the purpose. No wasted words.

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

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

Given the tool is simple with no params and an output schema exists, the description covers key aspects (pricing, tool names, certificate, free). Could mention read-only nature, but overall 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?

No parameters in input schema, so parameter semantics are not applicable. Baseline for 0 parameters is 4, and description adds no extra parameter info, which is fine.

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 verb 'list' and the resource 'offerings', and provides specific details about the content (pricing, tool names, certificate info). It distinguishes from siblings like list_expert_profiles which list experts, not 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 usage when listing available offerings, but does not provide explicit guidance on when to use this tool versus alternatives or any exclusions. No mention of when not to use.

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 discloses immediate return of sessionId+referenceCode, polling via get_result, and one revision turn. It does not mention any destructive actions, authentication, or rate limits, but covers key behavioral aspects.

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 efficiently convey purpose, process, and key behaviors. No unnecessary words; information 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?

Given 4 parameters (1 required) and an output schema, the description covers the workflow (async polling, revision) and references sibling tools. It is adequately complete for an agent to 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 description coverage is 100%, and the description adds context beyond the schema—e.g., 'images, decks, docs, links' for mediaUrls and examples for requestedDeliverables. This enriches understanding without redundancy.

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 ('Convene a think tank'), specifies the duration (30-minute), and lists outputs (synthesized directions, ideas, next steps). It distinguishes itself from the sibling 'order_think_tank_session_60' by the session length.

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 explains when to use the tool (for ideas, problems, decisions) and mentions a free revision turn via 'request_think_tank_revision'. However, it does not explicitly contrast with the 60-minute variant or other sibling 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?

With no annotations, the description fully bears behavioral burden. It explains async return and two revision turns, but omits authentication needs, rate limits, cost implications, or any destructive behavior. Adequate but not thorough.

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 paragraph with three logical sentences: purpose, async return, revisions. Front-loaded and efficient, though slightly verbose in the first sentence (could be shortened).

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 output schema exists (covers return structure), the description adds async polling and revision workflow, which is valuable. Missing potential context like pricing or prerequisites, but overall complete for a tool with 4 parameters and full schema coverage.

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

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

All four parameters have schema descriptions (100% coverage). The tool description does not add new meaning beyond the schema; it merely implies usage context. Baseline 3 is appropriate as schema already documents 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 tool convenes a 60-minute think tank session with human experts, specifying the verb 'Convene' and resource 'think tank session'. Duration distinguishes it from the 30-minute sibling, and the outcome (synthesized directions, ideas, next steps) is 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?

Provides clear workflow guidance: returns sessionId/referenceCode immediately, poll get_result, use request_think_tank_revision for revisions. However, does not explicitly mention when not to use this tool versus siblings like consult_domain_expert or predict_audience_reaction.

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 discloses the key behavioral trait: a real human is matched to the demographic and provides ratings, criteria scores, qualitative feedback, and comparison notes. It doesn't mention rate limits or authorization, but the core behavior and output are clearly stated.

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: first states the core function, second tells when to use, third lists returns. Every sentence adds value, no fluff, and it is front-loaded with the most important 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?

Given an output schema exists (not shown but indicated), the description covers purpose, usage context, and return types. It doesn't mention prerequisites like having a human available or cost, but for a tool with this complexity and sibling set, it is largely complete.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description does not add parameter semantics beyond what the schema already provides (e.g., examples for targetDemographic are in the schema description). No additional meaning or usage hints are given for parameters in the tool description.

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

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

The description clearly specifies the verb 'Get' and the resource 'a real human matching your target demographic to rate and react to your content'. It distinguishes this tool from siblings like consult_domain_expert or review_content by emphasizing audience reaction prediction. Use cases (before A/B test, ad spend, distribution decisions) further clarify purpose.

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

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

The description explicitly advises when to call the tool ('before A/B test commits, before ad spend, or before distribution decisions'), providing clear context. It does not specify when not to use it or mention alternative tools, but the guidance is actionable and context-rich.

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 provided, so description carries burden. Describes flow: get URL, user reviews, connects wallet, pays, session created. Returns payment URL and price. Minor issue: states 'Free' despite mentioning $15 payment, causing slight confusion. Otherwise 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?

Concise and front-loaded with main purpose, usage condition, and outcome. The contradictory 'Free' at end mars efficiency slightly, but overall compact and clear.

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?

Covers what, when, and outcome. Does not mention expiration of URLs or error handling. Given 5 parameters and output schema, missing edge case details but sufficient for typical use.

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 adequate per-parameter descriptions. The description says 'brief you pass in' but adds no new semantics beyond schema. Baseline 3 is appropriate since schema already documents 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 tool creates a humantaste.app URL for placing a consult_domain_expert order via browser, with specific payment details (MetaMask, $15 USDC on Base). It distinguishes from sibling tools like consult_domain_expert by targeting 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?

Explicit usage condition: 'Use this when your MCP client has no wallet integration (Claude Desktop, generic chat UIs).' This clearly indicates when to use and implies alternatives like direct consultation for wallet-capable clients.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool returns a verdict, flagged issues, fix suggestions, and a certificate on-chain. However, it does not mention any required permissions, side effects, or whether the review is read-only or mutates state. The output format is partially described, but lacks details on error handling or idempotency.

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 moderately concise, front-loading the main action and then detailing use cases and outputs. Every sentence adds useful information, though the list of media types could be slightly more compact. Overall, it is well-structured but not overly terse.

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 (human review with on-chain certificate), the description covers inputs, appropriate use cases, and outputs. An output schema exists but is not provided; however, the description lists what is returned. There are no glaring gaps for an AI agent to decide when to use this tool.

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

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

The input schema covers both parameters with descriptions that explain their use (URL for non-text media, context for clarification). The description adds value by explicitly stating that 'content' can be text or a URL, and that 'context' helps the expert evaluate. Since schema description coverage is 100%, the baseline is 3, but the extra clarification earns a 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's purpose: getting a human expert to review AI-generated content before publishing. It specifies the action (review), resource (content), and distinguishes it by mentioning the human expert, certificate, and types of media. This contrasts with siblings like review_content which may not offer human review or on-chain certification.

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 when-to-use guidance: 'Call before social posts, marketing campaigns, content distribution, or anywhere public-facing.' It does not mention when not to use or explicitly name alternative tools, but the context of pre-publication human review is clear enough for an AI agent to decide.

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 fully carries the burden. It discloses that the tool pauses the workflow, returns 'approved/denied + reasoning', and mentions on-chain enforcement. The timeout behavior is described in the parameter schema but not in the description, which is a minor gap.

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

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

The description is three sentences, each serving a distinct purpose: stating the action, specifying usage context, and describing the result and additional enforcement capability. No unnecessary words.

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

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

Given the presence of an output schema, the description provides all necessary context: when to use, what it does, what it returns, and additional enforcement details. The parameter schema covers the rest.

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 baseline is 3. The description adds value beyond the schema by explaining the return format ('approved/denied + reasoning') and noting on-chain enforcement via the Taste Gatekeeper hook, which is not in the schema.

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

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

The description clearly states 'Pause your workflow for explicit human approval before executing a high-stakes action.' It uses a specific verb+resource (request human approval) and provides concrete examples (large spend, on-chain transaction). The tool is distinct from siblings as the only one focused on pausing for human approval.

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: 'Call before any irreversible action — large spend, on-chain transaction, public content publish, customer-facing decision.' It provides clear context but does not specify when not to use or suggest alternatives, which would improve the score.

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 provided, so description carries full burden. It explains that the same illustrator revisits the brief and returns an updated deliverable, and that no payment is required. It does not mention side effects, but behavior is largely self-contained.

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

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

Three sentences, front-loaded with the action. Efficiently covers purpose, usage, and retrival. No unnecessary words.

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

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

For a simple tool with 2 parameters and an output schema, the description covers purpose, usage, retrival step, and cost implication. No gaps identified.

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 descriptions. The description adds minimal new info beyond schema for adjustments and referenceCode. Baseline of 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?

Description clearly states the action: spending a free revision turn on a completed illustration order. It distinctively refers to the resource (illustration order) and contrasts with sibling tools like request_think_tank_revision.

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?

Description specifies when to use the tool (after a completed order) and that it's a free included turn. It advises polling get_result to retrieve the updated deliverable. No explicit when-not-to-use, but context makes it 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?

No annotations are provided, so the description must disclose behavioral traits. It states the action is free and that the same team revisits the brief. However, it does not specify whether the original order is modified or if the revision turn is consumed irreversibly. It also omits authorization needs or rate limits, though for a free revision turn these may be less critical.

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 (three sentences) and front-loaded with the key action. Every sentence adds value: stating the action, explaining the workflow, and clarifying the cost.

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 main workflow (order revision, then poll get_result). With an output schema present, return values need not be detailed. It does not address edge cases like invalid reference codes or exhausted revision turns, but for a simple two-parameter tool it is mostly 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?

Both parameters have schema descriptions (100% coverage). The description adds value by contextualizing referenceCode as a 'TASTE-...' code and explaining that adjustments are provided to the same team. It also clarifies that the revision is free, which is not in the schema.

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

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

The description clearly states the tool's purpose: spending a free revision turn on a completed think tank order. It specifies the action (spend a revision turn), the resource (think tank order), and mentions retrieving the result via get_result. It is distinct from sibling tools like request_illustration_revision and order_think_tank_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 explicitly mentions that this is a free revision turn included with the order, implying it should be used after an initial order. It also directs the user to poll get_result, guiding the workflow. However, it does not explicitly exclude scenarios (e.g., when no revision turns remain) or compare directly with other revision tools.

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

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

No annotations provided, so description carries full burden. It discloses human expert involvement and on-chain certificate, but lacks details on turnaround time, potential costs, or limitations on content types beyond text/URL.

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 with no wasted words. The structure front-loads the purpose, then usage, then returns. Every sentence adds value.

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 adequately summarizes return values (verdict, issues, improvements) and mentions the certificate. It is complete for most use cases, though could mention if the review is asynchronous.

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?

Both parameters are documented in the schema with 100% coverage. The description adds value by explaining that 'content' can be text or a URL for non-text media, and that 'context' clarifies intent. This goes beyond schema constraints.

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

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

The description clearly states the tool's purpose: 'Get a vetted human expert to review your AI-generated content... for hallucinations, factual errors...' It uses specific verbs and resource, and mentions on-chain certification which distinguishes it from similar siblings like 'prepublish_review'.

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 explicit when-to-use guidance: 'Call before publishing, before forwarding to another agent, or before acting on the content.' It also describes return values. However, it does not explicitly mention when not to use or suggest 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?

No annotations are provided, so the description must disclose all behavioral traits. It mentions 'Free' and 'on-chain', but does not specify whether this is a read-only call, requires a wallet connection, or has any side effects. The lack of detail is a significant gap.

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

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

The description is only three sentences, each adding distinct value: function, usage trigger, and trust chain context. No redundancy or wasted words.

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

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

Given the tool has an output schema (not shown but referenced), the description covers the key return fields. It lacks details about error handling or failure modes, but for a verification tool with moderate complexity, 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's existing parameter descriptions. It does not clarify the mutual exclusivity or provide examples beyond what is already in the schema.

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

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

The description clearly states the tool verifies a Taste content certificate on-chain, lists the return fields (reviewer domain, date, offering, verdict, validity), and contrasts with sibling tools like verify_external_source and verify_reasoning_chain by focusing on Taste certificates.

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 'Call when consuming content from another source that claims to be human-reviewed' and provides a trust chain example. It does not mention when not to use or alternatives, but the context is clear enough.

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 reveals that the tool uses a vetted human expert and returns verdict, red flags, positive signals, and confidence score. It implies a human-in-the-loop process but does not detail costs, turnaround time, or limitations.

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: two sentences. The first sentence states the core purpose, and the second covers usage guidelines and output. Every word earns its place, with no redundancy.

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

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

The description is complete given the tool's complexity. It explains what the tool does, when to use it, and what it returns (verdict, red flags, positive signals, confidence score). It also covers the parameters adequately, even though the output schema is not shown, the description lists the key return fields.

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?

Both parameters have descriptions in the input schema (100% coverage). The description adds value by specifying that subject should be a URL, project name + token address, or verbatim claim, and that context is optional but can clarify intent. This goes beyond the schema's basic 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 purpose: having a vetted human expert verify an external source, project, or claim. It provides specific verbs and resources, and distinguishes itself from sibling tools like verify_certificate and verify_reasoning_chain by emphasizing human expertise and external claims.

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 when to call the tool: when output depends on an external claim that cannot be independently verified. It lists example scenarios (crypto project legitimacy, social media authenticity, etc.), providing clear context, though it does not explicitly state when not to use or mention alternatives.

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

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

No annotations provided, so description covers full behavioral disclosure: it returns per-step verdict, flagged errors, suggested corrections, and on-chain certificate. Clearly states it catches intermediate errors missed by final checks.

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

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

Three sentences, front-loaded with purpose, then usage, then output. No wasted words. Every sentence adds value.

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?

Output schema exists (mentioned in context signals), description explains return values and purpose. For a tool with 2 parameters and moderate complexity, description fully covers needed 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?

Input schema has 100% coverage, so baseline 3. Description does not add new parameter-specific meaning beyond schema; it only mentions chain and context implicitly. Schema already describes parameters thoroughly.

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?

Description clearly states the tool audits step-by-step reasoning for mid-chain errors. It specifies the action ('Audit your step-by-step reasoning') and resource ('chain'), distinguishing it from siblings like 'get_result' or 'verify_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?

Explicitly says 'Call when stakes are high and your chain has 3+ steps' and contrasts with final-output checks, providing clear when-to-use and alternative strategies.

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