Choosing an external service rarely fails on features; it fails on signup friction, unstable schemas and errors nobody is watching for. The failure-modes and credential-ceremony calls put both of those on the table up front, and they cost nothing to ask. If you go on to execute through it, set the budget first — it is enforced before the call, so an overrun is a refused request rather than a surprise on the invoice — and keep the receipts, since each one carries the provider, the routing explanation and an integrity hash for the execution it describes.
Two halves behind one connection. The index scores and compares services and the capabilities they fulfil; the execution side routes a supported capability call to a provider, applies your budget and routing policy, and returns an auditable receipt for what it did.
- Services searched by what you need done rather than by name, returned ranked, with the full score breakdown for any one of them — execution quality, access readiness, autonomy level, tier and freshness
- Alternatives to a service ranked the same way, for when the first choice does not fit
- Known failure patterns for a service with severity and workarounds, which is worth reading before you write the integration rather than after the first error
- Capabilities browsed as actions that several providers can fulfil — the level to search at when you know what you need doing but not who does it
- A capability resolved into ranked providers with health status, cost per call, auth methods, endpoint patterns and machine-readable recovery hints, including a correction when the capability id is wrong
- Step-by-step credential instructions for a service: signup steps, the token format to expect, a verification endpoint, how long it takes and whether a human has to be involved
- Readiness inspected across credential modes, globally or per capability, so you know what can run right now
- Cost controls before the fact: an estimate of the rail, cost and circuit health before a call; a budget enforced ahead of execution so exceeding it returns a refusal rather than a bill; a routing policy trading cost against speed and quality with a minimum score floor and an optional per-call ceiling
- The money side visible: spending broken down by capability and provider for a period, credit balance with auto-reload status, a checkout URL to top up, and a billing ledger of charges and credits
- Execution analytics over your own usage — calls, latency, errors, costs and provider health
- An immutable chain-hashed receipt for every execution recording the provider used, cost breakdown, latency, routing explanation and integrity hash
- Published multi-step recipes listed and read before being run, executed through the same capability rail with per-step results and a receipt chain
Nothing for discovery — scoring, comparison, failure modes and capability resolution work with no signup at all, and the same read endpoints are public over HTTP. Execution is the part that needs a governed API key in RHUMB_API_KEY, and it spends money: calls draw on a Rhumb credit balance, so the budget and routing settings are the controls worth setting before an agent runs unattended. It starts as npx -y --package rhumb-mcp@latest rhumb-mcp. Scope matters here — the index covers far more services than the execution side can call today, and the multi-step recipe catalogue is in beta and can be empty, which is why the listing tool exists to check before assuming a workflow is live. MIT.
One command — npx -y --package rhumb-mcp@latest rhumb-mcp