ProductClank

Check what ChatGPT and Claude say about a product

create_ai_visibility_check

Find out what AI assistants tell buyers about the product: real people ask ChatGPT / Claude (and optionally Gemini, Perplexity, Grok) the product's buying questions from their OWN accounts in a fresh chat, and send back the shared chat link or a screenshot. Once the check ends (default 4 days) the owner generates a report: how often the product comes up, who gets named instead, and the exact words — nothing is probed through an API, and nobody on the panel is paid more when the product's name shows up. COST: one flat launch fee of 1,000 credits at create, whatever the panel size; the panel earns ProductClank points; the report is free. Call with dry_run:true first — it returns the brief and the price and creates nothing — show it to the user, then call again with dry_run:false once they say yes. Give it the buying questions the user cares about (or omit questions to let people ask in their own words). Nothing is posted anywhere.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_id": "<product_id>"
    },
    "name": "create_ai_visibility_check"
  }
}

Input Schema

Name	Required	Description
`days`	No	How long the panel has to ask (default 4).
`models`	No	Assistants to ask. Default ChatGPT + Claude.
`dry_run`	No	true = return the brief and the price, create nothing, charge nothing. Do this first.
`questions`	No	Optional 1–30 buying questions the panel picks from, e.g. 'best analytics tool for solo founders'. Omit to let people ask in their own words.
`product_id`	Yes	Product UUID (from search_products or create_product).
`max_participants`	No	Panel size: people who may submit an answer (default 40).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) it discloses the commercial terms up front: one flat 1,000-credit launch fee charged at create regardless of panel size, report free, panel paid in ProductClank points, and no bonus tied to the product being mentioned. It also states default duration (4 days), that dry_run charges and creates nothing, that nothing is probed via API, and that nothing is posted anywhere — exactly the side-effect and conflict-of-interest context an agent needs before a spend.

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

Conciseness4/5

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

Purpose is front-loaded in the opening clause and the operational instructions (cost, dry_run sequence) follow in a logical order. It is a dense single block with a few clauses that read as reassurance copy ('nobody on the panel is paid more when the product's name shows up', 'nothing is probed through an API'), though both do carry genuine behavioral meaning. Breaking the cost and dry_run rules into their own sentences would improve scanability.

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

Completeness4/5

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

For a 6-parameter, non-read-only tool with no output schema, the description covers the decisive facts: charge amount and when it is incurred, duration default, what the panel returns, and the dry-run preview path. What is left unstated is what the create call itself returns (check identifier, status, or a link to poll), which the agent must guess before calling get_ai_visibility_results.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter (days, models, dry_run, questions, product_id, max_participants) is already documented in the schema including defaults and limits. The description reinforces only two of them — the default 4-day window and the 'omit questions' behavior — and adds no format, range, or interaction detail beyond what the schema carries. With the schema doing the heavy lifting, the baseline 3 is appropriate.

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

Purpose4/5

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

The description states a specific action and resource: it spins up a panel of real people who ask ChatGPT/Claude (optionally Gemini, Perplexity, Grok) the product's buying questions and submit the shared chat link or screenshot. That mechanism is concrete enough to separate it from adjacent tools in the family. It never names the retrieval siblings (get_ai_visibility_results, generate_ai_visibility_report), so the boundary is implied by 'once the check ends ... the owner generates a report' rather than stated.

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

Usage Guidelines4/5

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

The description gives an explicit procedural order that matters: call with dry_run:true first to get the brief and price, show it to the user, then call again with dry_run:false only after they say yes. It also tells the agent how to handle the optional questions param (provide the buying questions the user cares about, or omit to let the panel ask in their own words). It does not name an alternative tool or a 'do not use when' case, so it stops short of a full routing rule.

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

All ProductClank tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.