CULT+MATH Decision Briefs

Is this claim already taken by a competitor?

run_claim_check

Read-onlyIdempotent

Use when the user is choosing a positioning, a tagline or a message and asks whether competitors already say it, whether a claim is crowded or open, or who has moved onto it recently. Reads each competitor's home page today and its Internet Archive copy from a year ago, and returns, per site, whether it leads with the claim, mentions it, or does not, and whether that changed this year, with a verdict: open, mentioned but not owned, taken, or crowded. No page text is returned. Safe to cite: its controls are checked first, it states its limits, and every result carries a run id, a date and a citation line. If a control fails it refuses and you are not charged. This tool charges nothing: it validates the request and returns a payment_url, the price and instructions. Pay by POSTing to payment_url over MPP (HTTP 402, a Stripe shared payment token from your wallet). Price: $3.00 per run, charged only when the run comes back sound; pay over MPP (a Stripe shared payment token) or x402 (USDC on Base, no account needed). A real sample of this run, free: https://cultmath.com/agent/samples/claim-check.json

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": {
      "claim": "<claim>",
      "sites": "<sites>"
    },
    "name": "run_claim_check"
  }
}

Input Schema

Name	Required	Description
`claim`	Yes	The claim as a buyer would read it, e.g. "plant-based protein".
`sites`	Yes	3-5 competitor domains, comma-separated.
`variants`	No	Optional: up to 3 other wordings, comma-separated.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the data sources (today's home page plus an Internet Archive copy from a year ago), the return shape (leads with, mentions, does not mention, and whether that changed), and the verdict taxonomy. It also explains control checks, refusal behavior when controls fail, no-charge semantics, run IDs, dates, citation lines, and the two-step payment flow. The line 'This tool charges nothing' followed by a $3 price is potentially confusing, but the subsequent explanation clarifies that the initial call only returns a payment_url and the charge applies to the actual run.

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?

The description is front-loaded with the usage scenario and return behavior, which is the right structure for an agent deciding whether to call it. It is somewhat long and includes some marketing-adjacent phrasing and repeated MPP/Stripe payment details, but most of that information is relevant for a paid tool.

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

Completeness5/5

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

There is no output schema, so the description must explain return values, and it does: per-site classifications, year-over-year change, verdict categories, no page text, and citation/run metadata. It also covers payment mechanics and failure behavior, leaving little an agent needs to know before invoking the tool.

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 all three parameters are already documented in the input schema, including the claim example and the 3-5 domain constraint. The description does not add syntax or meaning beyond that schema, such as how variants interact with the primary claim, so the baseline score is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: it reads competitors' home pages and archived copies to determine whether a claim is already taken. It also names the exact deliverable—per-site categorization and an open/mentioned/taken/crowded verdict—so an agent can distinguish it from sibling checks like run_disclosure_check or run_fad_check.

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?

It gives clear triggering conditions: use when the user is choosing positioning, tagline, or message and asks whether competitors already say it or whether a claim is crowded. It does not explicitly name sibling alternatives or state when not to use it, which keeps it just below the top score.

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

All CULT+MATH Decision Briefs 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.

Resources

Need Help?