Taste

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

No annotations provided, so the description carries the full burden. It discloses that a human arbiter is involved (implying delay) and lists expected returns: approve/reject verdict, reasoning, quality rating, contract alignment. It could be more explicit about latency or cost, but it is sufficiently 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 concise: three sentences covering purpose, usage guidelines, and outputs. Every sentence adds value, no fluff. Front-loaded with the core action.

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 clearly states what the tool returns, and an output schema exists (per context signals). It covers the agent's decision needs. Missing explicit mention of asynchronous human involvement, but overall complete given the output schema.

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 good parameter descriptions. The tool description does not add much beyond the schema; it reiterates the parameters (contract, deliverable, positions) without additional constraints or details. 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 'Get an impartial human arbiter' and clearly identifies the resource (deliverable vs contract). It distinguishes itself from siblings like 'consult_domain_expert' and 'request_human_approval' by explicitly stating when to call: when automated evaluation fails, when parties dispute, or when subjective judgment is needed.

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 guidance: 'Call when automated evaluation cannot determine quality, when two parties dispute fulfillment, or when subjective judgment is needed for contract assessment.' This tells the agent both when to use and implies when not to (e.g., when automated evaluation suffices).

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 discloses behavior: human expert, first-hand knowledge, return values (answer, role, confidence, flag), on-chain certificate for approved answers, and best-effort time for unlisted domains. It does not contradict any annotations.

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

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

The description is in a single paragraph but efficiently packs all key information: purpose, parameters, domain list, follow-up cap, and output details. It is front-loaded with the primary action. Minor reorganization could improve readability, but it remains 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 (7 parameters, optional output schema), the description covers essential aspects: required vs optional parameters, domain handling, follow-up rules, output fields, and on-chain certification. It provides sufficient context for agent invocation.

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%, but the description adds meaningful context beyond the schema: e.g., 'domain' matches an expert, 'parentSessionId' has a 3-follow-up cap, 'buyerWalletAddress' enables retrieval on humantaste.app, and 'requireListedDomain' rejects instantly if unlisted. This enriches parameter understanding beyond the schema 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 clearly states the tool's purpose: a vetted human expert answers a question via first-hand knowledge. It specifies passing 'domain' to match an expert and 'parentSessionId' for follow-ups, distinguishing it from sibling tools like 'prepare_consult_domain_expert' or 'list_expert_profiles'.

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 good usage guidance, including when to use the tool (getting expert answers), follow-up limitations (3 per parent), and domain handling (listed vs best-effort). However, it doesn't explicitly exclude alternatives or mention when not to use this tool instead of others.

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 states that the tool returns a full structured deliverable once work completes, implying a read operation. However, it doesn't disclose auth requirements, rate limits, or whether it is idempotent.

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 purpose, the second explains the parameters. It is front-loaded, clear, and contains 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 that an output schema exists, the description need not detail return values. It covers the essential information: what the tool does, the two accepted parameters, and when the result is available. It omits error handling or timeout behavior but is fairly 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?

Input schema covers both parameters with descriptions (100% coverage). The description adds value by explaining that 'referenceCode always returns the latest revision' and that sessionId comes from a paid tool call, enriching understanding 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 clearly states the tool's purpose: 'Check the status of a previously submitted request' and specifies the resource ('status') and verb ('check'). It distinguishes from sibling tools like 'order_think_tank_session_30' and 'request_think_tank_revision' by focusing on retrieval of results.

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 the accepted parameters (sessionId or referenceCode) but does not explicitly state when to use this tool versus alternatives like 'consult_domain_expert' or 'review_content'. It lacks guidance on prerequisites or 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?

No annotations provided, but the description fully compensates by stating it is free, returns no PII ('no per-expert PII is exposed'), and provides real-time counts and wait times. This gives a complete behavioral picture.

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 high information density. First sentence lists what is returned; second sentence provides usage guidance and privacy. 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?

Output schema exists and covers return types. Description supplements with real-time nature, free cost, and privacy. For a zero-parameter tool, this is fully 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?

Input schema has zero parameters, so no parameter documentation is needed. Description adds context about the output (taglines, count, wait) beyond the schema, justifying a score above baseline of 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?

Description clearly states it returns expert taglines, online count, and wait time. Verb 'returns' is specific, and the resource is well-defined. It is easily distinguishable from sibling tools like 'consult_domain_expert'.

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 as a cheap pre-flight check before calling a paid tool.' This provides clear context and when to use. It does not mention when not to use, but the guidance is sufficient for an informational tool.

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

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

With no annotations, the description carries the burden. It discloses it's free and returns specific fields. However, it does not mention authentication requirements or side effects, though none are expected for a listing 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?

Single sentence that is front-loaded and contains all essential information. No redundant 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 zero parameters and an output schema, the description is complete. It covers purpose, output details, and cost aspect. The agent has sufficient information 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?

There are zero parameters, so the schema coverage is 100%. The description adds value by explaining what is returned (pricing, tool names, certificate info), which is meaningful for agent selection.

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 lists all available human expert evaluation offerings with pricing, tool names, and certificate info. It distinguishes from sibling tools like 'list_expert_profiles' which lists 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 it's free and intended to list offerings, but does not explicitly state when to use it over alternatives like 'list_expert_profiles' or when not to use it. No exclusions or context provided.

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

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

With no annotations, the description provides reasonable transparency: it explains the asynchronous flow (immediate sessionId, polling get_result), the revision policy, and the session duration. However, it lacks details on potential failure modes, cost, or expert availability.

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 action, and contains no redundant information. Every word 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?

For a complex tool with asynchronous behavior, the description covers the main flow and references sibling tools for polling and revisions. The output schema is available. It could briefly mention that the session is not immediate, but the polling instruction suffices.

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 minimal value beyond the schema, only reinforcing that 'description' should be specific. The schema already explains parameters well.

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 30-minute think tank session with experts, returning synthesized directions and next steps. It distinguishes from the sibling order_think_tank_session_60 by the duration, and mentions specific deliverables like sessionId and referenceCode.

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 (for ideas, problems, decisions) and mentions the revision tool as an alternative for adjustments. However, it does not explicitly exclude cases where other sibling tools like consult_domain_expert might be more appropriate.

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

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

With no annotations, the description carries the full burden. It discloses the asynchronous behavior (returns sessionId immediately, poll get_result later) and the revision policy (2 free turns). It does not mention authentication, costs, or rate limits, but the key behavioral traits are 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 relatively concise with three sentences covering purpose, async behavior, and revisions. It could be restructured for easier scanning (e.g., bullet points), but it remains focused and informative without 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 complexity (async, revisions, output schema), the description covers the key points: what it does, immediate return, polling, and revision option. It omits prerequisites and costs, but the existence of an output schema reduces the need to detail return values. Overall sufficient 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?

All four parameters have schema descriptions (100% coverage). The tool description adds context beyond the schema: e.g., for buyerWalletAddress it explains wallet retrieval, and for requestedDeliverables it provides examples. This extra meaning elevates the score above baseline 3.

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 'convene' and the resource 'think tank session', and specifies the session duration (60 minutes). It distinguishes from sibling tools like order_think_tank_session_30 (30-minute version) and request_think_tank_revision (revision) by describing the immediate async return and revision feature.

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 when to use the tool: for ideas, problems, or decisions. It also hints at alternatives by mentioning get_result for polling and request_think_tank_revision for revisions. However, it does not explicitly contrast with the 30-minute session or other consulting tools, slightly limiting guidance.

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

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

No annotations provided, so description carries full burden. Discloses that a human is involved ('real human matching your target demographic') and describes return values (overall rating, criteria scores, etc.). Could detail turnaround time or constraints, but sufficient for an AI agent to understand behavior.

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

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

Two sentences that efficiently state purpose, usage, and return. No redundancy or filler. 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?

Given the tool's complexity (3 parameters, no enums, output schema exists), the description covers purpose, usage guidelines, and return values. Could mention any limitations like rate limiting or exclusivity, but overall complete for an AI agent to select and invoke.

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

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

Schema description coverage is 100% with clear parameter descriptions. Description adds value by explaining the output (ratings, scores, feedback) which helps interpret parameter effects. Slight improvement over baseline 3.

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') and resource ('real human matching your target demographic') and clearly distinguishes from sibling tools like 'consult_domain_expert' or 'review_content' by focusing on audience reaction.

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

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

Explicitly states when to use ('before A/B test commits, before ad spend, or before distribution decisions'). Does not explicitly state when not to use, but context from sibling tools implies 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?

Describes the flow: prefilled URL, user reviews, connects wallet, pays $15 USDC. Also mentions return values. Lacks details on URL expiration or cancellation, but overall transparent for a simple URL generator.

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, no wasted words. Efficiently conveys all necessary 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 output schema exists, the description adequately covers the tool's functionality and integrates well with sibling tools in the server.

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?

Adds meaning by stating parameters prefill the brief and that parentSessionId submits a follow-up with a cap of 3 per parent, complementing the fully described 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 it generates a humantaste.app URL for placing a consult_domain_expert order via browser, distinguishing it from the direct consultation tool.

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

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

Explicitly says to use when MCP client lacks wallet integration (Claude Desktop, generic chat UIs), providing clear when-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that a human expert reviews content and returns a verdict, flagged issues, fix suggestions, and an on-chain certificate for approved content. However, it does not mention latency, cost, required permissions, or whether it is synchronous or asynchronous, leaving gaps in 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 four sentences, each serving a distinct purpose: stating what the tool does, when to use it, what it returns, and an additional outcome (certificate). It is front-loaded with the core purpose. While slightly verbose, it contains no fluff and is well-structured.

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 moderate complexity (2 parameters, output schema exists, no annotations), the description covers purpose, usage scenario, return values (verdict, issues, suggestions, certificate), and provides enough context for an agent to decide when to invoke it. Missing details like error handling are likely covered by the output schema.

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%, baseline is 3. The description adds value by explaining that 'content' can be text or a publicly accessible URL for non-text media, and that 'context' clarifies intent, audience, or constraints. This goes beyond the schema's short 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 reviews AI-generated content for cultural sensitivity, brand safety, and audience appeal, with a specific verb ('Get a vetted human expert to review') and resource ('your AI-generated content'). It distinguishes from siblings like 'review_content' by emphasizing human expertise, on-chain certificates, and specific use cases like social posts and marketing campaigns.

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 social posts, marketing campaigns, content distribution, or anywhere public-facing.' It provides clear context but does not mention when not to use it or suggest alternatives, which would enhance guidance.

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

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

With no annotations provided, the description carries the full burden. It indicates the return format ('approved/denied + reasoning') and mentions on-chain enforcement, but does not describe timeout behavior or other subtle traits; schema covers timeout but description lacks explicit mention.

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 long, each serving a distinct purpose: defining the action, giving usage context, and describing output. It is front-loaded and wastes no words, achieving high conciseness.

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

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

Given the presence of an output schema (context signal indicates true), the description need not detail return values, but it does mention them. It covers purpose, usage, and behavioral context adequately, though it omits error conditions or when not to use. Overall, it is fairly complete for the tool's 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 the schema already documents each parameter. The description adds value through usage examples but does not enhance meaning beyond the schema definitions, warranting a baseline 3.

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 pauses workflow for human approval before high-stakes actions, with specific examples like large spend and on-chain transactions. It distinguishes itself from sibling tools such as arbitrate_dispute or consult_domain_expert, which serve different purposes.

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 use the tool ('Call before any irreversible action') and provides concrete examples. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity for edge cases.

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. It discloses that this is a write operation using a free revision turn, that no payment is required, that the same illustrator revisits the brief, and that the result is an updated deliverable. It lacks details on limits or side effects but is sufficiently transparent for a simple mutation.

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

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

The description is concise, with three sentences that front-load the main action. Every sentence adds value: explaining the tool, usage steps, and cost. No unnecessary 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 the tool's simplicity (two parameters, output schema exists), the description is largely complete. It covers purpose, usage, follow-up action, and cost. It does not specify revision limits or the exact meaning of 'free turn', but for a straightforward tool, it provides adequate 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 has 100% coverage, so the description adds minimal value beyond the schema. For referenceCode, both describe the TASTE-... code; for adjustments, both mention describing adjustments. The description provides context about the same illustrator but does not enhance parameter understanding significantly.

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: to spend a free revision turn on a completed illustration order. It specifies the verb 'spend', the resource 'revision turn', and the context 'illustration order', distinguishing it from 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?

The description explains when to use the tool (after placing an illustration order) and how to use it (provide reference code and adjustments). It also advises polling get_result to retrieve the updated deliverable. However, it does not explicitly state when not to use it 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 carries full burden. States free, same team revisits, but doesn't disclose limits (e.g., one free revision only) or timing.

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 efficient sentences with no waste; key actions and constraints 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?

Covers purpose, usage, and retrieval; missing explicit mention of revision limits or prerequisites beyond reference code, but generally sufficient given simple tool and output schema.

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 with good descriptions; description supplements by noting retrieval process and team revisiting, adding value beyond 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?

Description clearly states it spends a free revision turn on a completed think tank order, distinguishing it from ordering new sessions or retrieving results.

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?

Describes when to use (completed order needing free revision) and mentions polling get_result, but doesn't explicitly exclude alternatives like requesting illustration revisions or 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 must fully disclose behavior. It mentions vetted human expert, return of verdict/issues/suggestions, and on-chain certificate. However, it does not indicate if review is synchronous, typical turnaround time, or any prerequisites beyond content and optional 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?

Description is approximately 80 words, well-structured with purposeful sentences: what the tool does, when to use, what it returns. 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?

Output schema exists (not shown) so description need not detail return values. It mentions verdict, issues, suggestions, and certificate. Could mention if synchronous or async, but overall complete for a complex tool.

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

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

Schema coverage is 100% and schema descriptions are already detailed. The description adds clarifying 'publicly accessible URL' for non-text media, which is already in schema description. Thus adds minimal value beyond 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 obtains a human expert review of AI-generated content for hallucinations, factual errors, weak parts, and domain mistakes. It specifies content types (text, images, videos, etc.) and outputs (verdict, issues, suggestions, on-chain certificate), distinguishing it from sibling tools like 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?

Explicitly states when to call: 'before publishing, before forwarding to another agent, or before acting on the content.' Does not mention when not to use or explicitly name 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?

No annotations are provided, so the description carries the full burden. It states the operation (verify) and return fields, implying it is non-destructive. It does not explicitly state read-only behavior, rate limits, or permissions, but the verification nature is clear. Adequate but not fully explicit.

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. The first sentence gives the core purpose, the second adds usage context, and the third provides a use case (trust chains). Front-loaded and efficient.

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 output schema exists (context signals indicate it does), the description does not need to detail return format. It already mentions return fields (reviewer domain, date, etc.). Two parameters are well-documented in schema. The description adds context for when to use (human-reviewed content, trust chains) and that it's free. Complete for agent decision-making.

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 both parameters described. The tool description adds no new parameter meaning beyond the schema (e.g., 'provide this OR certificateId' is already in schema). Baseline 3 is appropriate since the schema already documents the parameters well.

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: 'Verify a Taste content certificate on-chain.' It specifies the action (verify) and the resource (certificate), and distinguishes from siblings like verify_external_source and verify_reasoning_chain by focusing on certificate verification for human-reviewed content. Returns are explicitly listed.

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 context: 'Call when consuming content from another source that claims to be human-reviewed.' It also mentions that it is free and builds trust chains. However, it does not explicitly mention when not to use or name 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?

No annotations are provided, so the description carries full burden. It discloses that a human expert is involved and describes return fields (verdict, red flags, etc.). However, it does not mention potential latency or cost, which are important behavioral traits for a human-expert 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 concise: three sentences covering purpose, usage, and returns. No unnecessary words, and each sentence adds distinct 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 the output schema exists and schema coverage is high, the description is largely complete. It mentions return fields. A minor gap is not addressing that the human-expert process may be asynchronous or have a delay, which could affect agent expectations.

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

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

Schema description coverage is 100%. The description adds value beyond the schema by clarifying usage hints (e.g., 'Use to clarify intent' for context and 'Be specific (e.g. a URL)' for subject), helping the agent provide effective input.

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 external sources. It uses specific verbs ('verify') and resources ('external source, project, or claim') and provides examples that differentiate it from siblings like 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?

The description explicitly says when to call ('when your output or planned action depends on an external claim you cannot independently verify') and gives examples. It does not explicitly mention when not to use or alternatives, but the context across siblings provides implicit 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?

No annotations provided, so description fully covers behavior. It discloses returns per-step verdict, flagged errors, suggested corrections, and that approved chains receive an on-chain certificate. Clearly indicates read-only audit with a side effect of certificate issuance.

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. No filler; every sentence adds value. Efficient and well-structured.

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, and description mentions return values (verdict, errors, corrections). Covers input, behavior, and output adequately for a reasoning audit tool.

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

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

Schema coverage is 100% with descriptions for both 'chain' and 'context'. Description does not add extra meaning beyond schema; it focuses on use case. Baseline of 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?

Description clearly states the tool audits step-by-step reasoning for mid-chain errors, with a specific verb ('Audit') and resource ('reasoning chain'). It distinguishes from sibling tools like 'verify_certificate' and 'verify_external_source' by focusing on internal reasoning verification.

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 calls out when to use: high stakes with 3+ steps. Contrasts with final-output checks, explaining why intermediate checks matter. Lacks explicit 'when not to use' or alternative tools, but provides strong context.

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