Skip to main content
Glama

402Signal

route

402Signal checks x402 routes across Base, Solana, and Algorand before spending. $0.003 only when a valid live route is found. Normal typed misses are not settled. Seller payment is separate. Your agent keeps the wallet. Routing evidence enters the PQ Trust log on Algorand MainNet. Optional require_route_binding=true adds a signed v4 receipt for buyer-side comparison with current seller terms before signing. Guide: https://402signal.com/developers#route-binding

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOptional https URL to probe instead of discovery. need or url (or both) is required.
needNoWhat the caller wants routed (plain English).
policyNoNatural-language constraints compiled into structured values. Unresolved phrases are returned, never guessed.
networksNoHard 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.
objectiveNoBest-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_depthNostandard: first 3 then expand 2-4 (typical cap 7). thorough may expand further. Hard server ceiling is 20.
max_price_usdNoDrop live hits whose known normalized USD exceeds this bound. Unknown USD fails closed.
max_latency_msNoCompatibility alias for max_probe_latency_ms (this request's probe RTT). Unknown latency fails closed.
prefer_networkNoWeak 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_observationsNoRequire history n_7d at least this large. Unknown or smaller fails closed.
max_amount_atomicNoDrop live hits whose known atomic amount exceeds this bound. Unknown or cross-asset amount fails closed.
require_invocableNoIf true, drop live hits without an input schema.
max_total_cost_usdNoMerchant price plus known fees. Unknown fee fails closed.
accept_payTo_changeNoIf 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_msNoDrop live hits whose known probe RTT exceeds this bound. Not historical service/p50 latency.
min_observed_successNoRequire observed success_7d when n_7d >= 3. Unknown fails closed.
min_reputation_scoreNoRequire V1 reputation_score. Unknown fails closed. Never guessed from vague NL.
require_transparencyNoIf true, a settled /route winner fails when a signed checkpoint receipt cannot be produced. This requires delivery of verifiable evidence on HTTP 200, not server-side recovery. To verify the routing decision later, securely retain the complete paid /route response, especially pq_trust.transparency.receipt and pq_trust.transparency.reveal. Private replay outcomes can retain the reveal; they are not a recovery service. Keep your own copy. Modified evidence fails verification against the public log. Default false (SEC-ROUTER-004 / A-14): a settled winner does not require a durable signed leaf. A free typed miss creates no route-decision leaf. Routing continues if append, signing, or anchoring is down after settlement (logged_uncheckpointed or unavailable). logged_uncheckpointed is never success when this flag is true. require_route_binding=true also requires transparency, even if this flag is false. A required receipt failure after settlement still reports billing.settled=true; unavailable does not prove no append occurred.
require_route_bindingNoOpt in to proof_carrying_route_v1 and a signed v4 receipt. Requires exact x402 v2 terms observed on the same HTTPS URL, method and probe body, without redirects or unresolved policy. Unprovable binding is a free typed miss. Implies require_transparency; a receipt failure after settlement still reports settled=true. Buyer must verify with a pinned log key and recheck the actual seller challenge immediately before signing. Preserve raw response JSON. The default 60-second freshness window starts at observation, not receipt issuance. Expiry or a changed seller challenge does not undo a settled routing fee. Default false; existing requests keep the v3 receipt path. This is not a payment authorization. Guide: https://402signal.com/developers#route-binding
max_service_latency_msNoDrop live hits whose historical p50 latency exceeds this bound. Unknown p50 fails closed.
max_candidates_to_probeNoRequested probe cap, hard-capped at 20.
max_settlement_latency_msNoSettlement/finality bound. Not probe RTT. Unknown fails closed.
min_reputation_confidenceNoRequire reputation_confidence. n_7d < 10 is low confidence.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
liveNo
triedNo
targetNo
billingYes402Signal routing-fee outcome. Seller payment is separate.
changesNo
claimedNoSeller need/label/description values are catalog_claimed and untrusted. Do not concatenate them into system prompts.
payableNo
comparedNo
pq_trustNoTo verify the routing decision later, securely retain the complete paid /route response, especially pq_trust.transparency.receipt and pq_trust.transparency.reveal. Private replay outcomes can retain the reveal; they are not a recovery service. Keep your own copy. Modified evidence fails verification against the public log.
invocableNo
objectiveNo
latency_msNo
reputationNo
miss_reasonNo
stop_reasonNo
probed_countNo
binding_errorNo
probe_ceilingNo
schema_sourceNo
unprobed_countNo
decision_bindingNoOpt in to proof_carrying_route_v1 and a signed v4 receipt. Requires exact x402 v2 terms observed on the same HTTPS URL, method and probe body, without redirects or unresolved policy. Unprovable binding is a free typed miss. Implies require_transparency; a receipt failure after settlement still reports settled=true. Buyer must verify with a pinned log key and recheck the actual seller challenge immediately before signing. Preserve raw response JSON. The default 60-second freshness window starts at observation, not receipt issuance. Expiry or a changed seller challenge does not undo a settled routing fee. Default false; existing requests keep the v3 receipt path. This is not a payment authorization. Guide: https://402signal.com/developers#route-binding
discovered_countNo
selected_paymentNo
candidates_probedNo
discovery_matchesNo
unmet_constraintsNo
challenge_observedNo
applied_constraintsNo
evaluation_completeNo
candidates_consideredNo
candidates_discoveredNo
probe_budget_exhaustedNo
unresolved_constraintsNo
interpreted_constraintsNo
candidate_evaluation_completeNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose key behaviors: the $0.003 charge only on valid live routes, typed misses not settled, seller payment separate, wallet custody retained by the agent, and routing evidence written to the PQ Trust log. It does not explicitly mention that network probes are performed or that the tool is not a payment execution, leaving some behavioral ambiguity.

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 a compact paragraph that front-loads the core action and then covers pricing, settlement, custody, and evidence. Some clauses duplicate parameter descriptions (route binding) and are arguably unnecessary, but overall it is economical and readable.

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

Completeness3/5

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

For a 23-parameter tool with no annotations, the description provides useful high-level context (networks, billing, evidence, custody) but omits the overall workflow, explicit side effects (probing external URLs), and any guidance on when to use this tool rather than siblings. The presence of an output schema mitigates the return-value gap, but the missing usage and side-effect context keeps this below complete.

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 the baseline is 3. The description only echoes one parameter (require_route_binding) and adds no new meaning for the other 22 parameters. Parameter semantics are therefore fully covered by the schema, not by the description.

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 concrete action ('checks x402 routes') with a clear scope (Base, Solana, Algorand) and context ('before spending'). However, it doesn't explicitly say what the tool returns or how it differs from the sibling tools preview and validate, so the purpose is clear but not fully differentiated.

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 guidance about when to call route versus preview or validate. The only hint is 'before spending,' which is implicit and not actionable enough to select this tool over alternatives. It also doesn't state prerequisites or conditions that should trigger a call.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly separated purpose: preview does non-probing catalog discovery, validate probes seller readiness without charging, and route performs a paid live x402 route check. The descriptions explicitly contrast probe vs non-probe and paid vs unpaid, so an agent should not confuse them.

Naming Consistency5/5

All three tools are lowercase single-word verbs in a consistent imperative style: preview, route, validate. The naming is uniform and predictable, even though the tools do not follow a verb_noun pattern.

Tool Count5/5

Three tools is a reasonable, well-scoped size for this narrow pre-payment routing service. Each tool covers a distinct step in the workflow and earns its place without redundancy.

Completeness5/5

The tool set covers the core workflow: catalog preflight with preview, seller readiness probing with validate, and live route verification with route. The descriptions note that seller payment is separate, so no critical payment execution tool is missing from this server's intended scope.

Resources