Tell us what your agents need to reach.

A model provider, a remote MCP server, or a REST API. Send the vendor and the effect; Obol runs the tier gate on it, and the tier is what fixes the evidence a receipt can ever carry. Nothing on this page asks you for a credential.

What should Obol cover?

REST API

If every tool is one bounded HTTP request mapped by JSON Schema, it can be imported natively. Past that gate it is a trusted worker, or federated with the long tail.

MCP server

A remote MCP server owns its own vendor connection, so it is federated by definition. Obol authorizes and receipts the call; the evidence is broker-attested at best.

Model provider

A model endpoint behind /v1/*. Obol makes the request itself with your own BYOK key, so tokens, spend, and latency are metered at the gateway.

The gate runs on the effect first. A production destructive tool, or an official or high-risk connector, is native or trusted worker whichever transport it arrives on — federation is default-deny there.

This form does not want a credential. No token, key, or client secret belongs in any box above — pasting one here would be a mistake, and we would have to ask you to rotate it. A vendor credential reaches Obol only through the vault, on an authenticated connection.

No date, no SLA, no queue position — we don't have those.

What happens to this request

The gate runs before anything else
A production destructive tool, or an official or high-risk connector, is native or trusted worker. Federation is default-deny there. Everything else in the long tail defaults to federated through a catalog broker — that is how coverage arrives without the iPaaS treadmill.
A federated route runs on your account, not ours
Your own broker account, your own OAuth client. Obol operates no pooled vendor account and no shared broker OAuth app. A catalog broker is a vendor and never an authority: it mints no receipt, assigns no evidence trust, enforces no policy decision, and supplies no idempotency key.
The tier fixes what a receipt can prove
Every tool carries a required EffectSpec, and the receipt names the evidence class it earned.
Native
Gateway-observed: Obol makes the request itself, so a receipt can carry the vendor's own status and upstream id.
Federated
Broker-attested at best, never verified: a third party makes the call, so a receipt records what the broker reported, not what Obol observed.

It may already be on the map.

The catalog freeze covers 2,148 connectors — 104 reviewed packs Obol custodies itself and 2,044 reached through a broker — projected into 249 capabilities.

All catalog capabilities are eligible across native and federated routes: 3,226 candidate bindings in this freeze. Your workspace still needs a matching connected tool and permission, and the request must meet its feature and evidence requirements. Browse the existing catalog before requesting a new provider.

Native: Eligible for capability routing. Calls need a matching connected tool, valid arguments, and workspace permission. Eligibility does not certify a provider mapping.
Federated: Eligible for capability routing through your own connected broker account. The concrete operation and workspace permissions must match; evidence remains broker-attested at best, never verified.

Browse the coverage map