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
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
}
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.
tools-list.sh
1# Call Odock instead of the upstream MCP server
2curl "$ODOCK_GATEWAY_URL/v1/mcp/github-tools-http" \
3 -H "Authorization: Bearer $ODOCK_API_KEY" \
4 -H "Content-Type: application/json" \
5 -d '{
6 "jsonrpc": "2.0",
7 "id": "tools-list-1",
8 "method": "tools/list",
9 "params": {}
10 }'
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
tools-list.sh
# Call Odock instead of the upstream MCP servercurl "$ODOCK_GATEWAY_URL/v1/mcp/github-tools-http" \  -H "Authorization: Bearer $ODOCK_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "jsonrpc": "2.0",    "id": "tools-list-1",    "method": "tools/list",    "params": {}  }'