MCP gateway

One governed endpoint for every agent you run.

Q: What is an MCP gateway?

An MCP gateway is a layer between agents and the MCP servers they call. Clients hold one URL instead of their own list of servers and credentials, and the gateway decides which tools a person can see, which calls may run, and what is recorded.

Q: Does this add latency to every call?

It adds one hop. The upstream call is wrapped in its own OpenTelemetry span nested under the run, so Omniio's overhead is measurable separately from the upstream's time in your own tracing.

Q: Can I bring a server that is not in the library?

Yes. You can add your own MCP server URL from the dashboard; it joins your endpoint alongside the curated ones with the same search, policy and audit trail, and stays private to your account.

Q: What happens when an upstream server changes a tool?

Every tool definition is hashed, including its description and input schema, so a changed definition is detected rather than silently accepted. Changes are listed in the dashboard and can be delivered by webhook.

Q: Which clients can connect?

Any client that speaks MCP over streamable HTTP with OAuth, including Claude Code, the Claude desktop app, Cursor, VS Code and Windsurf. The exact configuration for each is on the clients page.

Q: Does Omniio see the data my tools return?

Tool results pass through Omniio and the call is recorded with its arguments and result, so the audit trail can answer what the agent did. Records are kept for the plan's retention window and deleted by a nightly prune.

Your clients hold one URL. Behind it, Omniio decides which tools a person can reach, which calls may run, and writes down every one of them — across 140 servers and the ones you bring yourself.

Start free Talk to us about rollout

Livehttps://mcp.omniio.dev

6 servers on the moment you sign up · 25,000 calls a month on Free · no card to start

Your clients

Claude Code
Claude desktop
Cursor
VS Code
Windsurf
Your own agent

One endpoint

https://mcp.omniio.devauthorized once, per person, per client

140 servers

The problem it solves

Every server you add is another thing to keep.

Connecting agents to tools one server at a time works until the third server. After that, three costs compound — and all three have the same fix.

A config file per machine

Every server is another block of JSON, on every laptop and in every CI runner. Adding one means a pull request; removing one means finding all the copies.

A credential per server, in plain sight

Tokens end up in shell profiles and config files, one per person per server, with nothing that says which are still in use or when they were last rotated.

No record of what the agent did

Each upstream keeps its own log, in its own format, if it keeps one at all. Nothing answers the question people actually ask: what did my agent change, and when.

Without a gateway

mcp.json — on every machine

{
  "mcpServers": {
    "postman": {
      "type": "http",
      "url": "https://mcp.postman.example/mcp",
      "headers": {
        "Authorization": "Bearer ${TOKEN}"
      }
    },
    "resend": {
      "type": "http",
      "url": "https://mcp.resend.example/mcp",
      "headers": {
        "Authorization": "Bearer ${TOKEN}"
      }
    },
    "github": {
      "type": "http",
      "url": "https://mcp.github.example/mcp",
      "headers": {
        "Authorization": "Bearer ${TOKEN}"
      }
    },
    "neon": {
      "type": "http",
      "url": "https://mcp.neon.example/mcp",
      "headers": {
        "Authorization": "Bearer ${TOKEN}"
      }
    }
  }
}

…and one more block for every server after these, kept in step across every laptop and runner that runs an agent.

With Omniio

mcp.json — once

{
  "mcpServers": {
    "omniio": {
      "type": "http",
      "url": "https://mcp.omniio.dev"
    }
  }
}

The rest is a toggle in your library. The config a client wrote on day one keeps working as the toolset changes underneath it.

Inside one call

Six stages, in this order, every time.

Not an illustration of the pipeline — it is the pipeline, in the order the endpoint runs it. Step along it, or let it run.

POST /mcp · 401 → OAuth 2.1step 1 of 6

The client authorizes against Omniio, once

An unauthorized request is answered with a 401 and a WWW-Authenticate header pointing at the authorization server, which is how an MCP client knows to start the flow. It registers itself dynamically, gets a token bound to this endpoint, and that token is what every later call carries.

protocol: MCP over streamable HTTP
auth: OAuth 2.1 + PKCE, dynamic client registration
audience: https://mcp.omniio.dev

How it compares

More than a proxy, and not one vendor’s tools.

Wiring servers into a client config gives you no control layer at all. A single vendor’s hosted MCP server gives you control over their product and nothing else.

Capability	Servers in a client config	One vendor's MCP server	Omniio
Client setup	One config block per server, per machine	One URL, for that vendor's tools only	One URL, for everything
Adding a server	Edit and redistribute the config	Wait for the vendor to add it	A toggle; live on the next call
Tool discovery	Every tool preloaded into context	Every tool preloaded into context	Searched, three tools exposed
Credentials	Env vars and config files on each machine	Held by the vendor, for their own APIs	Sealed per person, unsealed per call
Control before a write	None	Whatever that vendor offers	Allow, ask or block, per tool
Audit trail	Whatever each upstream keeps	That vendor's actions only	One log across every server
Changing model	Reconfigure every machine	Reconnect, per person	Nothing to change; the URL is the same

Rolling it out

It has to fit the org, not just the laptop.

Everything below is in the product today, and every card links to the page that documents it rather than to a form.

Your identity provider

SAML or OIDC single sign-on, and SCIM 2.0 so joiners and leavers in your directory become Omniio accounts and closed ones without anybody filing a ticket.

How SSO and SCIM work

Policy that survives the agent

Tool policy is set per account and enforced at the endpoint, so it holds whichever client, model or harness is asking — including ones that did not exist when you wrote it.

How tool policy works

Observability you already run

Spans are emitted over OTLP to whatever collector you use, so gateway latency shows up beside the rest of your traces rather than in a dashboard nobody opens.

How tracing works

Retention you choose

Records are kept for 7 days on Free and up to 1 year on Enterprise, pruned nightly, and readable over the REST API for as long as they are held.

Read API reference

Questions

The ones we get asked most.

What is an MCP gateway?

A layer between your agents and the MCP servers they call. Instead of each client holding its own list of servers and its own credentials, the clients hold one URL, and the gateway decides which tools that person can see, which calls may run, and what gets written down.

How is this different from an MCP server?

An MCP server exposes one product’s tools. Omniio is a client of many of those servers and a server to your agent, which is what lets it rank across all of them at once and hold one credential set per person rather than per machine.

Does this add latency to every call?

It adds one hop. The upstream request is wrapped in its own span nested under the run, so the difference between the two is Omniio’s own overhead — gating, credential decryption, the catalog lookup — and you can see it separately from the upstream’s time in your own tracing.

Can I bring a server that is not in the library?

Yes. Add your own MCP server URL from the dashboard and it joins your endpoint alongside the curated ones, with the same search, the same policy and the same audit trail. Servers you add are yours — they never appear in the public library.

What happens when an upstream server changes a tool?

Every tool definition is hashed — name, title, description and input schema — so a description that quietly grows a line of instructions to the model is detectable rather than invisible. Changes are listed in the dashboard and can be sent to a webhook.

Which clients can connect?

Any client that speaks MCP over streamable HTTP with OAuth. That includes Claude Code, the Claude desktop app, Cursor, VS Code and Windsurf; the exact snippet for each is on the clients page.

Does Omniio see the data my tools return?

It passes through, and the call is recorded — arguments and result — so the audit trail can answer what the agent did. That record is yours, kept for your plan’s retention window and then deleted by the nightly prune. What is held and for how long is set out in security.

140 servers and 584 cached tools in the catalog right now, served from mcp.omniio.dev.

Point one client at it and see what it costs you in context.

Free covers 25,000 calls a month, which is a personal agent running all month. Nothing to install and no contract.

Start free Get the config for my client