MCP Database Access for AI Agents: How Claix Retrieve and Guard Add the Control MCP Doesn't

Key points at a glance

What MCP is, and what it is not

MCP is an open protocol that lets an AI application (the client) discover and call tools exposed by a server. It solves a real integration problem: instead of writing a custom connector for every tool and every model, you write one server and any compatible client can use it.

What MCP does not do is decide what the agent should be allowed to do with a tool. It standardises the call, not the policy. Think of it as a better phone line to your database. The line is clearer and more convenient, but nobody on it is deciding which questions may be asked or which changes may be made.

What a raw database MCP server gives your agent

A typical database MCP server exposes tools such as list_tables, describe_table and execute_sql. That is great for developers: an assistant can explore a schema, test a query and propose a migration in seconds.

Put the same server in front of an agent that works on live customer data and the picture changes:

• The model writes the SQL. Whatever it writes runs with the permissions of the database role.
• The only brake is the role. Read-only roles are a good baseline, but they are not a full policy. Datadog Security Labs published a case study of an SQL injection in the PostgreSQL MCP server where a COMMIT inside the input let a query escape the read-only transaction the server relied on.
• There are no business rules. A role can say who may update a table. It cannot say that a discount may not exceed 20 percent or that no more than five rows may change in one statement.
• Every agent rediscovers the schema on every conversation, which costs tokens and invites mistakes.

This is not a flaw in the protocol. It is simply what a connector is: a door, with nobody deciding what happens behind it.

Why MCP plus a SQL-writing agent, or structured outputs, still leaves gaps

There are three common patterns on top of a raw MCP server: let the main agent write SQL, add a dedicated sub-agent that generates SQL, or force the answer into a JSON schema with structured outputs. They help, and each leaves the same gaps.

• Structured outputs guarantee the shape of an answer, not its truth. A response can be perfectly valid JSON and still contain an invented number, because the model was required to fill a field and the data was not there. Structured outputs also say nothing about whether a statement is safe to run.
• A better SQL-writing agent is still a model deciding what to run. A more careful prompt or a second model reduces mistakes, but both are probabilistic. A check that must hold every time needs to live outside the model.
• Neither pattern gives you per-agent limits, a kill switch or an audit trail. Those are operations features, not model features.

How Claix Retrieve works with MCP

Claix Retrieve connects to a SQL database (PostgreSQL, MySQL, MariaDB or Supabase) through a read-only role. You decide which tables, columns and relationships each agent can use, with a short guide written in your own vocabulary. Claix drafts a Data Map of the schema for you to review, and that map is shared across your agents.

Your agent reaches Retrieve over MCP (the tool is claix.retrieve.ask), REST or A2A. The difference from a raw database server is what the agent sends and what it gets back:

Because Retrieve is an MCP server, adopting it does not change how your agent connects. You swap one tool for another.

Where a raw MCP server is still the better choice

Being honest about this matters. A raw MCP server is the better tool for development, for exploring an unfamiliar schema, for one-off analysis and for cases where you want the model to write any query it likes. It is free, flexible and has no extra moving part. Retrieve is for the moment an agent starts acting on production data for real users.

How Claix Guard works as the check before execute_sql

If your agent must write to the database through an MCP tool, the safest place to add control is the single point where a statement is about to run. Claix Guard is a rules checker for exactly that moment.

• You describe your rules in plain English, for example: Discounts cannot exceed 20 percent. Agents can never delete orders. No statement may change more than five rows.
• Claix turns them into exact rules with test cases, and you review, accept or edit them.
• Before the statement runs, your code sends it to Guard and gets back allow or deny with a reason.
• No AI model decides at check time, and Claix never executes the statement. Your code does.

Agent -> proposes SQL -> your wrapper -> POST /check-sql (Claix Guard)
                                   |- allowed -> MCP execute_sql -> database
                                   |- denied  -> reason returned to the agent

Here is the pattern in Python. The agent is given guarded_execute_sql as its tool, and the raw execute_sql is not exposed to it at all:

import os
import httpx

CLAIX_HEADERS = {'x-api-key': os.environ['CLAIX_API_KEY']}

async def guarded_execute_sql(mcp_session, sql: str):
    # 1. Ask Guard first. Send one statement per check.
    async with httpx.AsyncClient(timeout=10) as http:
        resp = await http.post(
            'https://claix.dev/check-sql',
            headers=CLAIX_HEADERS,
            json={'sql': sql},
        )
    resp.raise_for_status()  # any error means fail closed
    verdict = resp.json()

    # 2. Only an explicit allow reaches the database MCP server.
    if not verdict['allowed']:
        return 'Blocked by Claix Guard: ' + verdict['reason']

    # 3. Forward exactly the statement that was checked.
    return await mcp_session.call_tool('execute_sql', {'query': sql})

The argument name (query in this example) depends on the MCP server you use. A denied response looks like this (values are placeholders):

{
  "allowed": false,
  "decision_id": "<uuid>",
  "code": "<code>",
  "reason": "<why the statement was denied>",
  "operation": "delete",
  "table": "orders",
  "violations": [{ "guard_name": "<guard>", "rule_title": "<rule>", "message": "<message>" }],
  "rules_checked": 3,
  "latency_ms": 0
}

Because the reason is written in plain language, the agent can read it and propose a different change instead of failing with a cryptic database error.

Rules for using Guard safely

• Make it the only path. Guard decides, your code enforces. If the agent can still reach a raw execute_sql, the check can be skipped. Expose only the guarded tool.
• Fail closed. If the call fails, times out or returns anything other than an explicit allow, do not run the statement.
• Check exactly what you run. Send the same statement you forward, and refuse input that contains more than one statement.
• Treat anything not explicitly allowed as denied, including statement types you did not expect.
• Keep database permissions tight anyway. Guard is an additional layer, not a replacement for least-privilege roles.

Putting it together: reads through Retrieve, writes through Guard

The same principle runs through all of it: MCP is the door, and Claix decides what is behind it.

Pricing

Every account has 30 successful calls per month free. Retrieve costs €0.10 per question with Claix Managed AI, or €0.02 with your own LLM key (you pay your provider for tokens). Guard costs €0.01 per check. You pay only for successful calls (HTTP 200); authentication errors, invalid requests and server errors are free.

Conclusion

MCP made it easy to connect agents to data, and that is exactly why control matters more, not less. A raw database MCP server is a better phone call to your database; it is not a policy. Use Claix Retrieve when an agent should read live data without writing SQL, and put Claix Guard in front of execute_sql when it needs to change data. Keep your raw MCP server for development, and let the agent in production work behind a layer that says yes or no, with the reason.

Try Claix free: 30 successful calls per month. Start at https://www.claix.dev/register.