Let agents use MCP tools without handing over the keys.
The Model Context Protocol makes it easy to connect an agent to a database, ticketing system, or file store. It does not decide which agent should be allowed to call which tool. Data.co's MCP gateway sits between agents and servers and makes that decision on every call.
One gateway in front of every MCP server.
MCP connects tools. It does not govern them.
An MCP server exposes tools with names, descriptions, and arguments. Any client that can reach it can usually call any tool it offers. Tool descriptions themselves can carry instructions that a model may follow. Teams wiring MCP servers directly to agents end up with broad, unlogged access to production systems.
The Data.co MCP gateway registers each server and its tools, exposes only the tools you have enabled, and evaluates every call against policy using the calling agent's identity, the user it acts for, the tool, and the arguments. Destructive calls can require approval. Every call and its decision are written to the audit log.
What the gateway enforces.
Server registry
Only registered MCP servers are reachable through the gateway, each with an owner and approval status.
Tool registration
Each tool is registered with its schema, risk level, and side effects, and stays disabled until someone enables it. New tools are never exposed automatically.
Argument conditions
Policies can inspect arguments, such as denying SQL statements of certain classes or restricting paths.
Per-tool approval
Writes, sends, and deletes can pause for a named approver.
Result filtering
Results containing labeled data can be filtered or masked before returning to the agent.
Credential isolation
Downstream credentials stay in the gateway. Agents never hold database passwords or API keys.
Registering a server and scoping its tools.
id: mcp_tickets
owner: it-platform
transport: streamable-http
url: http://tickets-mcp.internal:8080/mcp
credentials: { secret_ref: vault://mcp/tickets }
tools_reviewed_at: 2026-10-14
status: approvedIllustrative example · final API surface documented in /docs
A coding assistant asks to drop a table.
A developer's assistant is connected to a database MCP server through the gateway, acting on the developer's behalf.
- 1
Discover
On tools/list, the gateway returns only the enabled tools this identity is scoped for. Tools outside its scope are simply absent, so the model never learns they exist.
- 2
Call
The assistant calls the SQL tool with a statement that drops a staging table. The gateway classifies the statement deterministically as DROP before any policy runs.
- 3
Decide
A policy requires approval from the DBA on-call group for DROP statements through this connector. The call returns an approval-required error with the approval ID.
- 4
Approve once
A DBA reviews and approves. The identical call then succeeds one time; a repeat needs a new approval, and the developer cannot approve their own request.
- 5
Record
Each step is in the audit log: subject, tool, statement class, decision, policy IDs, and approver, without the SQL text or other argument values.
Questions to settle for each MCP server.
- Who owns the server, and who approves new tools on it
- Which tools are read-only and which have side effects
- Whether the server is reachable only from the gateway
- Which identities and tags may see each tool in tools/list
- Which calls need a named approver, and what happens on timeout
- Where the server's downstream credentials are stored and rotated
Questions buyers ask
Do we need to modify our MCP servers?
Generally no. The gateway proxies standard MCP traffic. Servers should be reachable only from the gateway so it cannot be bypassed.
Does this work with desktop MCP clients?
Clients that can be configured to connect to a remote MCP endpoint can point at the gateway. Locally launched stdio servers on a developer machine are outside the gateway unless routed through it.
How does the gateway handle tool description changes?
Clients see the tool definitions recorded in your registry, and tools a server adds later stay disabled until someone enables them. A server can also be quarantined, which hides and refuses all of its tools while a change is reviewed.
Can agents use Data.co Marketplace datasets over MCP?
Yes. Marketplace datasets are available through MCP servers and can be registered behind your gateway like any other server, subject to each dataset's license.
What does an agent see when a call is denied?
A standard JSON-RPC error that distinguishes a denial from an approval requirement, with the policy IDs involved. That lets well-built agents explain the refusal to the user instead of retrying blindly.
Does the gateway inspect tool results too?
Policies act on the call before it runs, and results containing labeled data can be filtered or masked before returning to the agent. Results from any server should still be treated as untrusted input by the model.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.