Relaystation
REMOTE · API.RELAYSTATION.AI · SCANNED SEP 21
Pay-per-call agent infrastructure: file storage & handoff, compute tools, messaging, e-sign, KYC.
Available components
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. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 3074 tokens (~219/item across 14 items; 14 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage69
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 8% of tool parameters carry a description.Partial
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "ask_operator" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the Relaystation MCP server?
Relaystation is a hosted endpoint at https://api.relaystation.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · api.relaystation.ai
claude mcp add --transport http ai-relaystation-relaystation 'https://api.relaystation.ai/mcp'
{
"mcpServers": {
"ai-relaystation-relaystation": {
"url": "https://api.relaystation.ai/mcp"
}
}
} {
"servers": {
"ai-relaystation-relaystation": {
"type": "http",
"url": "https://api.relaystation.ai/mcp"
}
}
} [mcp_servers.ai-relaystation-relaystation] url = "https://api.relaystation.ai/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"ai-relaystation-relaystation": {
"type": "remote",
"url": "https://api.relaystation.ai/mcp",
"enabled": true
}
}
} openclaw mcp add ai-relaystation-relaystation --url 'https://api.relaystation.ai/mcp' --transport streamable-http
mcp_servers:
ai-relaystation-relaystation:
url: "https://api.relaystation.ai/mcp" {
"McpServers": {
"ai-relaystation-relaystation": {
"Transport": "http",
"Url": "https://api.relaystation.ai/mcp"
}
}
} assistant mcp add ai-relaystation-relaystation -t streamable-http -u 'https://api.relaystation.ai/mcp'
{
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 26 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 +1
- Stability: 0.97 → pass security
- 14 Aug 26 0
- Tool “create_baton” rewrote its description, which is the text the model reads security
- Tool “mint_token” rewrote its description, which is the text the model reads security
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 0
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Probed https://api.relaystation.ai/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=relaystation.ai | CN=Amazon RSA 2048 M01,O=Amazon,C=US | 17 May 2026 | 30 Nov 2026 | RSA 2048 | SHA256-RSA | 7bf695d78201b6c1b024097d5e53f0b |
| SANs: relaystation.ai, *.relaystation.ai | ||||||
| CN=Amazon RSA 2048 M01,O=Amazon,C=US (CA) | CN=Amazon Root CA 1,O=Amazon,C=US | 23 Aug 2022 | 23 Aug 2030 | RSA 2048 | SHA256-RSA | 77312380b9d6688a33b1ed9bf9ccda68e0e0f |
| CN=Amazon Root CA 1,O=Amazon,C=US (CA) | CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US | 25 May 2015 | 31 Dec 2037 | RSA 2048 | SHA256-RSA | 67f944a2a27cdf3fac2ae2b01f908eeb9c4c6 |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of api.relaystation.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 3799 | 8 | Verified |
| relaystation.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://api.relaystation.ai/.well-known/oauth-protected-resource/mcp"
Bearer resource_metadata="https://api.relaystation.ai/.well-known/oauth-protected-resource/mcp" Protected resource metadata
| Document | https://api.relaystation.ai/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://api.relaystation.ai/mcp |
| Authorisation server | https://api.relaystation.ai |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.relaystation.ai/mcp | Verified | 200 | |
| http (plaintext) | http://api.relaystation.ai/mcp | HTTPS enforced |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
append_to_baton ~156
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>"}
| Name | Type | Req | Description |
|---|---|---|---|
| content | string | yes | – |
| contentEncoding | string | – | – |
| contentType | string | – | – |
| id | string | yes | Baton id, or a write-capable token id (tok_…). |
| overwrite | boolean | – | – |
| version_id | integer | – | Optimistic-lock guard for overwrite. |
No output schema declared.
No examples provided.
ask_operator ~246
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?'}
| Name | Type | Req | Description |
|---|---|---|---|
| attached_baton_id | string | – | – |
| max_wait_seconds | integer | – | – |
| message | string | yes | – |
No output schema declared.
No examples provided.
balance ~55
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 {}
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
call_tool ~165
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>"}]}}
| Name | Type | Req | Description |
|---|---|---|---|
| arguments | object | – | – |
| name | string | yes | – |
No output schema declared.
No examples provided.
create_agent_address ~139
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| purpose_label | string | – | – |
| ttl_seconds | integer | – | – |
No output schema declared.
No examples provided.
create_baton ~517
Create a baton — a prepaid storage object. Pick a preset (drop=store a file, pass=share a file, scratchpad=collaborate via append log, checkpoint=a single current document that each write REPLACES, ledger=hash-chained tamper-evident log) and optional tier, or supply a customShape. **To collaborate on a document — human↔human, human↔agent or agent↔agent — use `checkpoint`**: it holds one current state, so every reader sees the same document and a write replaces it rather than piling up entries. `scratchpad` is an append log: good for a running buffer two agents both add to, but readers of a scratchpad see the newest entry only. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| content | string | – | – |
| contentEncoding | string | – | – |
| contentType | string | – | – |
| customShape | object | – | – |
| description | string | – | – |
| flags | object | – | – |
| name | string | – | – |
| preset | string | yes | – |
| 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:… |
No output schema declared.
No examples provided.
create_contract ~372
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"}]}.
| Name | Type | Req | Description |
|---|---|---|---|
| arbitration | boolean | – | – |
| requiredSigners | array | yes | – |
| signingWindowSeconds | integer | – | – |
| terms | string | yes | – |
No output schema declared.
No examples provided.
create_topup_link ~132
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}
| Name | Type | Req | Description |
|---|---|---|---|
| amountUsd | number | yes | – |
| cancelUrl | string | – | – |
| successUrl | string | – | – |
No output schema declared.
No examples provided.
describe_tool ~46
Get one tool's full description and input schema by exact name (as returned by search_tools). FREE. Example: describe_tool {name:'pdf_merge'}
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
message_agent ~197
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'}
| Name | Type | Req | Description |
|---|---|---|---|
| attached_baton_id | string | – | – |
| body | string | yes | – |
| subject | string | – | – |
| to_address | string | yes | – |
No output schema declared.
No examples provided.
mint_token ~244
Mint a collaborator token for a baton so another agent — or a human — 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_…) to share as the baton credential, plus an `editUrl` a human can open in a browser to read and edit the content directly. **Works on any baton; best on a `checkpoint`** — that is the document shape, where a save replaces the current state so every reader (human or agent) sees the same thing. On append-shaped batons (scratchpad, ledger) a save adds an entry and the editor shows the newest entry only. Example: mint_token {id:"bat_<id>", type:"read_write"}
| Name | Type | Req | Description |
|---|---|---|---|
| expires_at | string | – | – |
| id | string | yes | – |
| ip_allow_list | array | – | – |
| reads_allowed | integer | – | – |
| require_fingerprint | boolean | – | – |
| type | string | yes | – |
| writes_allowed | integer | – | – |
No output schema declared.
No examples provided.
read_baton ~116
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>"}
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Baton id, or a collaborator token id (tok_…). |
No output schema declared.
No examples provided.
search_tools ~155
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}
| Name | Type | Req | Description |
|---|---|---|---|
| detail | string | – | – |
| limit | integer | – | – |
| query | string | yes | – |
No output schema declared.
No examples provided.
sign_contract ~208
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"}
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | – |
| method | string | yes | – |
| signature | string | – | – |
| walletAddress | string | – | – |
No output schema declared.
No examples provided.
What is the Relaystation MCP server?
Relaystation is an MCP server listed in the public MCP registry as ai.relaystation/relaystation. Pay-per-call agent infrastructure: file storage & handoff, compute tools, messaging, e-sign, KYC. This page covers its hosted endpoint (https://api.relaystation.ai/mcp).
Is the Relaystation MCP server safe to use?
Relaystation scores 83 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Relaystation MCP server expose?
Relaystation exposes 14 tools: ask_operator, message_agent, create_agent_address, create_baton, read_baton, and 9 more. Their descriptions and schemas cost roughly 2,748 tokens of context every time the server is loaded.
Does the Relaystation MCP server require authentication?
Yes. Relaystation asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Relaystation MCP server still maintained?
Relaystation is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.