Pay-per-call MCP server. Vetted human experts review AI-generated content (text, images, video, audio, social posts), audit reasoning chains, run prepublish safety checks, and gate high-stakes actions for human approval. 7 paid tools at $1.00 each plus 4 free tools (list_offerings, list_expert_profiles, get_result, verify_certificate). Payment via x402, USDC on Base mainnet. Approved outputs receive an on-chain Taste content certificate downstream agents verify before consuming.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 17 of 17 tools scored.
Each tool has a clearly distinct purpose, covering different aspects of human expert evaluation: dispute arbitration, domain consultation, content review, certificate verification, etc. Even similar tools like review_content and prepublish_review differ in their focus (facts vs. cultural sensitivity), and order_think_tank_session_30 and _60 only differ by duration, which is natural.
All tool names follow a consistent verb_noun pattern in lowercase with underscores (e.g., arbitrate_dispute, list_offerings, verify_certificate). There is no mixing of conventions or vague verbs, making the naming predictable and easy for an agent to infer functionality.
With 17 tools, the server strikes a good balance—enough to cover a wide range of human expert evaluation tasks without being overwhelming. Each tool serves a specific, justifiable purpose within the domain.
The tool set covers core workflows like ordering evaluations, retrieving results, requesting revisions, and verifying certificates. However, there is no explicit tool for ordering an illustration (only revision), which is a minor gap. Overall, the surface is nearly complete for the stated purpose.
arbitrate_disputeAInspectGet an impartial human arbiter to decide whether a deliverable meets an agreed contract, or to settle disagreements between agents. Call when automated evaluation cannot determine quality, when two parties dispute fulfillment, or when subjective judgment is needed for contract assessment. Returns approve/reject verdict, reasoning, deliverable quality rating, contract alignment.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. | |
| termsUri | No | Where the att/v1 manifest is hosted (https/ipfs). Convenience only — the hash is the identity. | |
| termsHash | No | Terms anchor this dispute is bound to: keccak256 of the att/v1 terms manifest (as echoed from the x402 payment), or an opaque 32-byte document hash such as an LCP atrHash ("sha256:0x…" accepted). Persisted on the ruling for the receipt + precedent lookups. | |
| termsJson | No | The full att/v1 terms manifest object. If provided it must be a valid manifest whose keccak256 equals termsHash. | |
| deliverable | Yes | The deliverable to assess. Text or a publicly accessible URL. | |
| partyAPosition | Yes | One side of the dispute. The expert evaluates both impartially — order is arbitrary. | |
| partyBPosition | Yes | The other side of the dispute. | |
| contractDescription | Yes | The agreed contract or deliverable specification. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the arbiter is impartial, returns specific outputs (verdict, reasoning, quality rating, contract alignment), and is for dispute resolution. It does not cover potential limitations or costs, but overall it provides good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences), front-loads the purpose, and every sentence adds value. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, output schema exists, many siblings), the description covers the core purpose, usage conditions, and outputs. It does not explain the output schema details but that is acceptable since the schema exists. 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?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it only restates the purpose of each parameter indirectly. No extra semantics or context are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets an impartial human arbiter to decide whether a deliverable meets a contract or settle disagreements. It specifies the situations for use and lists the return values (verdict, reasoning, quality rating, alignment). This distinguishes it from sibling tools like ask_a_human, which are more general.
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...' and lists three specific scenarios (automated evaluation cannot determine quality, parties dispute, subjective judgment needed). It provides clear context but does not explicitly mention when not to use it or list alternative tools, though the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask_a_humanAInspectAsk a vetted human a plain-text question and get a plain-text answer back, usually within 30 minutes. Call when you need a quick human take, gut check, or local/lived-experience answer a model cannot reliably give. No scoring, no verdict, no certificate — just a direct human response. Returns the human's answer, plus an optional note on who answered.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The plain-text question for a human to answer. Anything you want a quick human take on. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
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 typical response time (within 30 minutes), the nature of the response (direct human answer, no scoring/verdict/certificate), and return fields (answer plus optional note on respondent). This covers essential behavioral traits without contradictory information.
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 purposeful sentences. The first sentence states the core action, the second advises on usage, and the third clarifies boundaries and return value. No unnecessary words; 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 simplicity (one string parameter, no nested objects, and an existing output schema), the description covers all critical aspects: purpose, when to use, behavioral expectations, and return content. There are no evident gaps, and the description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is simple (one parameter 'question' with 100% description coverage). The tool description adds context about 'plain-text' and 'quick human take', but the schema already describes the parameter adequately. As schema coverage is high, the baseline is 3; the description adds marginal value 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: asking a vetted human a plain-text question and receiving an answer. It specifies the use case (quick human take, gut check, local/lived-experience) and explicitly distinguishes from siblings by noting no scoring, verdict, or certificate, which sets it apart from other human-related tools like arbitrate_dispute 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?
The description provides explicit guidance on when to use this tool, such as needing a quick human take or gut check. It implicitly indicates when not to use it by excluding formal outputs, but does not explicitly name alternative tools or conditions for exclusion. The sibling list includes many tools, and a direct comparison would be beneficial, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consult_domain_expertAInspectA vetted human in a named domain answers your question with first-hand knowledge. Pass domain to match an expert. Pass parentSessionId for follow-ups (cap 3). Returns answer, anonymised role, confidence, first-hand flag. Approved answers get an on-chain Taste cert. Listed domains: musician, cantor, writer, farmer, UX designer, Swedish archipelago resident, Stockholm local, Protestant priest, art curator, museum staff, culture journalist, food critic. Other domains: best-effort 24-48h.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Area of expertise needed. Examples of currently listed domains: "Professional musician", "Cantor", "Writer", "Farmer", "UX designer", "Person living in the Swedish Archipelago", "Stockholm local", "Protestant priest", "Art curator", "Museum staff", "Culture journalist", "Food critic". Free-form — describe the kind of expert you need. | |
| context | No | Optional. Why you are asking and what you are working on (essay, research, product decision, etc.). Helps the expert frame their answer. | |
| question | Yes | The specific question to ask the expert. Be precise — the more specific the question, the better the answer. | |
| referenceUrls | No | Optional. Publicly accessible URLs the expert should review before answering. | |
| parentSessionId | No | Optional. If present, this is a follow-up question to the same expert on an existing consultation. Up to 3 follow-ups per parent. Server validates the parent is completed and within the follow-up cap. | |
| buyerWalletAddress | No | Optional. An EVM wallet address. If provided, you can later retrieve the deliverable on humantaste.app by connecting this wallet. | |
| requireListedDomain | No | Optional. If true, the job is declined immediately when the domain is not on the supported listed-domain list, instead of being queued for best-effort sourcing. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes | |
| parentSessionId | No | |
| followupsRemaining | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return values (answer, anonymised role, confidence, first-hand flag), the on-chain Taste cert for approved answers, and the follow-up cap. It does not mention rate limits or failure modes, but the covered aspects are detailed and accurate.
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 that front-loads the core purpose and then covers parameters and behavior efficiently. It avoids redundancy and each sentence adds value, though it could be slightly more structured (e.g., bullet points). Overall, it is concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 2 required, output schema present), the description adequately covers the process, return values, and follow-up constraints. It lacks explicit error handling or non-listed domain behavior beyond 'best-effort 24-48h', but the essential information for an agent to use the tool correctly is present.
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 value by explaining that `domain` is free-form, `parentSessionId` is for follow-ups, `buyerWalletAddress` links to deliverable retrieval, and `requireListedDomain` controls immediate decline. This context goes beyond the schema's basic descriptions, aiding correct invocation.
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 explicitly states the tool matches a 'vetted human in a named domain' to answer questions with first-hand knowledge. It clearly identifies the verb ('answers'), resource ('human expert'), and scope ('named domain'), distinguishing it from general human query tools like ask_a_human. The listed domains and mention of best-effort for others further clarify its specific niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use: pass a `domain` to match an expert, use `parentSessionId` for follow-ups (capped at 3), and lists recognized domains. It does not explicitly state when not to use it or compare to sibling tools, but the context of needing a vetted domain expert is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resultAInspectCheck the status of a previously submitted request. Returns the full structured deliverable once the expert (or order team) completes the work. Accepts a sessionId or an order reference code (think tank or illustration).
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | The session ID returned by a paid tool call. | |
| referenceCode | No | An order reference code (TASTE-...) from a think tank or illustration order. Use this instead of sessionId to retrieve the result — it always returns the latest revision. |
| Name | Required | Description |
|---|---|---|
| tip | No | |
| reason | No | |
| status | Yes | |
| message | No | |
| deliverable | No | |
| estimatedWaitMins | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It mentions status check and deliverable return, but doesn't disclose polling behavior, error states, or access requirements. Adequate but could be more 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?
Two concise sentences plus parameter details. No fluff, front-loaded with purpose. 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?
Output schema exists, so return details are covered. Misses polling behavior and prerequisites. Adequate for a retrieval tool, but could address incomplete work scenarios.
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 description adds meaningful context: sessionId from paid tool, referenceCode format and behavior (latest revision). Significantly enhances 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 checks status and returns deliverables, with a specific verb and resource. It distinguishes from order/revision tools but doesn't explicitly call out siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on parameters (sessionId vs referenceCode) but no when-to-use or when-not-to-use guidance relative to siblings. Implied usage is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_expert_profilesAInspectReturns currently-available expert taglines (pseudonymous descriptions of the kinds of expertise on hand) plus the real-time count of online expert seats and estimated wait. Use this as a cheap pre-flight check before calling a paid tool. Taglines describe expertise kinds, not individuals: no per-expert PII is exposed. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| service | Yes | |
| onlineExperts | Yes | |
| qualityPolicy | Yes | |
| expertTaglines | Yes | |
| estimatedResponseMins | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it is free, no PII exposed, and returns non-identifying taglines. This adds behavioral context beyond the bare minimum.
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 concise sentences front-loading the main output, with 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?
For a parameterless tool with an output schema, the description fully covers what the tool returns, its cost, and privacy implications. Nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is trivially 100%. Baseline is 4, and description adds no parameter info because none needed.
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 returns expert taglines, online seat count, and estimated wait. It distinguishes itself as a free pre-flight check before paid tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use as a cheap pre-flight check before paid tools, providing context for when to use. Does not list exclusions but implies alternatives are the paid tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_offeringsAInspectList all available human expert evaluation offerings with pricing, tool names, and whether each issues an on-chain Taste content certificate. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| usage | Yes | |
| status | Yes | |
| service | Yes | |
| offerings | Yes | |
| nextOpenAt | Yes | |
| onlineExperts | Yes | |
| operatingHours | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially carries the burden. It discloses output fields but does not mention side effects, auth needs, or data freshness. It is adequate for a read-only list.
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 unnecessary words. Information is 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 no parameters and an output schema, the description is complete. It covers the tool's purpose and output details sufficiently.
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?
With zero parameters and full schema coverage, baseline is 4. The description adds no parameter info because none exist.
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 lists all available human expert evaluation offerings, specifying included details (pricing, tool names, certificate). It distinguishes from sibling tools like list_expert_profiles by the nature of 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?
No guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
order_think_tank_session_30AInspectConvene a think tank — a curated team of vetted human experts runs a 30-minute working session on your idea, problem, or decision and returns synthesized directions, ideas with rationale, and recommended next steps. Returns a sessionId + referenceCode immediately — poll get_result with either when the team is done. Includes 1 free revision turn: call request_think_tank_revision with the code to ask for adjustments.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaUrls | No | Optional. Publicly accessible URLs to reference material (images, decks, docs, links) the team should review. | |
| description | Yes | The idea, concept, or problem you want the think tank to work on. Be specific about the goal and any constraints. | |
| buyerWalletAddress | No | Optional. An EVM wallet address. If provided, you can later retrieve the deliverable on humantaste.app by connecting this wallet. | |
| requestedDeliverables | No | Optional. What you want out of the session — e.g. "5 campaign concepts", "a positioning statement", "product name ideas". |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes | |
| referenceCode | Yes | |
| revisionTurns | Yes |
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 the async nature, immediate token return, revision policy, and that experts are 'vetted human experts'. It does not mention costs, failure modes, or authentication, but covers key behavioral properties.
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 (plus a brief continuation) that front-loads the purpose and immediately follows with the async pattern and revision. Every sentence carries essential information 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?
Given the presence of an output schema (not shown but signaled), the description need not detail return values. It fully covers the input requirements, the async retrieval method, and revision capability. No gaps are evident for a tool that initiates a human session.
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% (all params have descriptions), so baseline is 3. The tool description adds context beyond schema: it explains that 'description' is the core input, 'mediaUrls' are optional reference material, and 'buyerWalletAddress' enables later retrieval. This adds meaningful guidance.
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 starts with 'Convene a think tank' and clearly specifies the 30-minute duration, the input (idea/problem/decision), and the output (synthesized directions, ideas, next steps). This distinguishes it from sibling 'order_think_tank_session_60', which is likely a 60-minute version.
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 async flow: returns sessionId+referenceCode immediately, poll get_result for final answer. It also mentions the free revision turn via request_think_tank_revision. However, it does not explicitly compare to the 60-minute session or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
order_think_tank_session_60AInspectConvene a think tank — a curated team of vetted human experts runs a 60-minute working session on your idea, problem, or decision and returns synthesized directions, ideas with rationale, and recommended next steps. Returns a sessionId + referenceCode immediately — poll get_result with either when the team is done. Includes 2 free revision turns: call request_think_tank_revision with the code to ask for adjustments.
| Name | Required | Description | Default |
|---|---|---|---|
| mediaUrls | No | Optional. Publicly accessible URLs to reference material (images, decks, docs, links) the team should review. | |
| description | Yes | The idea, concept, or problem you want the think tank to work on. Be specific about the goal and any constraints. | |
| buyerWalletAddress | No | Optional. An EVM wallet address. If provided, you can later retrieve the deliverable on humantaste.app by connecting this wallet. | |
| requestedDeliverables | No | Optional. What you want out of the session — e.g. "5 campaign concepts", "a positioning statement", "product name ideas". |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes | |
| referenceCode | Yes | |
| revisionTurns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description compensates by disclosing async behavior, immediate return of sessionId+referenceCode, and revision availability. Lacks details on authentication or costs but adequate for a creation 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?
Four sentences cover purpose, workflow, and revision policy. Slightly wordy but well-structured and 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 inputs, async pattern, and revision process. Output schema exists, so return values need not be detailed. Minor gap: no mention of session duration or cost.
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 descriptions cover all parameters fully (100%). Description adds minimal extra value beyond schema examples. 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 clearly states the tool convenes a think tank and returns synthesized directions, ideas, and next steps. It distinguishes from sibling tools like order_think_tank_session_30 and get_result.
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 explains to poll get_result for results and call request_think_tank_revision for revisions. Provides clear workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_audience_reactionAInspectGet a real human matching your target demographic to rate and react to your content as a representative audience member. Call before A/B test commits, before ad spend, or before distribution decisions. Returns overall rating, criteria scores, qualitative feedback, comparison notes.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to evaluate. Text or a publicly accessible URL for non-text media. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. | |
| targetDemographic | Yes | The audience whose reaction matters. Required — load-bearing for expert matching. E.g. "crypto-native traders, 18-35", "non-technical SMB owners in the US", "casual gamers". |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that a real human provides ratings, criteria scores, qualitative feedback, and comparison notes, which adds behavioral context. However, it lacks details on latency, authorization, or side effects, making it only moderately 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 two sentences, front-loaded with the core purpose, followed by usage guidance and output summary. Every sentence is necessary and concise, 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?
Given the tool's moderate complexity and the existence of an output schema (implied by 'Returns overall rating...'), the description covers purpose, usage, parameters, and return values. It misses details like expected turnaround time or cost, but is generally complete for 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%, so baseline is 3. The description adds value by providing examples for targetDemographic (e.g., 'crypto-native traders, 18-35') and clarifying that context is optional for intent. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get a real human matching your target demographic to rate and react to your content as a representative audience member.' It uses a specific verb and resource, and the mention of 'before A/B test commits, before ad spend, or before distribution decisions' distinguishes it from sibling tools like review_content or 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?
The description provides explicit use cases: 'Call before A/B test commits, before ad spend, or before distribution decisions.' This gives clear context for when to use the tool, but it does not mention when not to use it or explicitly list alternatives, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_consult_domain_expertAInspectGet a humantaste.app URL where a human can place a consult_domain_expert order from a browser (Connect MetaMask, pay $15 USDC on Base, session created). Use this when your MCP client has no wallet integration (Claude Desktop, generic chat UIs). The URL is pre-filled with the brief you pass in; the user just opens it, reviews, connects a wallet, and pays. Returns the payment URL and the price. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Area of expertise needed (e.g. Farmer, Protestant priest, UX designer, Stockholm local, art curator, museum staff, culture journalist, food critic). | |
| context | No | Optional. Why you are asking and what you are working on. | |
| question | Yes | The specific question to ask the expert. | |
| referenceUrls | No | Optional. Publicly accessible URLs the expert should review. | |
| parentSessionId | No | Optional. If present, the URL submits a follow-up to an existing consultation (capped at 3 per parent, same expert). |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| message | Yes | |
| priceUsdc | Yes | |
| paymentUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the process, return values (payment URL, price), and cost ($15 USDC on Base). However, the term 'Free' is ambiguous—possibly meaning the tool itself costs nothing, but it contrasts with the payment requirement. Minor confusion prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main purpose, and every sentence adds value. 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 5 parameters and an output schema, the description covers the essential workflow and return. It mentions the expected price and payment method. However, it does not describe the output schema in detail or explain optional parameters like parentSessionId, but the schema already does that.
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?
With 100% schema coverage, baseline is 3. The description adds minimal extra meaning beyond the schema: it refers to the 'brief you pass in' but does not elaborate on parameters like context, referenceUrls, or parentSessionId. No semantic enrichment.
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 explicitly states the tool's purpose: generating a humantaste.app URL for a human to place a consult_domain_expert order via browser. It clearly distinguishes from sibling tools like 'consult_domain_expert' by specifying the use case (no 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?
The description provides explicit guidance: 'Use this when your MCP client has no wallet integration (Claude Desktop, generic chat UIs).' It explains the workflow (pre-filled URL, user reviews, connects wallet, pays), leaving no ambiguity about when to employ this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepublish_reviewAInspectGet a vetted human expert to review your AI-generated content — text, images, videos, social posts, audio, or any media — for cultural sensitivity, brand safety, derivative risks, and audience appeal before you publish. Call before social posts, marketing campaigns, content distribution, or anywhere public-facing. Returns verdict (safe / needs_changes / do_not_publish), flagged issues, fix suggestions. Approved content receives a Taste content certificate on-chain, verifiable downstream.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to review. Text directly, or a publicly accessible URL for non-text media. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the review is done by a human expert and returns verdict, issues, and fixes. However, it does not mention potential latency, cost, content storage, or other behavioral traits that might be relevant for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear front-loading. It efficiently covers what, when, and what is returned without extraneous information. Slightly longer than ideal but remains well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (assumed to detail return values), the description sufficiently covers purpose, usage timing, and returned items. It lacks mention of potential async nature or human availability, but for a review tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional meaning beyond what the schema already provides for both the 'content' and 'context' parameters. With full coverage, baseline is 3, and no extra value is added.
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 by a human expert for cultural sensitivity, brand safety, and audience appeal. It mentions returning a verdict and on-chain certificate, which distinguishes it from generic review tools like review_content, though no explicit sibling differentiation is made.
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 does not mention when not to use or provide alternatives, but the guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_human_approvalAInspectPause your workflow for explicit human approval before executing a high-stakes action. Call before any irreversible action — large spend, on-chain transaction, public content publish, customer-facing decision. Returns approved/denied + reasoning. Approvals can be enforced on-chain via the Taste Gatekeeper hook for ACP and ERC-8183 jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| stakes | Yes | What kind of risk the action carries. Reversible: undoable. Irreversible: cannot be undone. Financial: moves value. Public: visible externally. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. | |
| timeoutMinutes | No | Maximum minutes to wait for a human response before returning denied_timeout. Default 30, max 120. | |
| actionDescription | Yes | Describe the action awaiting approval. Include numbers (amounts, recipients, URLs) the human needs to see. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly discloses the behavior: pauses workflow, returns approved/denied with reasoning, and mentions on-chain enforceability. This is comprehensive and accurate.
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 with no wasted words. The first sentence front-loads the core purpose, followed by specific usage examples, return value, and advanced feature. 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?
The tool has an output schema (mentioned but not shown), and the description explains return values (approved/denied + reasoning). It also covers enforcement mechanism, which is advanced context. For a tool with 4 parameters and moderate complexity, this is 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 descriptions, but the description adds value beyond schema by advising that actionDescription should include numbers the human needs to see (amounts, recipients, URLs) and that context clarifies intent and constraints. This extra guidance improves usability.
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 pauses workflow for explicit human approval before high-stakes actions. It distinguishes from siblings like ask_a_human and consult_domain_expert by specifying it is for irreversible actions (large spend, on-chain transaction, public content publish, customer-facing decision).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: before any irreversible action. It lists concrete examples. However, it does not explicitly mention when not to use it or name alternatives among the siblings, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_illustration_revisionAInspectSpend a free revision turn on a completed illustration order. Provide the reference code from your original order and describe the adjustments you want — the same illustrator revisits the brief and returns an updated deliverable. Poll get_result with the reference code to retrieve it. Free: no payment required, the turn is included with your order.
| Name | Required | Description | Default |
|---|---|---|---|
| adjustments | Yes | What you want the illustrator to adjust, expand, or rethink. | |
| referenceCode | Yes | The TASTE-... reference code returned when you placed the illustration order. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| sessionId | Yes | |
| referenceCode | Yes | |
| turnsRemaining | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the same illustrator revisits the brief, that the result is obtained by polling get_result, and that no payment is required. It does not mention idempotency or side effects, but the scope is limited and the critical behaviors 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?
Two sentences, front-loaded with the key action and resource, and every sentence adds value. There is no wasted text, and the structure is logical: action, required inputs, follow-up step.
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 purpose, parameters, and workflow (poll for result). Since an output schema exists but is not shown, the description effectively explains that the output is retrieved via another tool. This is appropriate for a mutation tool that does not return data directly.
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 value by explaining the reference code format (TASTE-...) and clarifying that adjustments are for the same illustrator. This supplements the schema definitions 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 tool is for spending a free revision turn on a completed illustration order, using a reference code and adjustments. It specifies the action and resource, and distinguishes from siblings like request_think_tank_revision by mentioning 'illustration order' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (after placing an order, need a revision) and notes that it's free. It does not explicitly state when not to use it or suggest alternatives, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_think_tank_revisionAInspectSpend a free revision turn on a completed think tank order. Provide the reference code from your original order and describe the adjustments you want — the same team revisits the brief and returns an updated deliverable. Poll get_result with the reference code to retrieve it. Free: no payment required, the turn is included with your order.
| Name | Required | Description | Default |
|---|---|---|---|
| adjustments | Yes | What you want the team to adjust, expand, or rethink. | |
| referenceCode | Yes | The TASTE-... reference code returned when you placed the think tank order. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| sessionId | Yes | |
| referenceCode | Yes | |
| turnsRemaining | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the revision is free ('no payment required'), that the same team revisits the brief, and that the result is retrieved via 'get_result'. It does not specify error handling for invalid reference codes or missing revision turns, but the core behavioral traits are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences to convey purpose, inputs, and follow-up action. It front-loads the core action ('Spend a free revision turn') and avoids unnecessary details. 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 simplicity (2 parameters, output schema exists), the description is mostly complete. It explains what the tool does, what parameters to provide, and how to retrieve the result. It lacks details on error scenarios or prerequisites (e.g., ensuring a free turn is available), which would make it more robust.
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 clear parameter descriptions. The description adds value by explaining the process: 'the same team revisits the brief and returns an updated deliverable' and emphasizing the free nature. This context enriches the schema's bare descriptions, justifying a score above the baseline of 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 explicitly states the tool's purpose: 'Spend a free revision turn on a completed think tank order.' It specifies the action (revision), the resource (think tank order), and the condition (free turn). This clearly distinguishes it from siblings like 'order_think_tank_session_30' (ordering new) and 'request_illustration_revision' (illustration 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 provides clear context for when to use the tool: after a completed think tank order with a free revision turn. It also directs the user to poll 'get_result' to retrieve the updated deliverable. However, it does not explicitly state when not to use it (e.g., if no free turn remains) or compare it to alternatives like ordering a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_codeAInspectGet a vetted human engineer to review your code, architecture, and design decisions — not just style, but correctness, security, and whether the structure will hold up. Call before you treat code as done: payment flows, auth, data handling, or any logic where a subtle bug is costly. Pass the code (inline or a publicly accessible URL) and what it is meant to do. Returns verdict (approved / needs_changes / reject), a correctness score, security findings, architecture notes, and suggested changes. Approved code receives a Taste content certificate on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code to review. Paste it inline, or pass a publicly accessible URL (e.g. a gist or raw file). | |
| intent | Yes | What the code is meant to do — the behaviour and constraints, plus any correctness or security concerns to focus on. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return verdict, correctness score, security findings, architecture notes, and on-chain certification. It does not mention rate limits or auth, but the core behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph that front-loads the purpose, then usage, parameter guidance, and output. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (human in the loop, output schema present), the description covers input, process, output, and certification. The context signals show high schema coverage and presence of output schema, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying that 'code' can be a URL, 'intent' can include focus areas, and 'context' is optional for extra info. This goes beyond the schema 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 explicitly states it gets a human engineer to review code, covering correctness, security, and architecture. It clearly distinguishes from sibling tools like 'review_content' and 'consult_domain_expert' by focusing on code 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?
The description provides strong guidance on when to use: 'Call before you treat code as done: payment flows, auth, data handling, or any logic where a subtle bug is costly.' It does not explicitly state when not to use, but the positive context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_contentAInspectGet a vetted human expert to review your AI-generated content — text, images, videos, social posts, audio, or any media — for hallucinations, factual errors, weak parts, and domain mistakes. Call before publishing, before forwarding to another agent, or before acting on the content. Returns verdict, issues found, suggested improvements. Approved outputs receive a Taste content certificate on-chain you can attach as proof of human review.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to review. Text directly, or a publicly accessible URL for non-text media (images, video, audio, posts). | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the process (vetted human expert), the types of errors checked (hallucinations, factual errors, weak parts, domain mistakes), and expected outputs (verdict, issues, improvements, certificate). It does not cover costs, rate limits, or turnaround time, but for a human-review tool, it provides sufficient behavioral insight.
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, all front-loaded with the most critical information: what the tool does, when to use it, and what it returns. Every sentence serves a purpose, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (handles multiple media types, includes certification), and the presence of an output schema, the description covers the essential aspects: purpose, input format, use cases, and outcomes. It lacks details like turnaround time or how the certificate works, but the output schema likely fills those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying that 'content' can be direct text or a URL for non-text media, which goes beyond the schema's description. This extra guidance justifies a score above the baseline of 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 specifies a clear verb ('Get a human expert to review'), defines the resource ('AI-generated content'), and details the scope ('text, images, videos, social posts, audio, or any media'). It distinguishes from siblings like 'ask_a_human' or 'consult_domain_expert' by focusing on content review before publishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to call: 'before publishing, before forwarding to another agent, or before acting on the content.' While it gives clear context for use, it does not explicitly mention alternatives or when not to use this tool, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_planAInspectGet a vetted human to review your implementation or project plan before you build. Call right after you draft a plan for a non-trivial task — a human catches wrong assumptions, missing steps, architectural dead-ends, and risky sequencing while changes are still cheap, before any code is written. Pass the plan, the goal it serves, and any constraints. Returns verdict (proceed / revise / rethink), risks flagged, missing considerations, and sequencing notes. Approved plans receive a Taste content certificate on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the plan is meant to achieve — the objective or task it addresses. | |
| plan | Yes | The implementation or project plan to review. Paste the full plan — steps, approach, architecture, sequencing. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
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 reviews the plan and returns a verdict with risks and missing considerations, plus an on-chain certificate for approved plans. However, it doesn't mention time/cost or availability of humans, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 70 words, front-loaded with the core action. It is fairly concise but includes some non-essential details (e.g., 'while changes are still cheap' and 'before any code is written') that could be trimmed. Still, it's well-structured and easy to parse.
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 output), the description covers input (plan, goal, context), output (verdict, risks, notes, certificate), and usage context (early in development). It is fully complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the three parameters (goal, plan, context). The description adds minimal additional meaning beyond restating that context can be used for constraints. 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 clearly states the tool's purpose: 'Get a vetted human to review your implementation or project plan.' It specifies the verb (review) and resource (plan), and distinguishes it from siblings like review_code or consult_domain_expert by focusing on plan review with human vetting.
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 use the tool: 'Call right after you draft a plan for a non-trivial task' and highlights benefits like catching wrong assumptions early. It also tells what to pass (plan, goal, constraints), providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_certificateAInspectVerify a Taste content certificate on-chain. Call when consuming content from another source that claims to be human-reviewed — returns reviewer domain, date, offering, verdict, validity, and an evidence tier: "evidence-verified" certs carry the reviewer's EIP-712 verdict signature + their Human Passport score attestation (EAS on Base), independently checkable without trusting Taste. Free. Use to build trust chains: agent A's output is reviewed → certificate issued → agent B consumes content and verifies cert before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| contentHash | No | keccak256 hash of the content, as 0x-prefixed hex. Provide this OR certificateId. | |
| certificateId | No | Numeric certificate id. Provide this OR contentHash. |
| Name | Required | Description |
|---|---|---|
| agent | No | |
| found | Yes | |
| valid | No | |
| domain | No | |
| reason | No | |
| verdict | No | |
| evidence | No | |
| issuedAt | No | |
| contentHash | No | |
| offeringType | No | |
| certificateId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details return fields (reviewer domain, date, offering, verdict, validity, evidence tier) and explains the evidence-verified tier's additional signature and attestation. It implies a read-only operation and independence from trust, but does not cover error cases or rate limits.
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 structured with a clear first sentence, then usage guidance, then return details, then a free note, then the use case. It is slightly verbose with the trust chain example but overall justified. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to detail return values. It covers purpose, usage context, behavioral traits, and parameter guidance sufficiently. All key aspects are addressed for a verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description does not add new meaning beyond what the schema provides (e.g., keccak256 hash, 0x-prefixed hex). Thus, the description adds minimal value beyond the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('verify') and the resource ('a Taste content certificate on-chain'), providing a specific verb and resource. It distinguishes itself from siblings like verify_external_source and verify_reasoning_chain by focusing on Taste certificates and evidence tiers.
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 when consuming content from another source that claims to be human-reviewed'. It also notes it is free, which aids usage decisions. However, it does not explicitly mention when not to use or provide direct alternatives, though the context of sibling tools is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_external_sourceAInspectHave a vetted human expert verify whether an external source, project, or claim is trustworthy. Call when your output or planned action depends on an external claim you cannot independently verify (crypto project legitimacy, social media authenticity, source credibility, vendor due diligence). Returns verdict, red flags, positive signals, confidence score.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. | |
| subject | Yes | The URL, project name, or claim to verify. Be specific (e.g. a URL, a project name + token address, or a verbatim claim). |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses a 'vetted human expert' and returns 'verdict, red flags, positive signals, confidence score.' However, it does not mention any potential costs, turnaround time, or side effects. Given the absence of annotations, this is adequate but not highly detailed.
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: the first states the core purpose; the second gives usage guidance and what the tool returns. No unnecessary words, front-loaded with key information, and highly 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 tool's moderate complexity (2 parameters, output schema exists), the description covers the essential aspects: what it does, when to use, and what it returns. It could mention any prerequisites or limitations (e.g., potential delays) but is largely complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (subject and context) described. The description adds some extra context (e.g., 'Use to clarify intent') but does not significantly enhance understanding beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Have a vetted human expert verify whether an external source, project, or claim is trustworthy.' It uses a specific verb (verify) and a clear resource (external source, project, claim), distinguishing it from sibling tools like consult_domain_expert or ask_a_human.
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: 'Call when your output or planned action depends on an external claim you cannot independently verify.' It provides examples such as crypto project legitimacy and source credibility. While it does not mention explicit alternatives or when not to use, the guidance is clear and covers the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_reasoning_chainAInspectAudit your step-by-step reasoning for mid-chain errors before producing the final answer. Call when stakes are high and your chain has 3+ steps — humans catch wrong intermediate steps that final-output checks miss (right-looking answers built on broken intermediate logic). Returns per-step verdict, flagged errors, suggested corrections. Approved chains receive a Taste content certificate on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Ordered array of reasoning steps. Each step: { step (number), reasoning (string), output (string), toolUsed? (string) }. | |
| context | No | Optional context. Use to clarify intent, constraints, audience, or anything that helps the expert evaluate. |
| Name | Required | Description |
|---|---|---|
| tip | Yes | |
| status | Yes | |
| message | Yes | |
| offering | Yes | |
| priceUsdc | Yes | |
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the return format: per-step verdict, flagged errors, suggested corrections, and mentions a certification ('Approved chains receive a Taste content certificate on-chain'). It does not explicitly state whether the tool is read-only or any side effects, but the nature of verification suggests read-only.
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, each serving a clear purpose: purpose, usage guidance, and return value. No redundant information. Front-loaded with the primary function.
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 purpose, usage conditions, return values, and an important behavioral note (certification). For a tool with only two parameters and a described return (output schema exists), this is complete. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds little beyond the schema: it clarifies that 'context' is optional and its purpose, and it describes the structure of chain steps (step, reasoning, output, toolUsed). This is helpful but does not significantly exceed what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Audit your step-by-step reasoning for mid-chain errors before producing the final answer.' It specifies the resource (reasoning chain) and action (audit), and distinguishes from siblings by noting that it catches errors that final-output checks miss.
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 when stakes are high and your chain has 3+ steps.' It also explains why it's preferable to alternatives: 'humans catch wrong intermediate steps that final-output checks miss (right-looking answers built on broken intermediate logic).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
