Discovery stays free while Rhumb is proving candidates; paid execution starts only after a selected route can name the capability, actor, credential rail, budget owner, side effect, estimate, and receipt evidence for one bounded workflow.
What stays in free proof?
The easy mistake is to treat any MCP server listing as a runnable route. A safer boundary keeps discovery, scoring, and safety rehearsal upstream of paid execution.
Search directories, registries, scored services, and capability definitions to assemble possible MCP servers or provider routes.
No provider call is made for the customer's workflow yet. Server count, ranking, and inclusion are inventory signals, not execution.
Collapse the list to one repeat job: search.query, scrape.extract, image.generate, email.send, data enrichment, or the supported equivalent.
A broad idea such as 'connect my CRM' stays evaluation until the action, inputs, outputs, and side-effect class are explicit.
Inspect caller identity, tool visibility, credential rail, tenant scope, and quota owner before a model can invoke anything.
Auth setup, manifest filtering, and route-card inspection remain proof. A connector grant is not a billable call by itself.
Pick the closest unsafe tenant, path, domain, amount, row, tool, or provider account and prove it fails closed.
Negative-case rehearsal should not spend provider budget or mutate state. It earns the right to estimate one safe lane.
Quality signals do not make the route paid by themselves
Quality evidence helps decide which candidate deserves a route card. It should never turn a directory score, marketplace badge, or server-quality review into execution authority by itself.
Quality guide: MCP server quality signals / Evaluation guide: how to evaluate MCP servers
What has to be true before the paid route exists?
A paid route is not merely “the best server.” It is a selected, attributable execution lane. The minimum fields should be boring enough for a human operator, retry worker, and finance trail to reconstruct later.
How the boundary changes by workflow
Search
Compare Exa, Tavily, Brave, and other candidates for the query class; inspect auth, freshness, and output contract.
A selected search.query route executes under a chosen credential rail with estimate, budget ceiling, and receipt fields preserved.
Extraction
Check domain constraints, browser risk, tool-output shape, blocked-host behavior, and the denied-neighbor URL before routing.
A bounded scrape.extract or extraction equivalent runs against the approved target set with trace evidence and no broad browser fallback.
Provider-specific tool use
Inspect MCP server metadata, manifest filtering, backend authority, and whether the caller sees only the intended tools.
The selected provider route executes one allowed capability instead of exposing the whole server inventory to the agent loop.
Pick the rail after proof, not before it
The workflow fits the current callable surface and the operator wants one stable key, bounded budget, denial proof, and receipts.
Upstream cost plus 20% margin on Rhumb-managed execution.
Get governed key →The agent should pre-fund repeat execution but keep normal key-based runtime ergonomics.
Wallet balance funds repeat calls; receipts should preserve top-up, drawdown, and budget context.
Review wallet-prefund →The payment proof is part of the per-request contract and zero-signup payment authorization matters more than repeat-lane ergonomics.
USDC on Base; upstream cost plus 15% margin on the x402 rail.
Review x402 →Execution must happen through the customer's provider account, workspace, contract, compliance boundary, or existing quota pool.
Rhumb adds no markup in BYOK or Agent Vault mode. Provider charges bill directly to your provider account. Provider cost, quotas, and credential hygiene stay with the operator.
Choose credential path →When Rhumb should stop instead of bill
- The tenant, caller, backend principal, or provider account cannot be named.
- The workflow needs a tool outside the visible allowlist or tries to widen scope after discovery.
- The quota owner is shared but attribution would collapse into a generic admin account.
- The side-effect class is unclear, irreversible, or missing an idempotency/recovery expectation.
- The nearest unsafe neighbor was never tested or failed with an ambiguous success-like response.
- The estimate cannot preserve credential mode, route, side-effect class, or cost-ceiling context.
The practical test
If the agent is still asking “which server should I use?” you are in discovery. If the operator can say “this caller may run this capability through this credential rail up to this budget, and this adjacent action must be denied,” you are close to execution.
That distinction protects both sides. Builders get useful candidate proof without paying for research. Operators only pay when the call is constrained enough that a retry, denial, receipt, and budget review can be understood later.
When free discovery becomes an E-007 route-hardening ask
Discovery has done its job when the argument is no longer “which MCP server is best?” but “this one MCP route will run repeatedly, and the adjacent route must never fire.” At that point the buying-intent signal is not another directory search. It is a concrete hardening request.