402Signal

route

402Signal is the independent check an AI agent makes right before spending. It finds the strongest x402 route across Base, Solana, and Algorand, verifies it live, and shows the evidence behind the choice. Your agent keeps the wallet. The decision history is committed to an append-only log with Falcon PQ anchoring on Algorand (currently TestNet).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	Optional https URL to probe instead of discovery. need or url (or both) is required.
`need`	No	What the caller wants routed (plain English).
`policy`	No	Natural-language constraints compiled into structured values. Unresolved phrases are returned, never guessed.
`networks`	No	Hard policy lock. Restricts discovery and selection to this set. A HTTP 200 winner must have selected_payment.network in this set from the CURRENT observed 402, never a catalog claim. Unlike prefer_network, this is not a ranking preference.
`objective`	No	Best-of-N among currently probed eligible candidates, not every discovered endpoint. cheapest, fastest, and most_reliable rank that probed survivor set. fastest is this-request probe RTT, not settlement latency. fastest_settlement is a separate settlement/finality objective. lowest_total_cost fails closed when a fee is unknown.
`search_depth`	No	standard: first 3 then expand 2-4 (typical cap 7). thorough may expand further. Hard server ceiling is 20.
`max_price_usd`	No	Drop live hits whose known normalized USD exceeds this bound. Unknown USD fails closed.
`max_latency_ms`	No	Compatibility alias for max_probe_latency_ms (this request's probe RTT). Unknown latency fails closed.
`prefer_network`	No	Weak ranking preference only. Ranks this pay-in rail first but still searches and selects across all supported rails. Not a filter. Use networks for a hard policy lock.
`min_observations`	No	Require history n_7d at least this large. Unknown or smaller fails closed.
`max_amount_atomic`	No	Drop live hits whose known atomic amount exceeds this bound. Unknown or cross-asset amount fails closed.
`require_invocable`	No	If true, drop live hits without an input schema.
`max_total_cost_usd`	No	Merchant price plus known fees. Unknown fee fails closed.
`accept_payTo_change`	No	If true, allow selecting a destination whose payTo just changed for the first time. Default false: the first unexpected payTo change is not selectable; a second later independent observation of the same destination can establish it.
`max_probe_latency_ms`	No	Drop live hits whose known probe RTT exceeds this bound. Not historical service/p50 latency.
`min_observed_success`	No	Require observed success_7d when n_7d >= 3. Unknown fails closed.
`min_reputation_score`	No	Require V1 reputation_score. Unknown fails closed. Never guessed from vague NL.
`require_transparency`	No	If true, paid /route fails when a signed checkpoint receipt cannot be produced. Default false: routing continues if signing or anchoring is down.
`max_service_latency_ms`	No	Drop live hits whose historical p50 latency exceeds this bound. Unknown p50 fails closed.
`max_candidates_to_probe`	No	Requested probe cap, hard-capped at 20.
`max_settlement_latency_ms`	No	Settlement/finality bound. Not probe RTT. Unknown fails closed.
`min_reputation_confidence`	No	Require reputation_confidence. n_7d < 10 is low confidence.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No
`live`	No
`tried`	No
`target`	No
`changes`	No
`payable`	No
`compared`	No
`pq_trust`	No
`invocable`	No
`objective`	No
`latency_ms`	No
`reputation`	No
`miss_reason`	No
`stop_reason`	No
`probed_count`	No
`probe_ceiling`	No
`schema_source`	No
`unprobed_count`	No
`discovered_count`	No
`selected_payment`	No
`candidates_probed`	No
`discovery_matches`	No
`unmet_constraints`	No
`challenge_observed`	No
`applied_constraints`	No
`evaluation_complete`	No
`candidates_considered`	No
`candidates_discovered`	No
`probe_budget_exhausted`	No
`unresolved_constraints`	No
`interpreted_constraints`	No
`candidate_evaluation_complete`	No

TDQS

B3.2/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden. It provides meaningful behavioral context beyond the schema: the check is live, evidence is shown, the agent keeps custody of the wallet, and decision history is committed to an append-only log with Falcon PQ anchoring. It still omits some operational details such as authentication, paid-route behavior, or side effects, but it discloses substantial non-obvious behavior.

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?

The description is reasonably short and not bloated, but it reads as value-proposition copy rather than structured operational guidance. It does not front-load the most decision-relevant fact for selecting the tool, such as 'given a need or URL, return a verified route.' It is acceptable, but not tight instruction.

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

Completeness2/5

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

For a 22-parameter tool with no annotations and sibling tools to disambiguate against, the description is thin on operational context. It never explains how to choose route over preview/validate, how the need/url requirement works at a high level, or what makes a route 'strongest.' The output schema reduces some burden, but the missing usage context is still significant.

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?

The input schema already covers all 22 params with detailed descriptions, so the baseline is 3. The tool description adds no parameter-level guidance, but the schema itself is rich enough that no compensation is needed.

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 goes beyond the name by saying the tool 'finds the strongest x402 route' across Base, Solana, and Algorand, 'verifies it live,' and 'shows the evidence.' That is a clear verb+resource. It does not explicitly distinguish itself from sibling tools preview and validate, so it loses the fifth point.

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

Usage Guidelines2/5

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

There is no explicit guidance about when to call route versus preview or validate. The 'right before spending' clue implies payment-time use, but it is not framed as a decision rule or contrasted with sibling tools. An agent is left to infer when this tool is the right choice.

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

All 402Signal tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

preview and validate both describe unpaid, non-charging preflight checks that report claimed vs observed, so an agent could initially confuse which one to call for catalog discovery versus SSRF validation. route is clearly distinct as the live, evidence-generating paid check.

Naming Consistency4/5

All tool names are lowercase single words, so the style is consistent and predictable. However, preview, route, and validate are terse and do not indicate their target resource or domain, making them less self-describing than a verb_noun convention.

Tool Count5/5

Three tools is well-scoped for this purpose: one for catalog preflight, one for live route verification, and one for URL/SSRF safety validation. Each tool covers a distinct stage without noticeable redundancy.

Completeness4/5

The set covers the key pre-spend workflow: preflight discovery, live route verification, and seller URL validation. Minor gaps exist, such as no tool to query the committed decision history or explicitly execute a payment, but the core verification surface is coherent.

Resources

Need Help?