Complete node installation and client access first. In these instructions, the serving node B is the node your MCP client connects to, and the provider node C is an eIOU node offering inference.
Choose a connection
Through eIOU contacts: the serving node B discovers models offered by other nodes, obtains a provider credential, and funds it with eIOU. This is the network path the pilot aims to test. Start with one participating provider directly connected to B.
Online model API: the serving node’s operator supplies credentials for a supported remote API and configures models and pricing. This is also how a hosted provider node C can supply inference to B. It requires an upstream API account with model access and budget. An MCP client login is not an upstream API credential.
Nodes we host use these remote paths. Do not deploy the plugin repository’s development Compose stack, model images, or Ollama sidecars on our hosted servers. Operators with their own inference hardware can configure local engines separately; that setup is outside this hosted pilot guide.
Through eIOU contacts
1. Arrange provider admission and credit
Ask the provider operator for the address of provider node C, an enabled model ID, its price and currency, and the agreed test funding. Connect the serving and provider nodes using the wallet’s contact workflow; verify the contact is accepted at both ends.
For the first test, use a direct accepted provider contact. Discovery through a chain of contacts does not itself grant access at the seller. In pilot mode the provider node accepts automated credential requests only when the signed contact assertion proves an identity C accepts. The serving node creates that assertion automatically; the user does not paste C’s key into their MCP client.
The provider operator must have installed the plugin, enabled public routes, and configured and priced a working model. The serving node needs a usable payment route in the same settlement currency. If credit is needed, the recipient or next hop must agree to accept the serving node’s obligations within its limits; increasing the credit the serving node offers someone else does not create its spending capacity.
2. Set limits before warming providers
On the serving node B, open MCP Passthrough → Network. Review Automatic routing, the per-request ceiling, daily funding limit, provider balance target, hop limit, and failover setting. Choose small, explicit values with the pilot team.
The following commands illustrate the settings. Replace the three AGREED_... placeholders with positive decimal amounts in the configured settlement currency before running them. They are not suggested prices or grants of pilot credit.
eiou mcp-passthrough set routing_daily_spend_limit AGREED_DAILY_LIMIT
eiou mcp-passthrough set routing_max_price_per_request AGREED_CALL_LIMIT
eiou mcp-passthrough set peer_balance_target AGREED_PROVIDER_PREPAYMENT
eiou mcp-passthrough set routing_max_hops 1
eiou mcp-passthrough set routing_failover_enabled 0
eiou mcp-passthrough set routing_remote_allowed 1
eiou mcp-passthrough routing enable
eiou mcp-passthrough routing status0 means unlimited for the daily and per-request price limits. Automatic routing is off by default. A one-hop routing limit and failover disabled make the initial provider test easier to inspect; broaden them later only after reviewing the additional providers and costs.
The provider balance target is advance funding at a seller, not a per-call charge or a maximum top-up. When funding is needed, automatic funding aims for the greater of that target or three times the estimated seller-side cost, subject to the remaining daily allowance. The low-balance watermark setting does not trigger funding in v0.29.3. The daily limit tracks provider funding, and routing fees are reconciled on settlement. Leave headroom for fees instead of treating the setting as an exact all-in cap on wallet outflow.
3. Discover and prepare a provider
On the serving node B, sync the directory, inspect the chosen model, then warm a provider:
eiou mcp-passthrough directory sync
eiou mcp-passthrough routing explain MODEL_ID
eiou mcp-passthrough peers warm --max=1
eiou mcp-passthrough peers listReplace MODEL_ID with the offered model. The panel’s Warm the best sellers action performs credential preparation too. Warming can send eIOU payments, so agree the budget first. The command chooses an eligible seller; --max=1 limits how many sellers it processes, not which seller it chooses.
The serving node B obtains and stores a managed credential at the provider C and sends funding with the credential’s top-up memo. Wait for the payment to settle, then inspect the provider balance and route again. If needed, run warmup again after settlement. A cold route may not be ready during the first attempt.
Read individual warmup messages. A summary saying “warming” or “funding” does not prove admission succeeded or money arrived; a refused credential request can also be reported as pending preparation. Check the actual peer state, transaction and balance. Managed provider readiness requires prepaid balance at the provider; that provider extending contact credit alone does not replace this check.
4. Confirm the route
eiou mcp-passthrough routing explain MODEL_ID
eiou mcp-passthrough peers listConfirm the intended model has a ready route. Automatic routing can also choose a provider configured directly on the serving node, so inspect the route if the purpose is specifically to test the network provider. Do not infer successful network routing merely from receiving an answer.
Online model APIs
Use this path on the serving node B for a directly configured online API, or on the provider node C when offering inference to other eIOU nodes.
- Open MCP Passthrough → Providers → Add provider. Choose the preset matching the service’s API protocol. The released plugin includes OpenAI-compatible and native Anthropic transports, plus vendor presets and a custom endpoint option.
- Check the endpoint against the API service’s documentation. Enter the upstream API token in the operator panel and click Add provider. Keep it out of client config and shell history. A client key issued by this plugin and an upstream API token serve different connections.
- Review the preset’s starter models immediately: they may already be enabled. Check their availability and default prices, and disable any you do not intend to offer. Test the connection, then use Fetch models. Newly discovered hosted models start disabled so you can review pricing before enabling them.
- Choose a model the upstream account can actually use. Set its input/output rates and pricing mode in the plugin’s settlement currency, then enable it. Use manual prices or reviewed upstream costs plus markup. Do not assume the upstream’s currency and the node’s settlement currency are interchangeable.
- Select the provider and active model. To test only this configured provider on the serving node, leave automatic routing off. On a provider node, this makes a model available for its own customers and contact discovery.
- Run a small provider test and check the result. Model speed tests consume upstream inference and can incur API charges. Then verify a real client call using the next guide.
Read-only inspection commands:
eiou mcp-passthrough provider list
eiou mcp-passthrough statusTo fetch models and select one after reviewing its pricing:
eiou mcp-passthrough provider models PROVIDER_ID
eiou mcp-passthrough provider use PROVIDER_ID MODEL_IDThe UI may call a provider configured on this node “local” when comparing routing choices. That means locally configured; its endpoint can still be an online API. It does not mean the hosted server is running a model.
Check provider readiness
Before handing the endpoint to a tester, confirm:
- The intended model is enabled, priced, and available in the selected currency.
- The client key on the serving node has its own balance or agreed contact credit.
- For network inference, the serving node is admitted at the provider and its managed provider credential has received funding.
- Spending limits and fallback behavior are understood. A retry through a different provider changes who processes the prompt.
- The tester knows the node endpoint, model ID, key expiry and support contact.
Then connect the MCP client and check a billed call. Your node, the serving provider and any upstream API process prompts and outputs; review inference privacy and the selected operators’ retention practices before sending sensitive content.
Release implementation references: credential acquisition and funding, signed contact assertions, routing settings, and provider operations.
Source: docs/PROVIDERS.md at revision 07476eedee57.