This guide describes the MCP Passthrough panel in v0.29.3. Open your node’s wallet, choose Plugins, then MCP Passthrough. Installation, permission approval and the Public routes switch belong to the host’s plugin controls; see Setup first.
The panel has seven tabs: Overview, Providers, API keys, Usage, Network, Notifications and Settings. On narrow screens the host may present these as a dropdown.
Choose how this node obtains inference
Each node serving or routing inference runs its own copy of the plugin. A wallet used only for billing or payment relaying does not need this plugin. A node can use an upstream model API configured under Providers, buy inference from another eIOU node through Network, or do both.
For nodes hosted by the eIOU team, use remote inference providers. Those hosted servers do not run local models or Ollama sidecars. The plugin’s first-run Set up inference panel probes for local runtimes, but a failed local probe does not prevent remote inference. Use Providers → Add provider for an upstream API, or configure network access as described below.
On infrastructure you operate, local runtimes are an additional option. Scan for a local sidecar looks for Ollama, LM Studio, vLLM, llama.cpp and TGI. Detection links an existing service; it does not create compute capacity. The provider’s Self-host … section contains its deployment recipe.
Overview
Status summarizes the active provider/model, keys and balances. MCP server shows the endpoint to give your client. The client also needs a plugin customer key; your wallet password and upstream model API token are different credentials.
The Chat tester appears when an active provider is configured:
- Choose a Model, or leave the active model selected.
- Enter a Prompt and press Send test.
- Inspect the response and the amount a customer would be charged.
This sends a real request to a configured provider, but does not debit a customer key or add an inference usage row. A paid upstream API can still charge your provider account. It does not verify client authentication, automatic network routing or the full billing path. Complete the first client call in Clients for that check.
Providers
Add and connect a provider
Under Add provider, choose a Preset, optionally set an Instance ID, and enter the API token and Endpoint where required. Use a distinct instance ID for multiple connections to the same service.
After adding it:
- Check the provider’s endpoint and use Test connection.
- Use Fetch models to obtain its catalog. Newly fetched model IDs are added disabled so you can review their prices.
- Open a model row to inspect availability, pricing and enabled status.
On an existing provider, a blank token field keeps the stored token. Clear stored token removes it when saving. Remove deletes the provider configuration and its model rows; it does not uninstall models from an upstream runtime.
For exact endpoint types, provider access and network funding, see Providers.
Price and enable a model
Click a model row to open its detail editor:
| Control | Meaning |
|---|---|
| Upstream cost | Input/output rates per million tokens and transfer cost per GB, in the displayed upstream currency. |
| Markup over upstream | Applies the configured markup to upstream cost. The cost currency must match the node’s settlement currency. |
| Manual rates | Sets customer input/output and transfer rates in the settlement currency shown in the editor. Use this when currencies differ; the plugin does not provide foreign-exchange conversion. |
| Enabled / Save model | Controls whether the model is available to serve. |
| Use this model | Sets the active provider/model used in manual routing and as the default selection. |
| Speed test | Makes test inference requests and records performance; paid upstream services may charge for them. |
| Recheck availability | Repeats an Ollama model’s availability check where offered. |
| Remove | Removes the plugin’s model row and its pricing/test history; the upstream model stays installed. |
Add a model lets you enter an ID missing from the fetched catalog. Preset prices are release defaults: review them against your own provider agreement before accepting paid requests.
API keys
Use this tab to issue the bearer key your MCP client will send to this node:
- Enter a Label.
- Enter an accepted contact’s name or public-key hash in Contact. This is required in the default pilot mode.
- Optionally set Registered pubkey for top-up matching, and Expires after for the key’s lifetime.
- Press Mint key and copy the newly displayed token before leaving the page. The key list cannot reveal that plaintext token again.
Lifetimes accept values such as 30d, 12h or 90m, or a bare number of days, up to 366 days. Blank uses Settings → Default key lifetime; if that is also blank, the key has no expiry.
The contact identifies the customer whose spending the key represents. Ownership of the serving node does not create a self-use key, and the node cannot be its own contact. Arrange the billing contact during setup; see Setup.
The table shows balances and key status. Revoke prevents further use and cannot be undone. Allowed-origin overrides apply to individual keys; an empty override inherits the default in Settings. An origin allow-list supplements bearer authentication and does not fund the key.
Key balances and the serving node’s funds at remote sellers are separate. See Architecture before interpreting a positive balance as proof that a network route can run.
Network
Routing settings
Automatic routing starts off: the default mode is Manual — use my active provider only. Expand Routing settings to configure it.
| Control | Meaning |
|---|---|
| Mode | Manual uses the active provider. Automatic considers configured providers and eligible network offers. Network only restricts selection to other nodes, useful for checking federation. |
| Policy | Local first prefers providers configured on this node; a configured provider can itself be a remote cloud API. Cheapest advertised ranks estimated advertised inference charges adjusted for recent route failures, without guaranteeing the lowest total including payment-route fees. |
| Daily spend limit | Limits automatic seller funding per UTC day; routing fees reconciled later can increase the final spend. 0 means no daily limit. |
| Max price per request | Excludes routes whose estimated request charge exceeds the ceiling. 0 means no ceiling. |
| Your markup on network inference | Adds a percentage to the seller’s inference price for your customer. |
| Top up each seller to | Target credit held at a seller. Funding can exceed that target when a request needs more headroom. |
| Discovery horizon | Limits how far offers learned through contacts are considered. This does not send the prompt through each discovery contact. |
| Routes to try per request | Limits candidate attempts to 1–10. |
| Allow buying inference from other nodes | Permits network candidates when routing mode also allows them. |
| Try the next route when one fails before producing output | Enables eligible failover. A different provider may receive the prompt. |
Press Save routing after changing these controls. For a hosted node using only the eIOU network, enable network buying, set spending limits and coordinate accepted-contact access to sellers. An advertised model alone does not establish seller admission or funding.
Check readiness
Where would a request go? explains candidate selection without sending a prompt or moving funds. A route explanation is a planning check; it does not prove a remote credential is funded and ready.
Warm the best sellers prepares up to three eligible sellers. It can request credentials and send eIOU top-ups under your routing limits. It is not a read-only connectivity test. A seller may remain funding while a routed payment completes; wait for readiness before relying on it for inference.
Managed seller credentials shows the credentials this node manages on other nodes without exposing their tokens. Forget removes a local credential record. It does not refund credit held at that seller; another warm-up may mint and fund a replacement.
Model directory lists offers learned through contacts, their currency and freshness. Direct and Networked describe discovery reach, not a guarantee of access. Recent attempts helps explain route failures. The Deals section displays manually initiated deal/job history; the table omits prompt text even though job storage can retain it for resumption.
Usage and Notifications
Usage displays Recent usage and Recent topups. Use these to check the charged model, token counts, currency and credited payments after a real client call. The Overview chat tester does not create these usage rows.
Notifications shows operational events. Dismiss handles one notification; Clear all clears the feed. These actions do not erase balances, top-ups, usage records or counterparties’ records.
Settings
| Setting | Effect |
|---|---|
| Currency | Selects the node’s settlement currency from the host’s allowed set. Review existing keys, balances and model rates before changing it; validation may refuse an incompatible change. |
| Default allowed origins | Comma-separated scheme://host[:port] entries for browser clients. Keys with their own override use that instead. Loopback origins are implicit; the node’s own host is not automatically allowed. In v0.29.3, entries match scheme and hostname without restricting ports. * disables the origin check. |
| Default key lifetime | Applies when minting future keys without an explicit lifetime. Changing it does not alter existing expiry dates. |
| Who may use the federation routes | Known contacts only is the default pilot mode. Open federation allows unverified callers to request keys; choosing it changes admission policy. |
In pilot mode, the operator can mint keys for accepted contacts, and a peer can obtain a contact-bound key by proving an accepted identity with a signed assertion. The v0.29.3 settings hint saying /request-key is refused describes anonymous signup, not this signed contact path. Directory access also checks accepted-contact status. See API for the actual authentication rules.
Implementation reference
The labels and actions in this guide are defined in Panel.php, panel.js and ActionRouter.php. The host permissions and exposed actions are declared in plugin.json.
Return to the documentation introduction, or use the CLI reference for operations not exposed in the panel.
Source: docs/GUI.md at revision 07476eedee57.