Powers the identity rail's payment model: file transfers are paid for from a prepaid pool of Share credits that is Stripe-billed, with monthly allocation and metered overage handled through Stripe billing.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@refueler/mcp-server price sending quarterly-report.pdf to alice@example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Refueler Share — privacy-first encrypted file transfer for AI agents.
Refueler Share gives an agent a privacy-first file-transfer capability that runs entirely in the agent's own trust domain: files are chunked, encrypted, and BLAKE3-hashed locally before anything touches the network, so the Refueler Worker relays ciphertext it cannot read and — on the anonymous rail — cannot tie to an identity. The v1 toolset lets an agent price a transfer, send a file to any recipient with a browser, and pull a signed collection receipt when it's collected, paying from a prepaid pool of Share credits. You run the server yourself — it's an open-source npm package under Apache 2.0, so your team can audit exactly what it does, and Refueler never sees your keys or your plaintext.
This server runs in your infrastructure, not Refueler's.
That is the point. Encryption happens inside this process, in your trust domain. The Refueler Worker receives ciphertext it cannot read. On the anonymous rail, it cannot tie a transfer to an identity. Refueler never sees your keys, your plaintext, or — on the anonymous rail — who you are.
Do not let a third party host this server on your behalf. The trust model only holds if the MCP server runs inside the same trust boundary as your agent.
Related MCP server: Silicon Transfer MCP Server
Node.js ≥ 20
A Refueler Share API credential pair (identity rail)
npx @refueler/mcp-server or node src/index.js
All configuration is via environment variables. Never put credential values in a file that could be committed to git or shared accidentally.
Place your credentials in your system's secrets manager, your CI environment, or a
.env file that is listed in .gitignore and never committed.
Variable | Required | Description |
| ✅ |
|
| ✅ |
|
| — | Defaults to |
| — |
|
| — | Local path to anonymous credit stack JSON (anonymous rail, coming in a future release) |
Credential files are never copied by an automation tool. Place them manually. This is not a workflow limitation — it is a security invariant. The server must never be able to exfiltrate its own credentials via an automated command.
npm install -g @refueler/mcp-server
export REFUELER_LIVE_KEY=rfs_live_...
export REFUELER_SIGN_KEY=rfs_sign_...
npx @refueler/mcp-serverOr add to your MCP client config:
{
"mcpServers": {
"refueler": {
"command": "npx",
"args": ["@refueler/mcp-server"],
"env": {
"REFUELER_LIVE_KEY": "rfs_live_...",
"REFUELER_SIGN_KEY": "rfs_sign_..."
}
}
}
}Tool | Status | Description |
| ✅ Live | Fetch service capabilities and rate card. Silent preflight. |
| 🔜 SW-MCP-3 | Price a transfer before spending anything. |
| 🔜 SW-MCP-3 | Check your credit pool balance. |
| 🔜 SW-MCP-4 | Encrypt locally and lodge a file. Returns a share URL. |
| 🔜 SW-MCP-5 | Pull acceptance and collection receipts. |
What ships in v1: the send path, honestly scoped. Standing agent-to-agent inboxes and inline Lightning payment are on the roadmap, not in this release.
Stripe-billed, server-held credit pool. Monthly allocation. Metered overage up to a ceiling (API tier). Hard stop at allocation (Personal API). Recoverable, invoiceable, auditable. The demoable rail today.
Client-held bearer credits stored locally in the agent's trust domain. Topped up via
Lightning. The server is blind to the balance. Non-recoverable. Set
REFUELER_RAIL=anonymous and REFUELER_ANON_CREDITS to the local credit stack path.
Not functional in this release.
Apache 2.0. Patent grant clause protects the BLAKE3 + Cashu combination.
Fetch current Refueler Share service capabilities, rate card, and feature flags. Call this before any send to gate behaviour on live server state. Unauthenticated, free, costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Level of detail to return. "summary" (default) returns the full §7.1 payload; "full" is identical in v1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behavioral facts: unauthenticated access, no cost, and that the live server state governs send behaviour. It implies a safe read but never explicitly says the call is side-effect-free or cacheable, which leaves a small gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the purpose front-loaded and the usage condition immediately after. Every sentence earns its place by adding purpose, timing, or cost/auth context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-required-param, no-output-schema discovery call, the description covers what to do and when, plus auth and cost. It does not describe the shape or format of the returned payload, which an agent might want given there is no output schema, but it does enumerate the categories of data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'detail' parameter is fully documented in the schema, including its enum values and that 'full' is identical in v1. The description adds no parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and a concrete resource (Refueler Share service capabilities, rate card, feature flags), naming the actual payloads returned. No sibling tools exist, so no differentiation is required. An agent immediately knows what this tool yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly prescribes when to call it: 'Call this before any send to gate behaviour on live server state.' This gives a concrete precondition rather than an implied one. It does not discuss when-not to call or alternatives, but none meaningfully exist for a capability-discovery call, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0refueler_capabilitiesScored across 1 tool
With a single tool there is no possibility of misselection or overlapping purpose. Its intent (fetch server capabilities/rate card before sending) is unambiguous.
The lone name refueler_capabilities is snake_case and namespaced, which is readable and predictable. It is noun-based rather than a verb_noun action pattern, but consistency cannot really be violated with one tool.
A single tool is far too thin for a server whose description implies a send workflow. There is no operation to actually do anything, making the surface feel like a stub.
The tool explicitly exists as a precondition for 'any send', yet no send, quote, status, or account operation is exposed. The advertised domain is essentially uncovered, leaving agents at a dead end.
Encrypted A2A object storage for autonomous agent state and artifacts
Agent-native storage with cryptographic verification on Solana. Keyless: clients sign and pay.
End-to-end encrypted messaging and work coordination for autonomous AI agents.
Prepaid balance for AI agents: one token, 1,500+ tools, caps, kill switch, signed receipts.
