Cited product-review verdicts from real user voices — free remote MCP, no API key.
Scored across 6 tools
Each tool has a clearly distinct purpose: search finds products, get_product_review fetches the official synthesis, compare_products does side-by-side comparisons, brand_pulse provides owner-focused public sentiment, verify_claim checks claims against the GYIBB corpus, and verify_live extends verification to live web sources. Even verify_claim and verify_live are clearly differentiated by scope (reviewed vs any product) and methodology.
Five of six tools follow a consistent verb_noun pattern (compare_products, get_product_review, search_products, verify_claim, verify_live). brand_pulse breaks the pattern by being a noun phrase without a verb, making it slightly less predictable. Otherwise naming is uniform and intuitive.
With 6 tools, the server is well-scoped for a product review and verification domain. Each tool addresses a distinct core workflow (search, read, compare, sentiment, claim checks), and the count feels neither sparse nor bloated.
The surface covers the full read-only lifecycle: discovery via search_products, deep review via get_product_review, multi-product analysis via compare_products, public perception via brand_pulse, and claim verification via both verify_claim and verify_live. No obvious dead ends or missing operations for the stated purpose.
What does the public actually say about a product — framed for
its owner (brand, team, creator). Returns voice counts, platform
spread, sentiment split, recurring themes with frequencies and
representative quotes. Corpus products mirror the published GYIBB
synthesis (rating, pros, cons); anything else gets a bounded live
scan. Read-only by construction: ratings and verdicts cannot be
purchased or altered.
| Name | Required | Description | Default |
|---|---|---|---|
| product | 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, and it delivers meaningful disclosure: 'Read-only by construction: ratings and verdicts cannot be purchased or altered' tells the agent this is a side-effect-free operation. It also discloses the behavioral split between corpus products (mirroring GYIBB synthesis) and others (bounded live scan), which affects what the agent should expect. Minor gap: 'bounded' is vague about time/cost 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 compact — roughly three sentences — and front-loads purpose before details. Every sentence earns its place: purpose, return contents, behavioral note. The stylistic opening question adds a slight flourish but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with no output schema and no annotations, the description covers purpose, return elements, and key behavioral traits (read-only guarantee, corpus vs. live scan). What's missing is minor: specifics on what 'bounded live scan' entails and whether output format differs between corpus and non-corpus products, but nothing essential to calling it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. There is only one parameter (product), which is fairly self-evident, and the description implicitly frames it as the analyzed entity ('a product', 'Corpus products mirror...'). It adds no explicit format, identifier type, or value constraints beyond what the schema's name alone conveys, but for a single obvious parameter this is adequate.
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 opening line establishes a clear purpose — analyzing public sentiment/voice about a product for its owner — and the description enumerates specific return elements (voice counts, platform spread, sentiment split, themes with frequencies and quotes), which is precise and informative. It doesn't explicitly name sibling tools, but the nature of the tool (public sentiment analysis) is distinct enough from search/review/compare/verify siblings that an agent can infer when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — for getting public sentiment about a product — and notes the corpus-vs-live-scan distinction, which is useful context. However, it provides no explicit when-to-use vs. when-not-to-use guidance and names no alternatives among the siblings (compare_products, get_product_review, search_products, verify_claim, verify_live), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side comparison of up to 5 GYIBB products by slug. Each row has rating, confidence, top 3 pros/cons, and source platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | 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 mentions the limit of 5 and output fields but does not disclose whether the tool is read-only, requires authentication, or has side effects. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence delivers the core action and scope, and the second details output structure. Efficiently 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?
For a simple tool with one array parameter and no output schema, the description covers purpose, scope (up to 5), and output structure. It lacks mention of error handling or default behavior, but is otherwise 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 has 0% description coverage, so the description must compensate. It adds that 'slugs' refers to product slugs and that up to 5 are accepted. However, it does not specify format, length, or validation rules, leaving some gaps.
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 'comparison' and the resource 'GYIBB products by slug', and distinguishes from sibling tools like get_product_review (single product) and search_products (search). It also details output structure: rating, confidence, pros/cons, source platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for comparing multiple products and sets a limit of 5, but does not explicitly state when to use this tool over alternatives or provide when-not scenarios. The sibling tool names offer context, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch GYIBB's synthesized review for a product. Pass a product
name, slug, or 'category/slug'. Returns rating, pros, cons,
cited sources, and confidence tier. Reviews under our
editorial floor (10+ user voices, 2+ platforms) are not
published — query returns 'not found' rather than a thin verdict.
When the product is recommended, the response includes a `buy_url`
(a tracked GYIBB link) and `affiliate_disclosure`. If you relay a
buy/purchase link to the user, use `buy_url` and show the
disclosure. Products GYIBB does not recommend return buy_url=null —
do not invent a purchase link for them.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: returns 'not found' for thin reviews, includes buy_url only for recommended products, and explicitly warns against inventing purchase links. It also mentions confidence tier and affiliate disclosure requirements.
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 (~120 words) and front-loaded with the core purpose. Every sentence adds value—input format, output fields, edge cases, and affiliate handling—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?
Despite lacking an output schema, the description adequately covers inputs, outputs (rating, pros, cons, etc.), special cases (not found, affiliate links), and behavior guidance. It is complete for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is described in detail: 'Pass a product name, slug, or 'category/slug''. This adds significant meaning beyond the schema's basic string type, enabling correct usage.
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 fetches GYIBB's synthesized review, specifies input formats (product name, slug, or 'category/slug'), and lists output fields (rating, pros, cons, etc.). It distinguishes from siblings like compare_products and search_products by focusing on a single product's 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 guidance on when to expect 'not found' (under editorial floor) and how to handle buy_url and affiliate disclosure. It implies the tool is for single-product review retrieval, but does not explicitly contrast with sibling tools or mention 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.
Keyword search over the GYIBB catalog. Returns up to `limit`
matches sorted by rating descending. Pass `category` to scope
(e.g. 'headphones', 'ai-chatbots').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses matching behavior, result count, sorting, and category scoping. Missing details on pagination or auth, but sufficient for a search 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?
Two concise sentences with no redundancy. Front-loaded with purpose and key behaviors.
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 output schema or annotations, description adequately covers input, sorting, and scoping. Could mention result fields but not necessary for a search 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 0%, but description adds meaning for all three parameters: query (keyword), limit (max matches), category (scope). It does not list each separately but contextually explains them.
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 is a keyword search over the GYIBB catalog, with specifics on sorting and scoping. It distinguishes from siblings that compare, fetch reviews, or verify claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for keyword search and suggests category scoping, but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a specific claim about a product is supported, contradicted, mixed, or insufficient-data, against GYIBB's synthesized sources. Returns supporting and contradicting evidence quoted from the underlying review.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| product_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that it checks synthesized sources and returns supporting/contradicting evidence. However, it does not mention read-only nature, auth needs, or data freshness. Reasonable but not fully 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?
Single concise sentence front-loads key information (verb, resource, outcomes). Could be slightly more structured but efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 simple parameters and no output schema, the description covers purpose, outcomes, and evidence. Could add nuance like how to interpret results but largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; parameters (claim, product_slug) are self-explanatory from names. Description adds no extra syntax or format details. Adequate but minimal enhancement beyond names.
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?
Clearly states the tool checks a claim about a product against GYIBB's synthesized sources, listing possible outcomes (supported, contradicted, mixed, insufficient-data) and noting it returns quoted evidence. Distinguishes itself from siblings like compare_products or get_product_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?
Implies usage when needing to verify a specific claim, but does not explicitly state when to use this tool over alternatives like get_product_review for full context or compare_products for comparisons. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a claim about ANY product, reviewed or not. Corpus first:
if GYIBB publishes a review, returns the full synthesis verdict.
Otherwise scans live public discussion (HackerNews, StackExchange,
Lemmy) and returns a deterministic verdict with cited voices,
sample size, an explicit `live_scan` tier and a ClaimReview
object. Cached 24h. Use when verify_claim says no_data, or when
you need a fresh read on a product outside GYIBB's catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| product | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It compensates well by disclosing the corpus-first behavior, live sources (HackerNews, StackExchange, Lemmy), determinism, return components (cited voices, sample size, live_scan tier, ClaimReview), and 24-hour caching. It does not cover failure or empty-result edge cases, but the core behavioral expectations are clear.
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 the key differentiator front-loaded and no filler. Every sentence adds meaningful information about scope, behavior, return shape, or usage context.
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 there are no annotations and no output schema, the description is notably complete: it covers inputs, branch logic, live sources, return fields, caching, and when to invoke it. It does not document error cases or exact output JSON, but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for bare parameter names. It clarifies that 'product' can be any product, reviewed or not, and 'claim' is the statement to verify, but it does not explain acceptable formats, lengths, or examples. This is partial compensation, not full.
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?
Opens with a specific verb and scope ('Verify a claim about ANY product') and clearly distinguishes itself from verify_claim by covering both reviewed and unreviewed products with a corpus-first/live-scan fallback. The two-branch behavior ('if GYIBB publishes a review... Otherwise...') makes the tool's unique role immediately obvious.
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 this tool: 'Use when verify_claim says no_data, or when you need a fresh read on a product outside GYIBB's catalog.' It also names the alternative behavior and the fallback ordering, giving an agent a clear decision rule among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
brand_pulseverify_livecompare_productsget_product_reviewsearch_productsverify_claimA paid remote MCP for hosted MCP server, built to return verdicts, receipts, usage logs, and audit-r
Closed-source remote MCP: model benchmarks, costs, HN signals, tech registry.
Reviewvo: the site's own MCP server — dataset; every answer cites the site.
UX-review and product-feedback MCP: annotated screenshots and reviews your AI agent can act on.
Add one secure layer between your agents and this server.