odock.ai
Governed tool request
MCP Gateway

Govern every tool call your agents make

Agents need more than a proxy. Odock puts a governed MCP gateway between your agents and every upstream server, enforcing auth, access policy, spend limits, and audit records before any tool executes.

Book a demoRead the MCP governance guide

One governed path for every tool call.

mcp-gateway.request
MCP Gateway
>POST /v1/mcp/tools/callagent runtime
01Agent authverified
02Tool grants...
03Policy scan...
04Budget hold...
05Route upstream...
06Usage logged...
Transports
SSE, HTTP, STDIO
Controls
Policy, budget, audit
What is an MCP gateway?

A policy layer between AI agents and every tool they can touch

An MCP gateway is a control plane between AI agents and the MCP servers that expose tools like GitHub, Slack, and databases. Instead of every agent holding upstream credentials and reaching each server directly, all tool traffic flows through one governed endpoint that authenticates the caller, checks tool-level permissions, enforces budgets, and records every call. Odock ships it as part of one AI governance plane, so the same keys, budgets, and audit records govern your MCP tool traffic and your LLM traffic alike.

Where teams use it

Agent tool access control

Expose only approved tools to each agent, block destructive actions like delete or deploy, and require approval for sensitive calls, regardless of what the model decides.

Credential isolation

Agents authenticate to the gateway with virtual API keys. Upstream GitHub, Slack, or database credentials are stored once in Odock and injected only after governance checks pass.

Cost and audit on tool traffic

Price tool calls per request and per byte, cap them with budgets and quotas, and attribute every call to a key, team, and user for chargeback and compliance review.

Keep exploring
LLM GatewayMCP governance guide
MCP request lifecycle

Every tool call follows a governed path

No request reaches an upstream server until it passes auth, access, inspection, and cost controls. Every outcome is recorded.

01

Authenticate

Validate the virtual API key.

02

Authorize

Confirm access grants and server scope.

03

Inspect & enforce

Filter tools, payloads, and policies.

04

Reserve spend

Check budgets and quotas before execution.

05

Transport

Proxy upstream via HTTP, SSE, or STDIO.

06

Record outcome

Log tool, latency, status, and cost.

Blocked request exampleDenied by governance
{
  "apiKey": "vk_agent_prod_support",
  "mcpServer": "github-tools-http",
  "method": "tools/call",
  "tool": "delete_file",
  "reason": "blocked_tool",
  "status": 403
}
Why it matters

Tool calls are a different attack surface from model calls

When an agent can write to a database, push to GitHub, or trigger a workflow, the risk boundary is no longer just the prompt. An MCP gateway gives platform and security teams a hard enforcement point on actions, not just outputs.

Control which tools agents can reach

Allowlist known MCP servers, expose only approved tools, and block destructive actions before an agent can call them, regardless of what the model decides.

Enforce policy before execution

Authenticate every caller, check access grants, inspect payloads, and reject requests that fail safety, budget, or compliance rules before any upstream call is made.

Generate audit-ready evidence

Attribute every tool call to a key, app, team, and user. Give security and compliance teams the records they need to review governed agent behavior, or prove it to an auditor.

What you configure

A complete MCP control surface, not just a proxy

Odock covers everything platform teams need to run MCP in production: server registration, transport and auth setup, tool-level governance, pricing, and usage records your security team can actually read.

MCP views
Selected view

Register servers from a trusted catalog or add them manually. Review transport, auth config, scope, and enabled status before any agent can reach them.

catalog-&-setup.mcp
Live
github-tools-http
Trusted catalog
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:support
Access12 keys granted
internal-ops-sse
Manual setup
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_ops_prod
Access1 key granted
filesystem-agent
Manual setup
TransportSTDIO
AuthNONE
Scopeorg-wide
Access4 keys granted
slack-tools-http
Trusted catalog
TransportSTREAMABLE_HTTP
AuthBEARER
Scopeteam:success
Access8 keys granted
notion-knowledge-http
Trusted catalog
TransportSSE
AuthOAUTH2
ScopeapiKey:vk_product_ai
Access3 keys granted
postgres-ops-stdio
Manual setup
TransportSTDIO
AuthNONE
Scopeorg-wide
Access2 keys granted
One endpoint

Your agents call Odock. Not the upstream server

Point every agent to `/v1/mcp/{slug}`. Odock authenticates the caller, confirms access, injects upstream credentials, runs governance checks, and records the outcome. The upstream server never receives an ungoverned request.

What the gateway handles

  • Call any server by slug, no upstream URLs in agent code.
  • Virtual API key required before any tool is reachable.
  • Upstream auth injected after governance checks pass.
  • HTTP, SSE, and STDIO through one governed endpoint.
mcp_client.py
MCP
Method
Language
1
# Use Odock's MCP endpoint directly from the official Python MCP client
2
import asyncio
3
import os
4
 
5
from mcp import ClientSession
6
from mcp.client.streamable_http import streamable_http_client
7
 
8
async def main():
9
    async with streamable_http_client(
10
        os.environ["ODOCK_MCP_URL"],
11
        headers={"Authorization": f"Bearer {os.environ['ODOCK_API_KEY']}"},
12
    ) as (read_stream, write_stream, _):
13
        async with ClientSession(read_stream, write_stream) as session:
14
            await session.initialize()
15
            result = await session.call_tool("get_me", arguments={})
16
            print(result)
17
 
18
asyncio.run(main())
EU AI Act & compliance readiness

Close the audit gap in your agent workflows

Compliance programs need answers to specific questions: who was authorized to use which tool, under what policy, with what evidence? An ungoverned MCP layer can't answer those questions. Odock can.

  • Route remote MCP servers, and internal workflow tools through one governed, auditable endpoint
  • Reduce prompt injection risk by enforcing tool access constraints outside the agent runtime
  • Produce evidence for internal AI reviews, vendor assessments, and EU AI Act compliance programs
  • Keep LLM traffic and tool traffic inside the same policy and operational boundary
FAQ

Questions teams ask about MCP gateways

These are the recurring questions that come up when teams move from direct MCP server access to a governed gateway layer.

Your agents need a gateway, not just a proxy

If your agents can call tools, you need the same level of control you already expect for model traffic. Odock governs both from a single request path.

Book a demoRead the MCP governance guide
mcp_client.py
# Use Odock's MCP endpoint directly from the official Python MCP clientimport asyncioimport os from mcp import ClientSessionfrom mcp.client.streamable_http import streamable_http_client async def main():    async with streamable_http_client(        os.environ["ODOCK_MCP_URL"],        headers={"Authorization": f"Bearer {os.environ['ODOCK_API_KEY']}"},    ) as (read_stream, write_stream, _):        async with ClientSession(read_stream, write_stream) as session:            await session.initialize()            result = await session.call_tool("get_me", arguments={})            print(result) asyncio.run(main())