Hearth: x402 Pay-Safety & Discovery

route

Read-only

Buy any x402 API through Hearth (standard: sellers up to $0.008). One call, any capability: describe what you need (q) and optional input (params JSON). Hearth classifies the intent (search, scrape, llm, image, enrich, onchain, price, social, geo, audio, security…), ranks verified x402 sellers by real paying usage, Hearth's own purchase outcomes, nightly free liveness probes and public reputation (402index reliability, vet402 verdicts and settlement, x402-trust grades), runs its pay-safety precheck (only 'pay'; payTo must match the verified listing; canonical USDC on Base), pays the seller from Hearth's wallet and returns the seller's response plus provenance. Flat $0.01; covers sellers up to $0.008. Not charged unless you get a result. Free preview: /v1/free/route?q=... Example output: {"schema":"hearth.route.v1","category":"search","seller":{"url":"https://seller.example/api/search","priceUsd":0.005,"payTo":"0x…","precheckScore":90,"rankScore":6.2,"tx":"0x…"},"contentType":"application/json","result":{"results":[]},"hearthPriceUsd":0.01}. Price: $0.01 USDC on Base via x402 (pass the payment in _meta["x402/payment"]).

Input Schema

Name	Required	Description
`q`	Yes	What you need, in plain words
`url`	No	Optional: a specific listed x402 seller URL to buy from
`params`	No	JSON object passed to the seller (query string for GET, body for POST)
`category`	No	Optional category override: search, scrape, llm, image, enrich, onchain, price, social, weather, geo, audio, security

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "Optional category override: search, scrape, llm, image, enrich, onchain, price, social, weather, geo, audio, security",
+  "type": "string"
+}

AddedOct 31, 2026

TDQS

B3.4/5.0

Behavior1/5

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

The description says the tool buys APIs, pays the seller from Hearth's wallet, charges $0.01, and requires x402 payment in _meta. That is a financial side effect, but annotations declare readOnlyHint=true. This is a direct contradiction, overriding the otherwise rich behavioral detail.

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

Conciseness3/5

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

It is front-loaded with the core purpose and includes a helpful output example, but the body is a dense run-on with long parenthetical lists and repeated pricing details. It is information-rich but not crisply structured.

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?

For a complex paid routing tool, the description covers intent classification, seller ranking, precheck rules, payment mechanics, pricing, free preview, and an example output. Even without an output schema, the return shape is illustrated well enough for an agent to understand what to expect.

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

Parameters4/5

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 useful meaning beyond the schema: q is natural-language intent, params are passed to the seller as GET/POST input, url selects a specific seller, and category overrides classification.

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 verb and resource: buy any x402 API through Hearth. It clearly explains the orchestration flow (classify intent, rank sellers, precheck, pay, return response), though it does not explicitly distinguish itself from route_plus.

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 a clear usage context: describe what you need via q, optionally specify a seller URL, params, or category override, and notes a free preview endpoint. It lacks explicit when-not guidance or named alternatives such as route_plus or x402_discover.

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

All Hearth: x402 Pay-Safety & Discovery 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?