PaidRouter

Watch routes

watch_routes

Tell PaidRouter which routes the owner uses (e.g. stripe_card, paypal_checkout, venmo_business, or a corridor like USD->MXN). From then on, any PaidRouter answer to this key starts with 'Since your last call, routes you watch changed: ...' when a fee or the best FX provider moved. Optionally give an https webhook_url: when the daily check finds a change on a watched route, PaidRouter POSTs {event: 'fee_changes', changes: [...]} to it, signed with HMAC-SHA256 of the raw body using your PaidRouter key as the secret, hex in the x-paidrouter-signature header (sha256=...). Each call replaces the list; send an empty list to stop watching. Up to 50 routes.

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": {
      "routes": "<routes>"
    },
    "name": "watch_routes"
  }
}

Input Schema

Name	Required	Description	Default
`routes`	Yes	Route ids (stripe_card), platform/method (stripe/card_online) or corridors (USD->MXN)
`webhook_url`	No	https URL to POST changes to (optional)

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully carries behavioral disclosure: it states that each call replaces the previous list, that an empty list stops watching, the maximum of 50 routes, and the daily check cadence. It further details the webhook behavior, including the exact POST body shape, HMAC-SHA256 signing of the raw body, the header name x-paidrouter-signature, and the sha256= prefix format.

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 primary action and effect, then follows with webhook and revocation details. It is dense but each sentence earns its place by adding operational detail. The single-paragraph format makes the signing and payload details slightly harder to scan than they could be.

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 or annotations, so the description must carry the full burden, and it does: it explains the persistent effect on future answers, webhook delivery and signing, replacement semantics, and the route limit. An agent has enough information to invoke the tool correctly and understands the side effects and downstream behavior.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful clarification that route values can be route ids, platform/method pairs, or corridors like USD->MXN, and that webhook_url is optional and must be an https URL. It also explains the replacement semantics of the routes array, which the schema alone does not convey.

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: 'Tell PaidRouter which routes the owner uses' to set up ongoing watches. It gives concrete examples of route identifiers and corridors (stripe_card, paypal_checkout, USD->MXN), making the scope unambiguous. It is clearly distinct from sibling tools like get_fees or compare_send_money, which are one-off queries rather than persistent subscriptions.

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 explains the trigger context: use this to make future answers include 'Since your last call, routes you watch changed' when fees or FX providers move. It also explains how to stop watching by sending an empty list. However, it does not explicitly name alternatives or say when not to use it versus one-off tools such as get_fees.

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

All PaidRouter 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?