# Relaystation (remote · api.relaystation.ai)

Pay-per-call agent infrastructure: file storage & handoff, compute tools, messaging, e-sign, KYC.

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

## Components

- remote · `api.relaystation.ai`: 72/100 (this document), [markdown](https://verifymcp.io/servers/ai-relaystation-relaystation/api.md), [page](https://verifymcp.io/servers/ai-relaystation-relaystation/api)

## Channel facts

- Endpoint: `https://api.relaystation.ai/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## 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-04.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 58/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 2893 tokens (~206/item across 14 items; 14 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 69/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 8% of tool parameters carry a description.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http ai-relaystation-relaystation https://api.relaystation.ai/mcp
```

### Codex

```toml
[mcp_servers.ai-relaystation-relaystation]
url = "https://api.relaystation.ai/mcp"
```

### opencode

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

### OpenClaw

```bash
openclaw mcp add ai-relaystation-relaystation --url https://api.relaystation.ai/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  ai-relaystation-relaystation:
    url: "https://api.relaystation.ai/mcp"
```

### Other

```json
{
  "mcpServers": {
    "ai-relaystation-relaystation": {
      "type": "http",
      "url": "https://api.relaystation.ai/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-04 (score 72, +1)

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

### 2026-08-02 (score 71, +1)

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

### 2026-07-31 (score 70, +5)

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

### 2026-07-29 (score 65, +1)

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

### 2026-07-28 (score 64, +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 63, 0)

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

### 2026-07-26 (score 63)

First indexed and scored.

## MCP tools (14)

### `ask_operator` (~246 tokens)

Send a question to the human operator via their Telegram and wait for their reply. Use when you need a decision, approval, or clarification you can't infer from the conversation. The operator gets a Telegram notification on their phone; their reply comes back to you here. Typical reply latency: 1-15 minutes when operator is away from desk; ~10 seconds when at-desk. Cost: $0.005 above the daily free tier (5 free/day). If the operator has disabled the bridge ("at desk"), this returns immediately with a 'use in-IDE interaction' hint — fall through to the host IDE's chat surface. For long messages (>4KB), use ask_operator_email (needs an OAuth-linked email address — wallet-only customers should attach a Baton instead) or attach a Baton via attached_baton_id (saves the long content as a re-readable workspace; $0.01). ASK = blocks until the operator replies (vs notify_operator = one-way, no reply). Example: ask_operator {message:'Deploy to prod now?'}

Input parameters:

- `attached_baton_id` (string)
- `max_wait_seconds` (integer)
- `message` (string, required)

### `message_agent` (~197 tokens)

Send a message to another Relaystation agent's ephemeral address (format <local_part>@courier.relaystation.ai). Same-Relaystation routing only (v2 launch); external domains return EXTERNAL_DOMAIN_NOT_SUPPORTED_V2. Free — agent-to-agent traffic has no per-message cost (subject to the recipient's per-address inbox quota; default 100 messages within the 30-day retention window). Use for multi-agent coordination: delegating subtasks, sharing context, building chains. For ongoing coordination involving 30+ messages, prefer a shared LEDGER or SCRATCHPAD Baton (better search/audit/verification at $0.01 setup). Example: message_agent {to_address:'agent-7@courier.relaystation.ai', body:'Status update: task ready'}

Input parameters:

- `attached_baton_id` (string)
- `body` (string, required)
- `subject` (string)
- `to_address` (string, required)

### `create_agent_address` (~139 tokens)

Mint a new ephemeral Relaystation address for this agent to receive messages from other agents. Returns a unique <local_part>@courier.relaystation.ai address tied to this agent's customer. Free up to the daily mint cap (default 10/day per customer); above-cap mints debit bridge.agent_address.over_cap_price_micros (default $0.001) via Pattern A. purpose_label is informational. ttl_seconds defaults to 24h; addresses past TTL bounce inbound messages. Example: create_agent_address {purpose_label:"inbox-for-task-42"}

Input parameters:

- `purpose_label` (string)
- `ttl_seconds` (integer)

### `create_baton` (~426 tokens)

Create a baton — a prepaid storage object. Pick a preset (drop=store a file, pass=share a file, scratchpad=collaborate via append log, checkpoint=overwrite snapshot, ledger=hash-chained tamper-evident log) and optional tier, or supply a customShape. BILLABLE: charged once at create (the engine quote of the shape; quote it first with quote_baton). Funded from your balance via your rs_live_* key. Pass inline `content` (≤3MB; base64 for binary) or omit and write later with append_to_baton. flags.hashChaining=true makes an append log tamper-evident (auto-includes a prepaid witness). NOTE: hash-chained batons (ledger preset, or flags.hashChaining=true) MUST be created empty — do NOT pass `content` (returns 422 CHAINED_BATON_REQUIRES_EMPTY_CREATE); create empty, then append_to_baton for entry 1. Example (store): create_baton {preset:"drop", tier:"femto", content:"<base64>"}. Example (hash-chained): create_baton {preset:"ledger", tier:"femto", flags:{hashChaining:true}} then append_to_baton.

Input parameters:

- `content` (string)
- `contentEncoding` (string)
- `contentType` (string)
- `customShape` (object)
- `description` (string)
- `flags` (object)
- `name` (string)
- `preset` (string, required)
- `tags` (array)
- `tier` (string): Bundle tier — valid tiers depend on preset (drop: femto/pico/nano/micro/standard/big · pass: femto/pico/nano · scratchpad: pico/nano/micro/standard/big · checkpoint: nano/micro/standard/big · ledger:…

### `read_baton` (~116 tokens)

Read a baton's content + metadata. FREE (reads draw down the prepaid egress budget, no per-call charge). Address by owner id (requires your key) or by a collaborator token id (tok_…, the token IS the credential). Large multi-entry batons return a presigned download URL or a hint to page via list-entries; small content returns inline. Example: read_baton {id:"bat_<id>"}

Input parameters:

- `id` (string, required): Baton id, or a collaborator token id (tok_…).

### `append_to_baton` (~156 tokens)

Write to a baton — append (for append / append-chained presets) or overwrite (for single-object / checkpoint presets). FREE (consumes the prepaid writes budget; no per-call charge). Owner or editor/write-token only. Set overwrite=true to replace in full on overwrite-shaped batons. Example: append_to_baton {id:"bat_<id>", content:"<text or base64>"}

Input parameters:

- `content` (string, required)
- `contentEncoding` (string)
- `contentType` (string)
- `id` (string, required): Baton id, or a write-capable token id (tok_…).
- `overwrite` (boolean)
- `version_id` (integer): Optimistic-lock guard for overwrite.

### `mint_token` (~154 tokens)

Mint a collaborator token for a baton so another agent can read and/or write without your key. FREE. type is read / write / read_write; optionally cap reads_allowed / writes_allowed, set an expiry, or restrict by IP. Up to 100 tokens per baton. Owner only. Returns the token id (tok_…) — share it as the baton credential. Example: mint_token {id:"bat_<id>", type:"read_write"}

Input parameters:

- `expires_at` (string)
- `id` (string, required)
- `ip_allow_list` (array)
- `reads_allowed` (integer)
- `require_fingerprint` (boolean)
- `type` (string, required)
- `writes_allowed` (integer)

### `balance` (~55 tokens)

Your current Relaystation balance and available (post-hold) credit, plus account profile. Read-only, FREE. Requires your rs_live_* key (or wallet-JWT / MCP token); scoped to YOUR account only. Example: balance {}

### `create_topup_link` (~132 tokens)

Create a one-tap Stripe Checkout link to add credit to YOUR balance — hand it to a human to open and pay. NO money moves here (it returns a URL; the balance is credited when the human pays). Use when you hit insufficient balance. `amountUsd` is dollars (whole cents). FREE to call. Requires your rs_live_* key (or wallet-JWT / MCP token); not for x402 callers. Example: create_topup_link {amountUsd:10}

Input parameters:

- `amountUsd` (number, required)
- `cancelUrl` (string)
- `successUrl` (string)

### `search_tools` (~155 tokens)

Search the full Relaystation tool catalog by keyword and get back the best matches. Use this first to find a tool, then `describe_tool` for its schema and `call_tool` to run it (or call a named hot tool directly). `query` is free text (e.g. "merge pdf", "csv to json", "send telegram"). `detail` controls how much is returned per match: "name" | "summary" (default) | "full" (with inputSchema). `limit` defaults to 5. FREE. Example: search_tools {query:"merge pdf", limit:5}

Input parameters:

- `detail` (string)
- `limit` (integer)
- `query` (string, required)

### `describe_tool` (~46 tokens)

Get one tool's full description and input schema by exact name (as returned by search_tools). FREE. Example: describe_tool {name:'pdf_merge'}

Input parameters:

- `name` (string, required)

### `call_tool` (~165 tokens)

Run a tool found via search_tools by name, passing its arguments. Dispatches the safe/billable utility tools (the cputools catalog + free reads/quotes) through the identical auth + billing + validation as a direct call. Consequential tools (account, money, credential, messaging — e.g. create_topup_link, create_baton, mint_token, ask_operator) are NOT dispatchable here: call them directly by name so your client can gate them with per-tool consent. FREE to invoke (the wrapped tool bills itself). Example: call_tool {name:"pdf_merge", arguments:{files:[{inputKey:"<key1>"},{inputKey:"<key2>"}]}}

Input parameters:

- `arguments` (object)
- `name` (string, required)

### `create_contract` (~372 tokens)

Create a binding-by-goodwill agreement between agents/parties and get back a contractId + termsHash + per-signer read tokens. The contract IS a hash-chained, auto-witnessed record (terms = entry 1, consents append after); it is tamper-evident and permanently verifiable, but it is NOT legally binding, NOT court-enforceable, and involves NO escrow or money movement — enforcement rests on the good faith of the parties. BILLABLE (contracts.create, charge-on-attempt). The system appends a canonical signature block (and, if arbitration:true, an arbitration block) to your terms — your terms body must NOT itself contain those blocks. Each required signer is identified by EXACTLY one method: a "wallet" (0x-address, satisfied only by an EIP-712 ContractConsent signature) or an "account" (a Relaystation customerId, satisfied only by that authenticated account). Input: { terms (required), requiredSigners: [{ identity, kind: "wallet"|"account" }] (required, ≥1), arbitration?: boolean, signingWindowSeconds?: int (default 72h) }. Requires an Idempotency-Key. Returns { id, batonId, termsHash, status, signingDeadline, requiredSigners, tokens: [{ identity, tokenId }] }. Hand each signer their read token + the contractId + termsHash so they can review and sign. Example: create_contract {terms:"Both parties agree…", requiredSigners:[{identity:"0xABC…", kind:"wallet"}, {identity:"<customerId>", kind:"account"}]}.

Input parameters:

- `arbitration` (boolean)
- `requiredSigners` (array, required)
- `signingWindowSeconds` (integer)
- `terms` (string, required)

### `sign_contract` (~208 tokens)

Append your consent to a contract (one entry on its hash chain). FREE. Two forms, no cross-method satisfaction: a "wallet" signer supplies an EIP-712 ContractConsent signature over the contract's termsHash (the signature IS the authentication — no account needed); an "account" signer must be authenticated as the matching Relaystation customerId. When the LAST required signer signs, the contract becomes "executed" and is witnessed. The EIP-712 typed data is domain { name:"Relaystation Contracts", version:"1", chainId } / ContractConsent(string contractId, bytes32 termsHash). Input: { id (contractId), method:"wallet", walletAddress, signature } OR { id, method:"account" }. Returns the updated contract view. Example: sign_contract {id:"<contract-id>", method:"account"}

Input parameters:

- `id` (string, required)
- `method` (string, required)
- `signature` (string)
- `walletAddress` (string)

## Diagnostics

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

## Score history

- 2026-08-04: 72
- 2026-08-03: 71
- 2026-08-02: 71
- 2026-08-01: 70
- 2026-07-31: 70
- 2026-07-30: 65
- 2026-07-29: 65
- 2026-07-28: 64
- 2026-07-27: 63
- 2026-07-26: 63

## Links

- Remote endpoint: https://api.relaystation.ai/mcp
- Website: https://relaystation.ai/
- Changelog RSS feed: https://verifymcp.io/servers/ai-relaystation-relaystation/api/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/ai-relaystation-relaystation/api/changelog.json
- HTML version of this page: https://verifymcp.io/servers/ai-relaystation-relaystation/api