Know what you're buying: brand, white-label, price, fake-discount, review and seller checks
Scored across 3 tools
Each tool targets a clearly distinct scope: check_brands evaluates brand reputation, check_product evaluates a single listing, and check_products evaluates multiple listings for comparison. The boundaries are explicit (single product vs. batch), so an agent can easily select the right tool.
All three tools follow a consistent verb_noun pattern (check_brands, check_product, check_products) with singular/plural distinction used meaningfully. The convention is predictable and readable.
Three tools is well-scoped for this server's purpose: brand checking and product trust-signal checking for single and multiple products. Each tool earns its place, and the batch version is justified for comparison use cases.
The surface covers the core domain of evaluating brand and product trust signals, with both single and batch product checks plus brand checks. Minor gaps include no explicit tool for seller-only checks or historical tracking, but these are not critical for the stated purpose.
Use this when the user asks whether a brand is reputable or what kind of brand it is (an established name, a store's own label, an independent maker, or a generic white-label name), or wants brands compared while shopping. Returns findings on each brand: what kind of brand it is, its reputation for quality and its usual price tier, each with a confidence. Signals only, never a buy or avoid verdict. Does not browse the web and is not for banking, health or email pages. Pass brand names as the user or the listing gave them, up to 50 per call.
| Name | Required | Description | Default |
|---|---|---|---|
| brands | Yes | Brand names, 1-50. | |
| detail | No | Include each finding's full probability distribution. Default false. |
| Name | Required | Description |
|---|---|---|
| quota | No | What is left of the allowance after this request. |
| brands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld=false, so safety is covered. The description still adds valuable substance: what each finding contains, that confidence is attached, that these are 'signals only, never a buy or avoid verdict', and importantly 'does not browse the web' — clarifying the openWorldHint=false meaning. Good added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the trigger condition, then returns, then exclusions, then parameter guidance. Dense but every sentence earns its place; the enumeration of brand types is slightly verbose but aids selection.
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 need not be explained, and the description nonetheless summarizes the finding shape. Given annotations plus output schema, nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a genuine constraint not obvious from the schema alone: 'Pass brand names as the user or the listing gave them, up to 50 per call' — coaching formatting and echoing the 50 cap, which exceeds schema-only value.
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?
States a specific verb+resource ('Check brands') and enumerates what 'kind of brand' means (established name, store's own label, independent maker, generic white-label), distinguishing it from check_product/check_products which operate on products. An agent can select it confidently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('when the user asks whether a brand is reputable or what kind of brand it is... or wants brands compared while shopping') plus explicit when-not ('not for banking, health or email pages'). This is unusually thorough routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user is looking at a specific product listing on an online store and wants to know whether it looks trustworthy or like a good buy. Pass what you already read from the listing as arguments: title (required) and, when shown, brand, price, listPrice (the seller's "was" price), currency, url, seller, category, rating, reviewCount and key details; each extra field sharpens the read. Returns findings such as generic white-label product, quality, price, questionable discount, review credibility and seller legitimacy, each with a confidence, plus a report on the brand unless includeBrand is false. Signals only, never a buy or avoid verdict. Does not browse: only the domain of url is used. Not for banking, health, government or email pages.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Your own id for this product (e.g. an ASIN or list index); echoed back. | |
| url | No | Listing URL. Only its domain is used. | |
| brand | No | Brand or maker, if the listing names one. | |
| price | No | What the buyer would pay now, as a number. | |
| title | Yes | Product title exactly as the listing shows it. | |
| detail | No | Include each finding's full probability distribution. Default false. | |
| rating | No | Average star rating out of 5. | |
| seller | No | Seller or store name, if different from the site. | |
| details | No | Key specs or bullet points as plain text. Longer text is trimmed. | |
| category | No | Product category, e.g. "Headphones". | |
| currency | No | ISO 4217 code for price and listPrice. Default USD. | |
| listPrice | No | The seller's "was" / "list" / "typical" price, if shown. | |
| reviewCount | No | Number of ratings or reviews. | |
| includeBrand | No | Also report on the brand the listing names (its brand field), with findings on the brand itself. Default true. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| brand | No | |
| quota | No | What is left of the allowance after this request. |
| counts | Yes | |
| summary | Yes | |
| instincts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive) but the description adds real behavioral context the annotations cannot: it returns signals only and never a buy/avoid verdict, it does not browse and uses only the domain of url, and the brand report is suppressed when includeBrand is false. Those are the non-obvious traits an agent needs.
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?
Front-loads the trigger, then the arguments, then the return shape and limits; every sentence carries information. It is dense but runs long, and the enumeration of findings partially duplicates what the output schema already exposes.
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 14-parameter, open-ended analysis tool it covers trigger, required vs optional inputs, return shape, the no-verdict limitation, the no-browsing constraint and domain exclusions. Nothing an agent needs to invoke it correctly is missing, and the output schema means return values need not be spelled out further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the description goes beyond it by explaining the intent of the argument set ('pass what you already read from the listing', 'each extra field sharpens the read') and clarifying that listPrice is the seller's 'was' price and that only title is required. It still omits detail on id/detail/currency, which the schema already covers.
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?
States a specific verb and resource ('check a product listing') and scopes it to a single listing the user is looking at, which separates it from the plural sibling check_products. It also names what the output is (trustworthiness findings), so an agent can tell what it gets back without opening the schema.
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?
Gives an explicit trigger ('when the user is looking at a specific product listing... wants to know whether it looks trustworthy') and explicit exclusions ('Not for banking, health, government or email pages'). It does not name check_products/check_brands as the alternative for bulk or brand-only checks, so routing between siblings is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user is comparing several product listings, such as search results or the same item at different stores, and wants trust signals on each. Pass up to 20 products, each with what you already read from its listing: title (required) and, when shown, brand, price, listPrice, currency, url, seller, category, rating, reviewCount, details, plus your own id to match results. Returns, in input order, the same findings as check_product for each; a product that can't be checked carries an error and message instead. Signals only, never a buy or avoid verdict. Does not browse the web. Not for banking, health, government or email pages.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Include each finding's full probability distribution. Default false. | |
| products | Yes | Products, 1-20. | |
| includeBrand | No | Also report on the brand the listing names (its brand field), with findings on the brand itself. Default true. |
| Name | Required | Description |
|---|---|---|
| quota | No | What is left of the allowance after this request. |
| products | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral detail beyond them: partial-failure semantics ('a product that can't be checked carries an error and message instead'), output ordering ('in input order'), and the output contract ('signals only, never a buy or avoid verdict'). It does not mention auth or rate limits, but for a read-only tool that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the triggering scenario before the mechanics, and the return contract and exclusions follow in a logical order. It is a dense single paragraph with a few near-redundant clauses (e.g. restating the field list already in the schema), so not quite a 5.
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 batch read-only tool with an output schema present, the description covers everything an agent needs: trigger, batch size, input expectations, output ordering, partial-failure behavior, and scope exclusions. Return-value shape is correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds framing the schema does not: the fields should be 'what you already read from its listing' (i.e. do not fetch anything new), the 20-item cap, and that the caller-supplied id is 'to match results'. That is useful guidance layered on top of the per-field 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?
States a specific verb and resource (check multiple product listings for trust signals) and explicitly distinguishes itself from the singular sibling: it returns 'the same findings as check_product for each' product. An agent can tell immediately this is the batch counterpart to check_product.
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?
Gives an explicit trigger ('when the user is comparing several product listings, such as search results or the same item at different stores') and explicit exclusions ('Not for banking, health, government or email pages'). The batch-vs-single routing versus check_product is also stated.
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.
get_proget_pro2 fields changedOutput schema / properties / includesAdded value: +{
+ "description": "What Pro includes: \"3,000 checks a month\".",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "checkoutUrl",
- "price",
- "renewal",
- "upgradesKey",
- "next"
-]New value: +[
+ "checkoutUrl",
+ "price",
+ "includes",
+ "renewal",
+ "upgradesKey",
+ "next"
+]get_procheck_brandscheck_productcheck_productsDetect fake or manipulated product reviews from Amazon, Trustpilot, Google and Etsy.
See who gets your money, catch fake holiday discounts, and find independent and local sellers.
Verified deals, store policies & a trust score for thousands of online retailers. No auth.
Cheapest delivered price for any product: tech, home, shoes, beauty. Read from each store's checkout
Add one secure layer between your agents and this server.
