Sentinel

Broadcast a USDC transfer you signed, with our gas (paid, x402)

relay_usdc

PAID: send USDC from a wallet that holds no ETH. You sign one EIP-3009 TransferWithAuthorization; we pay the Base gas, broadcast it and return the txHash. $0.0200 an order, ceiling 100000000 atomic USDC ($100). We never hold or need a key of yours -- we hold only the ETH that pays for the write. Every refusal (bad signature, closed window, value over the ceiling, self-send) is free and before the paywall: we never charge for a transaction we did not send, and a box whose gas key cannot fund one broadcast refuses free rather than taking your fee. A repeated payment buys another broadcast -- there is nothing to extend, and each order needs its own unused nonce. Call it once without payment to receive the price as an x402 PaymentRequired (Base USDC, and Solana USDC where offered); call it again with a signed payment in _meta['x402/payment'] to complete it. The receipt comes back in _meta['x402/payment-response']. No account, no API key. Complaints, questions, quote requests, or a service you wish we had: POST /feedback on this host -- free, no account. Every report is read and analysed daily; there is no individual reply.

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": {
      "from": "<from>",
      "to": "<to>",
      "value": "<value>",
      "validAfter": "<validAfter>",
      "validBefore": "<validBefore>",
      "nonce": "<nonce>",
      "signature": "<signature>"
    },
    "name": "relay_usdc"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Recipient of the USDC. Must differ from `from` -- a self-send is a free 400.
`from`	Yes	The USDC holder who signed. The signature must recover to exactly this address, e.g. 0x2222222222222222222222222222222222222222.
`nonce`	Yes	32 bytes of hex, unused before: USDC itself rejects a reused one, so each order needs its own.
`value`	Yes	Atomic USDC (6 decimals) as a decimal string, 1..100000000 ($100 ceiling an order).
`signature`	Yes	Your EIP-712 TransferWithAuthorization signature over chainId 8453, verifyingContract 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 (Base USDC). A refusal returns details.expected with the exact struct and domain.
`validAfter`	Yes	Unix seconds, as a string; must already have passed.
`validBefore`	Yes	Unix seconds, as a string; at least 30s out, so the broadcast lands inside your window.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare the mutation/safety profile; the description adds substantial behavior the agent could not otherwise know: $0.0200 per order, a 100000000 atomic USDC ceiling, free pre-paywall refusals for bad signature/window/ceiling/self-send, no-charge guarantees, a gas-key failure mode that refuses rather than charging, and the fact that a reused nonce is rejected by USDC itself. It also discloses there is no account or API key and where the payment receipt appears.

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 core is well front-loaded -- paid broadcast, pricing, refusal policy, payment handshake all arrive in order. But the closing two sentences about a /feedback endpoint and daily report analysis are unrelated to invoking this tool and consume real space, and some refusal language is restated more than once.

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

Completeness4/5

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

For a seven-required-parameter mutation tool with no output schema, the description supplies the return shape (txHash plus receipt in _meta['x402/payment-response']) and the full payment handshake, which is what an agent most needs. The only gap is that failure payloads are described only in general terms ('a refusal returns details.expected'), which the schema partially covers.

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 seven parameters are already documented in the schema, including the nonce uniqueness rule, the value ceiling, and the EIP-712 domain. The description reinforces the ceiling and per-order nonce but adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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 opening sentence names the exact verb and resource: broadcast a USDC transfer the caller has already signed, with the service paying Base gas, returning a txHash. It also states the discriminating condition -- the wallet holds no ETH -- which separates it from a normal payment sender like pay_send.

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?

The two-call x402 flow is spelled out concretely: call once with no payment to receive a PaymentRequired price, then call again with a signed payment in _meta['x402/payment']. It also states what is free (refusals before the paywall) and that a repeat payment buys a new broadcast rather than an extension. It stops short of explicitly naming sibling alternatives such as pay_send or execute.

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

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