An MCP server for private, end-to-end encrypted inference on OffRouter models running in GPU TEEs.
List models (list_models): browse available private models with context length and per-million-token price, optionally filtered by a search term like "qwen" or "deepseek".
Ask a model (ask): send a prompt (with optional system prompt, max_tokens, temperature) to a model and get the answer, cost, and signed receipt link — useful for sensitive material or cheap bulk work.
Compare models (compare): run the same prompt on 2–4 models in parallel and see answers and costs side by side.
Check the account (account): view prepaid key balance and recent spend, wallet address and per-call cap, or remaining free-demo quota.
Verify the enclave (verify_enclave): check the Intel TDX quote freshness and booted code from your own machine, and see the key your prompts are encrypted to.
Supports x402 per-call payments on Robinhood Chain using USDG from a configured wallet, with a configurable maximum USD cap per payment.
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., "@OffRouter MCP ask deepseek-v4-flash to privately review this contract and show the cost"
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.
An MCP server for OffRouter, private inference for agents.
Every model on OffRouter runs inside a GPU TEE (Intel TDX plus an NVIDIA confidential GPU). Nothing is cached or logged, and every answer comes back with a signed receipt. This server goes one step further: it encrypts your prompt on your own machine, to a key the enclave proves it holds, before anything goes over the network. OffRouter's gateway sits in the middle and only ever sees ciphertext.
That is the main reason to run this locally instead of using the hosted endpoint at https://offrouter.org/mcp. A remote MCP server has to read your prompt to build the request. This one never sends it in the clear.
You don't need an account to try it. With no configuration it uses OffRouter's free demo (one model, a few calls a day). It runs straight from this repository; the first start takes a minute while it builds.
Claude Code
claude mcp add offrouter -- npx -y github:offrouter/mcpClaude Desktop, Cursor, Windsurf and other clients
{
"mcpServers": {
"offrouter": {
"command": "npx",
"args": ["-y", "github:offrouter/mcp"],
"env": {
"OFFROUTER_API_KEY": "off_sk_..."
}
}
}
}Then ask your agent something like "use offrouter to verify the enclave" or "ask deepseek-v4-flash on offrouter to review this contract".
Nothing to install. If you'd rather not run anything locally, add the hosted server at https://offrouter.org/mcp with your key as an Authorization: Bearer off_sk_... header. It has the same models, but your prompt reaches the gateway in the clear, and it can't pay per call from a wallet.
Related MCP server: sir
Pick one by setting an environment variable. If you set both, the key is used.
Setup | How it pays | Good for |
nothing | Free demo, limited to one model and 5 calls a day | Trying it out |
| A prepaid key, billed per token | Everyday use |
| Pay per call with x402 from your own wallet | Agents that hold their own funds |
Prepaid key. Sign in with a wallet at offrouter.org/dashboard, fund a key, and copy the off_sk_... value. Each call is charged the exact token cost.
Wallet. Every call is paid on its own with a signed USDC transfer on Base, or USDG on Robinhood Chain. The private key stays in this process and is only used to sign the payment. OffRouter quotes each call as a ceiling (your whole input plus max_tokens of output) and refunds the unused part to the same wallet afterwards. This server won't sign anything above OFFROUTER_MAX_USD, whatever the server asks for. Use a dedicated wallet with a small balance, not your main one.
Variable | Default | What it does |
| Prepaid key, starts with | |
| Private key of a wallet to pay per call from | |
|
| Most a single wallet payment can be, in USD |
| both | Only pay on |
|
| Output budget when the agent doesn't set one |
|
| Set to |
|
| API to talk to |
list_models lists the models with context length and price per million tokens.
ask sends a prompt to one model and returns the answer, what it cost, and a link to its signed receipt.
compare runs the same prompt on 2 to 4 models in parallel, so you can see the answers and costs side by side.
account shows the key balance and recent spend, the wallet address and cap, or what's left on the demo.
verify_enclave checks the enclave from your machine right now and shows the key your prompts are encrypted to.
list_agents lists the agents published on OffRouter Studio: what each does, its model, how its runs have gone and whether it has a ready standing. Filter by a search term or to ready agents only.
get_agent shows one Studio agent in full: its example tasks, latest evaluation, wallet and config hash.
The same calls are on the client, listAgents() and getAgent(id), and need no key or wallet: the Studio directory is public.
Before the first call, the server fetches an attestation report for a random nonce it just generated and checks it with the enclave gateway's reference verifier:
The Intel TDX quote verifies all the way up to Intel's root certificate.
The report covers our nonce, so it was made just now and is not a replay, and it binds the enclave's key set.
The boot log replays to the measured launch file, which pins the open source enclave gateway at a specific commit.
If any of these fail, nothing is sent. If they pass, each message is encrypted to the enclave's X25519 key (HKDF-SHA256, then AES-256-GCM, with a fresh ephemeral key for every field). Each ciphertext is bound to the request's nonce and timestamp and to the model, so it can't be replayed or redirected to a different model. The answer comes back encrypted to a one-time key this server made for that request, and it's decrypted here. If the answer doesn't decrypt, it wasn't made by the enclave for your request, and the server throws it away.
The verified key is cached until shortly before it expires. If the enclave rejects a request, usually because its key rotated, the server checks the enclave again and retries once.
To be clear about what this does and doesn't hide:
The gateway can't read your messages or the answers.
The gateway still sees which model you picked, settings like max_tokens and temperature, the size of the ciphertext, the token counts the enclave reports, timing, your IP address, and who paid.
With a wallet, the payment itself is a normal onchain transfer, so it's public.
Your MCP client (Claude, Cursor and so on) sees the prompt and the answer, because that's where they come from and go to. This server protects the hop from your machine to the model.
npm install
npm test
npm run build
OFFROUTER_API_KEY=off_sk_... npm run devRequires Node 20 or newer.
MIT
Show how this server pays for calls: the prepaid key balance and recent spend, the wallet address and per call cap, or what is left on the free demo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: it discloses the categories of data returned (balance, recent spend, wallet address, cap, demo credit), which matters because no output schema exists. It stops short of noting auth requirements or what happens when no key is configured.
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?
A single compact sentence that front-loads the purpose and then enumerates the return categories. Every clause carries content, though the opening framing is slightly wordier than needed.
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?
With no output schema and no parameters, the description must convey the return surface, and it does so by listing the possible account views. The one residual gap is that the 'or' framing implies mutually exclusive views without explaining how a caller selects among them, which is left unstated.
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?
The tool takes zero parameters and the schema has no properties, so there is no parameter semantics to explain. Baseline of 4 applies; the description correctly spends no words on parameters.
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?
The description supplies a concrete verb ('Show') and enumerates the resources returned: prepaid key balance, recent spend, wallet address, per-call cap, and free demo balance. This clearly separates it from siblings like compare, verify_enclave, list_models, and ask, though the opening phrase 'how this server pays for calls' is slightly abstract compared to the concrete account-status content that follows.
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?
Usage is only implied: an agent can infer this is the tool to check balance/spend, but there is no explicit 'use this when…' statement, no prerequisites (e.g., whether an API key is needed), and no named alternative or exclusion. Sibling tools don't obviously overlap, but the guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to an OffRouter model and get the answer back. It runs inside a GPU TEE and is not logged, so it is a good fit for sensitive material, a second opinion, or cheap bulk work.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id from list_models, like "gemma-4-31b". | |
| prompt | Yes | The user message. | |
| system | No | Optional system prompt. | |
| max_tokens | No | Cap on output tokens. Reasoning models need a generous budget. | |
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real behavioral context beyond the sparse annotations: execution inside a GPU TEE, no logging, and cheap bulk usage. However, it stays silent on latency, cost specifics, error/timeout behavior, and does not reconcile with readOnlyHint=false (a non-mutating generation call presented as not read-only).
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?
Two tight sentences: the action first, then the differentiators and use cases. No filler or repetition of schema content.
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 5-parameter generation call with no output schema, the description conveys what comes back ("the answer") and the privacy model. It could say more about response shape or failure modes, but nothing an agent needs to invoke it is missing.
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 80%, so model, prompt, system, and max_tokens are already documented in the schema. The description adds no parameter-level guidance, so the baseline 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+resource ("Send a prompt to an OffRouter model and get the answer back") and adds the distinguishing traits (GPU TEE, not logged). It does not explicitly contrast with siblings like compare or list_models, but the purpose is unambiguous.
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?
Gives concrete use cases: sensitive material, a second opinion, and cheap bulk work. It does not name an alternative or state when NOT to use it (e.g. use compare for multi-model benchmarking), so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the same prompt on 2 to 4 models in parallel and get every answer with its cost side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | Model ids from list_models. | |
| prompt | Yes | The user message. | |
| system | No | Optional system prompt. | |
| max_tokens | No | Cap on output tokens. Reasoning models need a generous budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations cover the safety profile (readOnlyHint=false, openWorldHint=true), and the description adds genuinely new behavioral facts beyond them: fan-out across multiple models, parallel execution, and that each answer carries a billed cost. It stops short of saying what happens when one model in the batch fails or is rate-limited.
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?
A single front-loaded sentence with no filler; the parallel-execution and cost aspects — the two things an agent most needs to know — land immediately.
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 four-parameter tool with full schema coverage and no output schema, the description is sufficient: it conveys breadth (N models), concurrency, and that results and their costs are returned together. Only partial-failure behavior remains unstated, which is a minor omission.
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%, so all four parameters are already documented, including the 2–4 bounds and the models/prompt distinction. The description reinforces but does not extend this — nothing is said about how 'system' or 'max_tokens' apply across a heterogeneous model set, which would be the genuinely additive detail.
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?
The description gives a specific verb ('Run the same prompt') and resource scope ('2 to 4 models in parallel') plus the return shape ('every answer with its cost side by side'). It implicitly sets itself apart from the single-model sibling 'ask', but never names that sibling or otherwise makes the distinction explicit.
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?
Usage is only implied: the '2 to 4 models' framing and the side-by-side cost output suggest it is for A/B or cost/quality trade-off comparisons. There is no explicit 'use this instead of ask when...' routing, and no mention that 'list_models' should be called first, which is a real prerequisite since model ids must come from somewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the private models on OffRouter with their context length and price in USD per million tokens. Use it to find a model id for ask or compare.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filter on the model id, like "qwen" or "deepseek". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's job is incremental — and it delivers by disclosing what the results contain (context length, price) and the pricing unit convention (USD per million tokens). Pagination behavior and result size limits are not mentioned, which keeps it short of a 5.
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?
Two tight sentences: the first defines content and scope, the second gives purpose. Zero filler and the resource description is front-loaded.
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?
With no output schema, the description correctly fills the gap by naming the returned attributes and units, and the single parameter is fully documented in schema. Only the absence of any list-size or pagination note keeps it from being fully complete.
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?
The sole `search` parameter has 100% schema description coverage with a concrete example ("qwen", "deepseek"), so the schema carries the semantics. The description adds nothing about the filter beyond implying the tool lists models.
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?
A specific verb ("List") on a specific resource ("private models on OffRouter"), with the exact fields returned (context length, USD price per million tokens) stated up front. This is clearly distinct from compare, ask, and account, though the description never explicitly contrasts itself with those siblings.
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?
"Use it to find a model id for ask or compare" gives concrete downstream context that tells the agent when this tool is the right first step. It doesn't state when NOT to use it or what to do instead, but the positive routing cue is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the enclave right now from this machine: the Intel TDX quote, that the report is fresh, and that it booted the published code. Returns the key prompts are encrypted to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnly and openWorld; the description adds substantive context beyond that — it performs a live network attestation against a remote enclave and returns the encryption key. It omits failure semantics (what a failed quote check returns, error shape), which matters for an attestation tool.
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?
Two dense sentences: the first front-loads what is checked, the second front-loads the return value. No filler and nothing repeated from the schema or annotations.
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?
With no output schema, the description carries the return-value burden and does name the key return. It leaves the success/failure result shape implicit, which is the one gap for an attestation call an agent must branch on.
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?
Zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly implies no input is required because the machine context is implicit.
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 (check/verify) and resource (the enclave) plus the exact three things being validated: the Intel TDX quote, report freshness, and that it booted the published code. None of the siblings (compare, account, list_models, ask) overlap, so an agent can route unambiguously.
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?
'Right now from this machine' gives a real usage condition — a live, local verification rather than a cached or remote one. It stops short of naming when-not-to-use or a fallback path, but no sibling competes for this job.
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.0accountaskcomparelist_modelsverify_enclaveScored across 5 tools
Each tool has a clearly distinct purpose: list_models discovers models, ask executes a single prompt, compare executes across multiple models, account reports billing/payment state, and verify_enclave checks attestation. The ask/compare overlap is explicitly clarified by compare's parallel multi-model comparison behavior.
The set mixes verb_noun snake_case tools (list_models, verify_enclave) with simple verbs (ask, compare) and a noun-like tool (account). It remains readable, but there is no single predictable pattern across all five names.
Five tools is well-scoped for an inference router: discovery, single query, comparison, billing, and attestation cover the core surface without excess. Each tool appears to earn its place.
The surface covers model discovery, prompt execution, multi-model comparison, account/billing status, and enclave verification, which are the key workflows for a private model router. Minor gaps might include richer model details or usage history, but agents can work around these.
Auction exchange for LLM inference: browse models and prices, preview and buy answers.
Prepaid inference for agents over hosted MCP. Chat, image, and video.
Every major chat, image and video model on one prepaid key. OpenAI, Anthropic and Gemini formats.
OpenAI-compatible LLM gateway: pay per request with an API key, signed receipt for each call.