MCP Server

Connect a custom agent (LangChain, LlamaIndex, or your own) to your database

a custom agent (LangChain, LlamaIndex, or your own) can read your real data over the Model Context Protocol without ever holding a database password. Point it at a DBShifts Agent Gateway instead: you choose the tables and columns it may read, PII is masked before results leave the server, results are row-capped and rate-limited, and every single query is logged.

Start freeHow Agent Gateway works

a custom agent (LangChain, LlamaIndex, or your own) MCP configuration

Config file: wherever your agent framework registers MCP servers — or call the endpoint directly

# The MCP endpoint is plain JSON-RPC 2.0 over HTTP — no SDK required.
curl -X POST https://dbshifts.com/api/v1/agent-gateways/mcp \
  -H "Authorization: Bearer agt_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list"
  }'

Transport is the JSON-response mode of MCP Streamable HTTP — a normal JSON body, not SSE — so any HTTP client works. Protocol version 2025-06-18.

Where the token lives in LangChain & Custom Agent

A gateway token is a credential. Each client stores it somewhere different, and that changes what it should be scoped to.

There is no config file, so there is no default hiding place

You decide where the token lives, which means it belongs in your secret store or an environment variable — never inline in the source that calls the endpoint. The curl above shows the header literally for readability; code that ships should read it from the environment.

A server process serves many people

Unlike a desktop client, one agent process usually acts for a whole application. A single shared token makes every audit line read as the application rather than the person. Token exchange binds a short-lived token to the end user your app already authenticated, so the audit log records who actually asked.

The endpoint is the whole boundary

Anything that can reach the URL with a valid token gets exactly what that token allows — there is no client UI in the way to constrain it. Rotate on a schedule, keep one token per deployment so a leak has a blast radius you can name, and watch the gateway's own anomaly alerts rather than relying on the caller behaving.

How it works

01

Register the database

Connect it once with read-only credentials. The schema is introspected and scanned for PII automatically — you see what's sensitive before anything is exposed.

02

Set the policy

Pick the tables and columns agents may read. Set PII masking, a row cap, a rate limit, and daily/monthly usage budgets. Default is deny.

03

Issue a scoped token

One agt_ token per agent, revocable independently, optionally IP-bound and time-windowed. Never your database password.

04

Point the agent at it

Drop the endpoint and token into your client's MCP config. Every call is policy-checked, masked, capped and logged.

Tools the agent gets

Exactly the 26 tools the MCP server exposes — no raw SQL is accepted from the agent on any of them. What each one does.

Readlist_tables, query_table, list_views, query_view, aggregate_table, query_related
Retrievallist_search_indexes, search
Metricslist_metrics, query_metric
Background jobssubmit_job, get_job, list_jobs, cancel_job
Change feedslist_feeds, subscribe_changes, poll_changes, unsubscribe_changes
Historylist_history, diff_history, query_at_commit
Access requestsrequest_access, list_access_requests
Writes (human-approved)list_actions, propose_action, propose_action_plan

Frequently asked questions

Do I have to give a custom agent (LangChain, LlamaIndex, or your own) my database password?

No — that's the entire point. The agent authenticates with a scoped agt_ token issued by the gateway. The database credentials stay on the server and are never sent to the agent, the model provider, or the client machine. Revoke a token and that agent loses access immediately, without touching any other agent or rotating your database password.

Can the agent read columns I haven't allowed?

No. The policy is default-deny: an agent sees only the tables and columns you explicitly allow. Denied columns are not returned, and PII columns are masked server-side before results ever leave the gateway — including inside aggregates, so a masked column can't be grouped or filtered back into visibility.

Can the agent modify or delete data?

Reads are read-only by construction. Writes exist only as named, parameterized actions you define in advance — the agent can propose one, but a human approves it (in-app or from Slack) before anything executes. Approved writes are audited and carry a one-click undo, plus a version-controlled history of the affected table.

What stops an agent from pulling the entire database?

Layered limits: a per-query row cap, a per-minute rate limit, and cumulative usage budgets (daily queries, daily rows, monthly rows) per token and gateway-wide. Tokens can also be IP-bound and time-windowed, so a leaked token is useless outside your network or outside working hours.

How do I see what the agent actually did?

Every call is logged: which token, which tool, which table, which columns were masked, how many rows came back, and what was denied. You can replay any logged read to see exactly what the agent saw at the time.

Ship agents without betting the database on them.

Free to start — no card. Read-only, masked, rate-limited, fully audited.

Get started