# Robyn — Gasless Cross-Chain for AI Agents (remote · api.anygas.xyz)

Gasless cross-chain for AI agents: 25 nodes incl. Solana & native Bitcoin. One signature, no gas.

- Trust score: 61/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `api.anygas.xyz`: 61/100 (this document), [markdown](https://verifymcp.io/servers/ox31461-robyn/api.md), [page](https://verifymcp.io/servers/ox31461-robyn/api)
- npm · `anygas-mcp`: 63/100, [markdown](https://verifymcp.io/servers/ox31461-robyn/anygas-mcp.md), [page](https://verifymcp.io/servers/ox31461-robyn/anygas-mcp)

## Channel facts

- Endpoint: `https://api.anygas.xyz/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.5`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 51/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 47 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS not yet verified: we couldn't determine whether a plaintext access path exists.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 65/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 6317 tokens (~134/item across 47 items; 47 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 83/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 50% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http ox31461-robyn https://api.anygas.xyz/mcp
```

### Codex

```toml
[mcp_servers.ox31461-robyn]
url = "https://api.anygas.xyz/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ox31461-robyn": {
      "type": "remote",
      "url": "https://api.anygas.xyz/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add ox31461-robyn --url https://api.anygas.xyz/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ox31461-robyn:
    url: "https://api.anygas.xyz/mcp"
```

### Other

```json
{
  "mcpServers": {
    "ox31461-robyn": {
      "type": "http",
      "url": "https://api.anygas.xyz/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 61, +1)

- [functional regression] Tool coverage: 59% → 50%
- [functional regression] Schema quality: 3813 → 6317
- [functional] New tool “robyn_payment_request_settlement”
- [functional] New tool “robyn_mandate_status”
- [functional] New tool “robyn_mandate_list”
- [functional] New tool “robyn_mandate_events”
- [functional] New tool “robyn_mandate_cosign_request”
- [functional] New tool “robyn_mandate_check”
- [functional] New tool “robyn_capability_snapshot”
- [functional] New tool “robyn_integration_lint”
- [functional] New tool “robyn_changelog”
- [functional] New tool “robyn_why_this_route”
- [functional] New tool “robyn_recipes”
- [functional] New tool “robyn_preflight_full”
- [functional] New tool “robyn_payment_request_verify”
- [functional] New tool “robyn_payment_request_prepare”
- [functional] New tool “robyn_evidence_bundle”
- [functional] New tool “robyn_improve_cost”
- [functional] New tool “robyn_mandate_certificate”
- [functional] New tool “robyn_counterparty_check”

### 2026-08-02 (score 60, 0)

- [functional regression] Schema quality: 2122 → 3813
- [functional improvement] Tool coverage: 48% → 59%
- [functional] Server version: 1.0.3 → 1.1.0
- [functional] New tool “robyn_netting_reserves”
- [functional] New tool “robyn_netting_statement”
- [functional] New tool “robyn_netting_transfer_payload”
- [functional] New tool “robyn_refusal_verify”
- [functional] New tool “robyn_plan”
- [functional] New tool “robyn_verify_outcome”
- [functional] New tool “robyn_spend_statement”
- [functional] New tool “robyn_delivery_stats”
- [functional] New tool “robyn_fee_forensics”
- [functional] New tool “robyn_netting_account”
- [functional] New tool “robyn_netting_enroll_payload”
- [functional] New tool “robyn_netting_info”
- [functional] New tool “robyn_netting_preview”
- [cosmetic] “robyn_quote” added an optional parameter “fromAddress”

### 2026-08-01 (score 60, 0)

- [security] Tool “robyn_submit” rewrote its description, which is the text the model reads
- [cosmetic] “robyn_submit” added an optional parameter “dryRun”

### 2026-07-31 (score 60, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 60, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 59, 0)

- [security] Tool “robyn_cross_chain” rewrote its description, which is the text the model reads
- [functional regression] Tool coverage: 46% → 40%
- [functional regression] Schema quality: pass → fail
- [functional] New tool “robyn_submit”
- [functional] New tool “robyn_sandbox_do”
- [functional] New tool “robyn_sponsor_7702”
- [functional] New tool “robyn_prepare”
- [functional] New tool “robyn_errors”
- [functional] New tool “robyn_7702_delegate”
- [functional] New tool “robyn_7702_check”

### 2026-07-28 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 58, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

## MCP tools (47)

### `robyn_mesh` (~43 tokens)

Robyn mesh

List the Robyn gasless chains and the cross-chain route graph (22 EVM nodes + Stellar), plus the relayer/Permit2 addresses. No credentials needed.

### `robyn_quote` (~258 tokens)

Quote a gasless cross-chain route

Best gasless route to move a token from one Robyn chain to another. Returns estimated output, the bridge used, duration, and the Robyn fee. Read-only — moves nothing. IMPORTANT: check `quoteOnly` on the response. If it is true the corridor can be PRICED but NOT settled — execute will refuse it with UNSUPPORTED_DIRECTION — so present that quote as a price comparison only and do not tell the user it can be sent. `quoteOnlyReason` says why. Absent/false means executable.

Input parameters:

- `amount` (string, required): amount in fromToken base units (e.g. "25000000" = 25 USDC)
- `fromAddress` (string): sender — determines membership (fee tier) AND whether a free netting path is available between these two accounts
- `fromChain` (number|string, required): source chain id, or "stellar"
- `fromToken` (string, required): token address on the source chain (0x0000…0000 for native)
- `toAddress` (string): recipient on the destination chain
- `toChain` (number|string, required): destination chain id, or "stellar"
- `toToken` (string, required): token address / symbol on the destination

### `robyn_preflight` (~256 tokens)

Check a transfer will succeed BEFORE spending anything

Run this before robyn_prepare/robyn_submit. Returns decision GO or NO_GO plus typed `blockers` (each with a `fix`) and `warnings`. It catches, for free, the failures that otherwise cost gas: a fixed corridor fee that would consume the whole amount so nothing arrives, a recipient in the wrong address family, a corridor that can price but not settle, and a transfer above the instant lane's capacity that would silently pay a dearer bridge. Read-only — signs nothing, moves nothing. Pass fromAddress so membership (free micro-transfers) is recognised.

Input parameters:

- `amount` (string, required): amount in fromToken base units (e.g. "5000000" = 5 USDC)
- `fromAddress` (string): sender — determines membership and therefore fee tier
- `fromChain` (number|string, required): source chain id, or "solana"/"stellar"/"tron"/"bitcoin"
- `fromToken` (string): symbol or address; omit for the chain default
- `toAddress` (string): recipient — validated against the destination chain family
- `toChain` (number|string, required): destination chain id or non-EVM name
- `toToken` (string)

### `robyn_vip_status` (~122 tokens)

Check membership / VIP benefits for an address

Check whether an address holds a recognised member NFT and what it gets. Members pay ZERO on cross-chain transfers of $0.10-$25 to low-cost chains, 15bps instead of 25bps routing, and 10% instead of 25% gas markup. Read-only. Call this before quoting for a user so you can tell them accurately what a transfer will cost — and, if they are not a member, what holding a recognised NFT would save them.

Input parameters:

- `address` (string, required): EVM address (0x…) to check

### `robyn_route_status` (~39 tokens)

Track a cross-chain route

Status of an in-flight route by id (BRIDGING → DONE), with the destination tx once delivered.

Input parameters:

- `id` (string, required)

### `robyn_cross_chain` (~130 tokens)

Move value cross-chain, gasless

Plan a gasless cross-chain move and get the exact payload to sign. This hosted server never holds your key: call this, sign what it returns with your own wallet, then call robyn_submit to have the relayer broadcast it and pay the gas.

Input parameters:

- `amount` (string, required): amount in fromToken base units
- `fromChain` (number|string, required)
- `fromToken` (string, required): token address on the source chain
- `toAddress` (string)
- `toChain` (number|string, required)
- `toToken` (string, required): token address / symbol on the destination

### `robyn_prepare` (~160 tokens)

Prepare a gasless action (returns what to sign)

Turn a plain-language or structured intent into a concrete plan plus the EXACT payload to sign. Costs nothing, moves nothing, needs no key. Returns status:"sign" with signRequest, or status:"quoted" if something is still missing.

Input parameters:

- `amount` (string): base units, overrides amountHuman
- `amountHuman` (number): human units, e.g. 25 for 25 USDC
- `fromChain` (number|string)
- `intent` (string): plain language, e.g. "send 25 USDC to 0xabc... on arbitrum"
- `toAddress` (string)
- `toChain` (number|string)
- `token` (string): USDC, USDT, ETH, ...

### `robyn_sandbox_do` (~98 tokens)

Dry-run the whole flow with no funds

Runs the identical path end to end against the sandbox: no key, no funds, no broadcast. Use this to prove an integration works before touching real money.

Input parameters:

- `amount` (string)
- `amountHuman` (number)
- `fromChain` (number|string)
- `intent` (string)
- `toAddress` (string)
- `toChain` (number|string)
- `token` (string)

### `robyn_submit` (~318 tokens)

Submit your signed intent (relayer pays the gas)

Relay an intent you already signed. The relayer broadcasts it and fronts all network gas; your account needs no native token. Build `permit2` from robyn_prepare: sign its signRequest.eip712 payload (canonical Permit2 domain + PermitTransferFrom/TokenPermissions types) and pass the OBJECT below - not a bare signature string. The signed spender must be the relayer from signRequest.spender, otherwise the permit cannot be redeemed. Supply idempotencyKey so a retry after a timeout cannot double-spend. TO REHEARSE WITHOUT BROADCASTING set dryRun:true — it returns {status:"DRY", broadcast:false, wouldSend} and moves nothing, on EVERY corridor. Do NOT assume that omitting a live flag means dry: that holds on the float lane and the non-EVM legs, but the EVM-to-EVM path ignores it and BROADCASTS.

Input parameters:

- `amount` (string, required)
- `dryRun` (boolean): true = rehearse only: returns {status:"DRY", broadcast:false, wouldSend} and broadcasts NOTHING, on every corridor. Use this to preview before committing.
- `fromChain` (number|string, required)
- `fromToken` (string, required)
- `idempotencyKey` (string): any unique string; makes retries safe
- `permit2` (object, required): Permit2 SignatureTransfer object - NOT a bare signature string
- `toAddress` (string, required)
- `toChain` (number|string, required)
- `toToken` (string, required)

### `robyn_netting_info` (~111 tokens)

What netting accounts are (opt-in, custodial)

Explains the opt-in netting ledger: transfers between two ENROLLED accounts settle as a book entry — no chain, no gas, no fee, instant, at ANY size including amounts below every per-chain cost floor. CUSTODIAL — this is the ONE part of Robyn that holds your balance; every other tool here moves funds without Robyn ever holding them. Tell the user that plainly before they enrol. Read-only. Returns the caps, the published limits and the fee model.

### `robyn_netting_account` (~76 tokens)

Netting balance, enrolment state and next nonce

Whether an address is enrolled (and therefore custodied), its internal balance, recent history, and `nextNonce` — which you MUST use when signing the next transfer or withdrawal. An address that never enrolled is reported as not custodied. Read-only.

Input parameters:

- `address` (string, required): EVM address (0x…)

### `robyn_netting_preview` (~165 tokens)

What a netting withdrawal would actually deliver

Free and read-only. Given an amount, ranks EVERY exit chain by what actually arrives after the destination payout cost is deducted. Those costs differ by more than 1000x (Avalanche delivers ~$0.99994 of a dollar; Linea ~$0.927), so which chain you leave on is a real decision. Pass toChain to price one chain and learn whether it would succeed at all. Internal transfers between netting accounts remain free at any size — this cost applies only to leaving for a real on-chain balance.

Input parameters:

- `amount` (string, required): amount in USDC base units (6dp), e.g. "1000000" = $1.00
- `toChain` (number|string): price a single chain instead of ranking all

### `robyn_netting_statement` (~109 tokens)

Full, untruncated netting history for an address

Internal transfers produce NO transaction hash because no transaction occurs — this append-only journal is their only record. Never truncated; page with `before` (a seq number). Use this when a user asks to verify or dispute an internal payment, since there is no chain to check.

Input parameters:

- `address` (string, required): EVM address (0x…)
- `before` (string): return entries with seq below this, for paging
- `limit` (number): max entries (default 200)

### `robyn_netting_reserves` (~78 tokens)

Proof of reserves for the custodial ledger

Publishes what Robyn OWES across all netting accounts against the real relayer float backing it, per chain. Solvency is checkable rather than asserted. Deposits are refused if they would push liabilities above a safe share of the float. Read-only — a user considering a custodial balance should be shown this.

### `robyn_netting_enroll_payload` (~155 tokens)

Get the consent text a user must sign to open a netting account

Returns the EXACT message the account must sign with its OWN key to open a custodial balance. This endpoint holds no key and enrols nobody — it returns the text; the user signs it, then POST {address, signature} to /api/netting/enroll. CUSTODIAL — this is the ONE part of Robyn that holds your balance; every other tool here moves funds without Robyn ever holding them. Tell the user that plainly before they enrol. Show the user the full consent text before they sign it: it states that the balance is held by Robyn, is not insured, and could be lost.

Input parameters:

- `address` (string, required): the address that will own the netting account

### `robyn_netting_transfer_payload` (~150 tokens)

Build the message to sign for a FREE internal transfer

Returns the exact string to sign, with the correct next nonce, for a free instant transfer between two ENROLLED accounts. Signs nothing and moves nothing — the sender signs the returned message, then POSTs {from,to,amount,nonce,signature} to /api/netting/transfer. BOTH parties must already be enrolled: Robyn will not hold a balance for a recipient who never consented, so to pay an unenrolled address use the ordinary non-custodial route instead.

Input parameters:

- `amount` (string, required): USDC base units (6dp)
- `from` (string, required): sender (must be enrolled)
- `to` (string, required): recipient (must ALSO be enrolled)

### `robyn_counterparty_check` (~180 tokens)

Have I paid this address before?

Your OWN payment history with a recipient address: how many times, how recently, and whether this amount is typical. Call it before paying an address you have not confirmed. THIS IS NOT A REPUTATION SCORE and says nothing about whether the address is honest. A familiar address is NOT a safe address — keys get compromised. Never tell a user an address is "trusted" or "safe" on the basis of this. A `first-time-recipient` result is NOT a warning about the recipient — every legitimate relationship has a first payment. It is the moment to confirm the address through a second channel, because address substitution can only be caught before you send. Read `coverage`: float-lane payouts are NOT included, so "first time" can be wrong.

Input parameters:

- `amount` (string)
- `toAddress` (string, required)

### `robyn_preflight_full` (~205 tokens)

Everything you should know before you move money

ONE call combining serviceability, routing competitiveness, cheaper alternatives, delivery basis and mandate budget into a single go/no-go. Call this before executing rather than making five separate checks. BLOCKERS AND WARNINGS ARE DIFFERENT. `blockers` WILL fail — do not attempt the transfer. `warnings` are things to tell the user or act on first; they do not prevent execution. Never present a warning as a failure or a blocker as advice. Anything in `unavailable` means a check could NOT run: treat it as unknown, not fine. `proceed:true` means nothing known blocks it — it is not a guarantee of success.

Input parameters:

- `amount` (string, required)
- `fromChain` (number|string, required)
- `fromToken` (string)
- `mandateId` (string): check the spend against this budget too
- `toAddress` (string)
- `toChain` (number|string, required)
- `toToken` (string)

### `robyn_integration_lint` (~132 tokens)

Is the request I am about to send safe?

Post the request you INTEND to make and get back what is missing or unsafe, with the concrete consequence. Run this before your first live execute. Findings marked `unsafe` can lose money or make you report something untrue — fix them, do not proceed. IMPORTANT: it lints the REQUEST only. A clean lint does NOT mean your integration is correct — it cannot see whether you branch on all three verification verdicts or treat `undetermined` as success.

Input parameters:

- `endpoint` (string, required): the endpoint you intend to call
- `payload` (object, required): the body you intend to send

### `robyn_recipes` (~123 tokens)

The right order to call things

Ordered playbooks for real goals: pay-someone-safely, prove-what-i-spent, spend-within-a-budget, handle-failures-well, stay-current. CALL THIS BEFORE IMPROVISING A SEQUENCE. Each step says what it answers, what to do with the answer, whether it is optional, and what skipping it costs. Steps marked optional:false should not be skipped — `skippingCosts` explains the concrete harm, not a style preference.

Input parameters:

- `name` (string): a specific recipe, or omit for all

### `robyn_changelog` (~128 tokens)

What changed since I integrated?

Machine-readable API history. Pass the version your integration was built against as `since` and you get only what has changed after it, with an explicit `breaking` flag on each entry. CHECK `mustAct` FIRST: if true there are breaking changes and an existing integration may ALREADY be failing — read `entries[].action` for each. `breaking:true` means an existing correct integration could stop working; it is a compatibility claim, not a measure of importance.

Input parameters:

- `since` (string): the API version you built against, e.g. "3.9.0"

### `robyn_errors` (~43 tokens)

Error contract

The full error taxonomy: every errorCode, whether it is retryable, and the suggested recovery action. Read this once and branch on errorCode instead of parsing messages.

### `robyn_verify_outcome` (~225 tokens)

Verify a transfer against the chain

Check what ACTUALLY happened to a settled transfer, against the destination chain rather than Robyn's own database. Optionally assert who should have been paid (`recipient`) and the minimum that should have arrived (`minAmount`); we decode the payout transaction's ERC-20 Transfer logs and report whether reality matches. Also cross-checks Robyn's own receipt against the chain and says so if the books disagree. THE VERDICT IS THREE-VALUED: `verified`, `failed`, or `undetermined`. Treat `undetermined` as UNKNOWN, never as success — it means the chain was unreachable, the tx is not mined, or the rail records completion as a balance delta that cannot be re-derived (Allbridge/Chainflip/Solana/Tron). Do not tell a user a transfer is confirmed on an undetermined result.

Input parameters:

- `id` (string, required): transfer id, or the source/destination tx hash
- `minAmount` (string): minimum base units that must have arrived
- `recipient` (string): address that must have been credited

### `robyn_plan` (~132 tokens)

Validate a multi-step plan before executing any of it

Validate a WHOLE multi-step workflow up front instead of one hop at a time. Fees and durations accumulate across steps. Evaluation stops at the first unroutable step rather than reporting speculative results behind it. If the plan cannot work, the response names the BINDING CONSTRAINT and the value that would work (`bindingConstraint`, `whatWouldMakeThisWork`) — use that to adjust rather than retrying blindly. READ-ONLY: nothing is signed, reserved or moved. Use this before spending on step one.

Input parameters:

- `constraints` (object)
- `steps` (array, required): the hops, in order

### `robyn_spend_statement` (~154 tokens)

Signed proof of what was spent

A statement of every transfer in a window with each fee broken down, SIGNED by Robyn's relayer key (EIP-191). Use this when you must PROVE to a principal what you spent — your own summary is a claim by the party being audited, but this is verifiable against a published address without trusting you or Robyn. Read `limitations` and repeat them: the statement covers the Robyn float lane only and excludes other rails and the custodial netting book, so it may not be a complete picture of activity.

Input parameters:

- `address` (string): restrict to transfers whose record names this sender
- `days` (number): window length, default 30, max 365

### `robyn_fee_forensics` (~101 tokens)

Where every unit of a fee went

Reconstruct a settled transfer unit by unit: destination payout gas, Robyn margin, or a Robyn SUBSIDY where Robyn absorbed a loss. Each line names who was paid and how the figure was derived. Anything that cannot be attributed is returned as `unattributed` rather than folded into another line — if you see that field, report it rather than presenting the breakdown as complete.

Input parameters:

- `id` (string, required): settled transfer id

### `robyn_delivery_stats` (~78 tokens)

Measured delivery times

How long settlements ACTUALLY take, per rail and per corridor — not a single advertised constant. CHECK `basis`/`status`: below the sample threshold this returns `insufficient-data` and the figure is a static ESTIMATE, not a measurement. Say which you are quoting when you tell a user how long something will take.

### `robyn_mandate_events` (~104 tokens)

What has happened to my budgets

Poll for spend, nearly-exhausted, exhausted, approval-required and revoked events on a principal's mandates. Pass the returned `cursor` back as `since` for only what is new. Use this to tell a principal their budget is running low or that a large payment is waiting on their approval, instead of making them check each mandate by hand.

Input parameters:

- `limit` (number)
- `principal` (string)
- `since` (string)

### `robyn_mandate_list` (~87 tokens)

Every budget a principal has granted

List all mandates granted by a principal address, with remaining budget, co-sign threshold, expiry and revocation state. Use this before telling a user they are safe: live mandates can still be drawn against WITHOUT further approval, and a forgotten grant is the one that hurts. Anything they no longer intend to honour should be revoked.

Input parameters:

- `principal` (string, required): the principal address

### `robyn_mandate_cosign_request` (~126 tokens)

Does this spend need the principal to approve it?

For mandates with a co-sign threshold, check whether a specific spend needs the principal to approve it and get the exact digest they must sign. The digest binds the mandate, the transfer AND the amount, so an approval cannot be reused for a different payment — do not attempt to reuse one. If a large spend is refused for want of a countersignature, present the digest to the principal rather than splitting the spend to slip under the threshold.

Input parameters:

- `amount` (string, required)
- `mandateId` (string, required)
- `transferId` (string, required)

### `robyn_mandate_certificate` (~134 tokens)

Signed proof the agent stayed within its budget

A signed certificate listing every spend counted against a mandate, the budget, the total spent, and whether it stayed inside. Hand it to the principal at the end of a period. Every spend listed was VERIFIED ON-CHAIN before counting, and the amount is what the chain showed arrived — not what the agent reported. IMPORTANT WHEN PRESENTING IT: this certifies adherence to a ROBYN budget. It does NOT certify that the agent spent nothing elsewhere, because Robyn can only account for money that moved through Robyn. Do not describe it as proof of total spending.

Input parameters:

- `mandateId` (string, required)

### `robyn_mandate_check` (~135 tokens)

Does this spend fit the budget my principal set?

Check a proposed spend against a signed spending mandate BEFORE making it. Returns WITHIN_MANDATE, EXCEEDS_MANDATE or EXPIRED plus the remaining budget. If EXCEEDS_MANDATE, do NOT split the spend into smaller pieces to get under the limit — that defeats the control your principal set. Ask them to raise the budget. NOTE THE SCOPE: a mandate covers spending THROUGH ROBYN only. It is not custody and does not stop spending elsewhere with the same key.

Input parameters:

- `amount` (string, required): proposed spend in base units
- `mandateId` (string, required): the mandate digest

### `robyn_mandate_status` (~51 tokens)

How much of my budget is left?

Remaining and consumed budget for a signed mandate. Consumption counts ONLY transfers verified on-chain, so the figure cannot be inflated by claiming spends that did not happen.

Input parameters:

- `mandateId` (string, required)

### `robyn_improve_cost` (~177 tokens)

What would make this transfer cheaper?

Turns a price into a decision. Returns concrete, QUANTIFIED changes — a cheaper destination chain with the exact saving, the size at which a fixed payout cost stops dominating, whether the instant float lane applies, and whether rails that would have competed were unavailable. CRITICAL: suggestions with `changesOutcome: true` move WHERE THE MONEY LANDS. Never apply those silently as cost savings — confirm with the user that the alternative destination is acceptable first, or you will have saved gas by delivering to the wrong place. If nothing can be improved it says so rather than inventing filler.

Input parameters:

- `amount` (string, required)
- `fromChain` (number|string, required)
- `fromToken` (string)
- `toAddress` (string)
- `toChain` (number|string, required)
- `toToken` (string)

### `robyn_why_this_route` (~173 tokens)

Why this route won — and what it beat

Returns the full routing decision: every rail that quoted, what each would deliver, the margin the winner won by, and which rails stayed SILENT and why. Signed, so you can archive the rationale. CHECK `wasCompetitive` BEFORE TELLING A USER THE PRICE IS GOOD. If it is false, exactly one rail answered and "best" means "only" — it did not beat anything. Rails in `silentRails` did NOT lose; they failed to answer (down, rate-limited, missing credentials). Never describe them as more expensive.

Input parameters:

- `amount` (string, required)
- `fromChain` (number|string, required)
- `fromToken` (string)
- `toAddress` (string)
- `toChain` (number|string, required)
- `toToken` (string)

### `robyn_capability_snapshot` (~171 tokens)

What Robyn can actually do right now (signed)

A signed, timestamped record of current capability: which chains can actually be PAID OUT ON right now, which are merely policy-eligible, which rails are execute-ready, and whether delivery figures are measured or estimated. USE `serviceableNow`, NOT `policyEligible`, when deciding where to send funds — a chain can be eligible by policy while holding no inventory, in which case the instant lane is unavailable and the transfer falls through to a bridge rail. `notServiceable` lists the difference. Fetch this BEFORE committing to a multi-step plan and keep it with your decision: if the plan later fails you can show what you were told. It is a RECORD, not a guarantee — it does not promise the same capability a minute later, and the signature does not make it an SLA.

### `robyn_evidence_bundle` (~198 tokens)

One signed bundle of all evidence about a transfer

Assembles EVERYTHING about a settled transfer in one call: the on-chain verification, the unit-by-unit fee breakdown, what the alternative route would have cost, and whether the delivery time is measured or estimated — signed as a whole. This is the artefact to hand to a principal who was not there; swapping any component invalidates the signature. READ `verdict` BEFORE PRESENTING IT: the bundle verdict is the WEAKEST of its parts. A complete fee breakdown does not mean the transfer was confirmed — if `verdict` is `undetermined`, settlement was NOT verified and you must not describe it as complete. Components that could not be produced appear as `unavailable` with a reason; check `incomplete`.

Input parameters:

- `id` (string, required): settled transfer id
- `minAmount` (string): assert the minimum that should have arrived
- `recipient` (string): assert who should have been paid

### `robyn_payment_request_prepare` (~151 tokens)

Prepare a payment request for the payee to sign

Build a canonical payment request (payee, chain, token, amount, memo, expiry) and return the digest for THE PAYEE to sign with their own wallet. Robyn does not sign these and holds no payee keys — a request signed by Robyn would prove nothing about the payee. Use this when an agent needs to ASK another agent for money in a way the payer can actually check.

Input parameters:

- `amount` (string, required): base units
- `chain` (number|string, required): destination chain id or name
- `expiresInSec` (number)
- `memo` (string)
- `payee` (string, required): address that should be paid
- `token` (string)

### `robyn_payment_request_verify` (~134 tokens)

Verify a payment request before paying it

ALWAYS run this before paying a request you received. It confirms the payee address, chain, token and amount were signed by whoever controls the payee address, and that the request has not expired. If `signedByPayee` is false, DO NOT PAY — that is what an altered payee address looks like, and address substitution is the most common theft in this space. A valid signature proves AUTHENTICITY, not that the payment is owed and not that the payee is trustworthy.

Input parameters:

- `request` (object, required): the canonical request object
- `signature` (string, required): the payee signature

### `robyn_payment_request_settlement` (~95 tokens)

Prove a payment request was satisfied on-chain

After paying, prove it: re-checks the transfer against the DESTINATION CHAIN and confirms the payee was paid at least the amount requested. Returns paid=true only on a verified on-chain result; paid=null means undetermined, which is NOT evidence you satisfied the request.

Input parameters:

- `request` (object, required)
- `signature` (string, required)
- `transferId` (string, required): the transfer that paid it

### `robyn_refusal_verify` (~128 tokens)

Verify a refusal receipt

Check a signed refusal receipt. Send header `x-anygas-receipt: 1` on any request and, IF Robyn refuses it, the error response carries a signed `refusalReceipt` recording what was asked, when, and why. This matters because when a provider says no, the AGENT gets the blame — a receipt lets you prove to your principal that you were blocked externally rather than simply failing. It proves the refusal HAPPENED; it does not claim the refusal was correct.

Input parameters:

- `receipt` (object, required): the full refusalReceipt object as returned

### `robyn_7702_delegate` (~67 tokens)

EIP-7702 delegate + rail info

The canonical Robyn EIP-7702 batch-executor delegate: its address on each of the 22 EVM chains, the ABI, and the EIP-712 scheme for executeSigned. Delegate to this and the relayer can sponsor your transactions. Read-only.

### `robyn_7702_check` (~73 tokens)

Verify an EIP-7702 authorization

Check that a signed EIP-7702 authorization tuple recovers the expected account, and whether its nonce matches the live account nonce. Free, read-only, moves nothing.

Input parameters:

- `authorization` (object, required): the signed 7702 authorization tuple
- `chainId` (number, required): chain the authorization targets

### `robyn_sponsor_7702` (~143 tokens)

Sponsor a transaction (relayer pays the gas)

Price or request an EIP-7702 sponsored transaction: Robyn submits your signed authorization as a type-4 transaction and PAYS THE GAS, so your account needs no native token. Over this HOSTED endpoint the call is a DRY price-check (returns estGas, priceUsd and the exact envelope) — paying the x402 invoice to broadcast requires calling POST /api/7702/sponsor directly with an X-PAYMENT header.

Input parameters:

- `authorization` (object, required)
- `chainId` (number, required)
- `data` (string): calldata hex
- `to` (string): call target (defaults to the delegated account itself)

### `robyn_yield_account` (~91 tokens)

Non-custodial yield account

An agent's own Aave v3 / Moonwell position (aUSDC/mUSDC) per chain + the capped allowance it granted the relayer + live APY (best-yield auto-selected). Non-custodial: funds stay in the agent's wallet, Robyn holds no key and no pool.

Input parameters:

- `agent` (string, required): the agent wallet address (0x…)

### `robyn_yield_quote` (~98 tokens)

Quote a spend from yield

Read-only JIT quote: how a spend would be fulfilled from an agent's Aave yield venue (draw <= your allowance -> Aave/Moonwell withdraw -> gasless deliver). Moves nothing.

Input parameters:

- `agent` (string, required)
- `amount` (string, required): USDC base units (6dp)
- `srcChain` (number|string, required)
- `toAddress` (string)
- `toChain` (number|string)

### `robyn_yield_spend` (~212 tokens)

Spend from yield (one signature)

Spend from your yield (Aave v3 or Moonwell) with ONE EIP-712 signature: Robyn pulls only up to your on-chain aUSDC/mUSDC allowance, unwinds exactly what is needed, and delivers gaslessly; the remainder keeps earning. This HOSTED endpoint is READ-ONLY: it returns the exact EIP-712 intent to sign + a live quote. To execute, sign it and POST {intent,signature,live:true} to /svc/api/ncaccount/spend, or run `npx anygas-mcp` locally with ROBYN_SIGNER_KEY. One-time setup: supply USDC to Aave v3 or Moonwell in your wallet + approve the relayer for your aUSDC/mUSDC up to your risk budget.

Input parameters:

- `agent` (string, required)
- `amount` (string, required)
- `srcChain` (number|string, required)
- `toAddress` (string)
- `toChain` (number|string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/ox31461-robyn/api#diagnostics

## Score history

- 2026-08-03: 61
- 2026-08-02: 60
- 2026-08-01: 60
- 2026-07-31: 60
- 2026-07-30: 60
- 2026-07-29: 59
- 2026-07-28: 59
- 2026-07-27: 58
- 2026-07-26: 58

## Links

- Remote endpoint: https://api.anygas.xyz/mcp
- Repository: https://github.com/ox31461/Gasless-Anygas-ROBYN-Relay
- Website: https://api.anygas.xyz/
- Changelog RSS feed: https://verifymcp.io/servers/ox31461-robyn/api/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/ox31461-robyn/api/changelog.json
- HTML version of this page: https://verifymcp.io/servers/ox31461-robyn/api