What Is MCP, and Why Should Anyone Working With a Database Care?

You've probably done this at least once: an AI assistant is helping you debug a query, and to get real answers you paste in a connection string, or worse, a chunk of production data. It works. It also means your database URL now lives in a chat log, a prompt history, and possibly a vendor's training pipeline. Multiply that by everyone on your team doing the same thing, and you've quietly scattered credentials across a dozen surfaces you can't rotate or audit.

The Model Context Protocol (MCP) exists to make that whole pattern unnecessary. It's an open standard for connecting AI assistants to external systems — databases, APIs, file stores — through a structured interface instead of copy-paste. For anyone who works with a SQL database daily, it's worth understanding, because it changes the answer to a question you probably ask a lot lately: "How do I let an AI help with my data without handing it the keys?"

This is a conceptual tour, not a product pitch. By the end you'll know what MCP actually is, why the architecture matters for security, and where teams trip up.

The core idea: a broker sits between the AI and your database

MCP is a client-server protocol. Your AI tool (Claude, Cursor, ChatGPT, VS Code, and a growing list of others) is the client. On the other side is an MCP server — a small service that exposes a specific set of capabilities as "tools" the AI can call.

The important part is what the server does for the database: it holds the connection. The AI never receives your credentials. It sees a menu of tools — something like list_tables, get_schema, run_query — and calls them. The server authenticates to the database, runs the operation, and returns only the result.

Think of it like a bartender. You don't get handed the keys to the liquor room; you ask for a drink, and someone with the keys pours it. The AI asks questions; the broker with database access answers them.

Here's roughly what a client sees when it lists available tools:

{
  "tools": [
    { "name": "list_databases", "description": "List accessible databases" },
    { "name": "get_schema",     "description": "Return tables and columns for a database" },
    { "name": "run_query",      "description": "Execute a read-only SQL SELECT" }
  ]
}

And a typical exchange, from a plain-English question to real SQL:

User:  "How many trial users signed up last week but never activated?"

AI →   calls get_schema  → learns tables: users, subscriptions, events
AI →   calls run_query with:

       SELECT COUNT(*)
       FROM users u
       LEFT JOIN events e
         ON e.user_id = u.id AND e.name = 'activated'
       WHERE u.plan = 'trial'
         AND u.created_at >= NOW() - INTERVAL '7 days'
         AND e.id IS NULL;

Server → runs it against the DB, returns: 342

At no point did the AI need your database password. It needed the schema (so it could write valid SQL) and a tool to run the query. That separation is the whole game.

Why this matters more than it first appears

Once the broker pattern is in place, a series of good properties fall out of it almost for free.

Credentials stay out of prompts. The single most common way secrets leak today is ending up in a chat window. If the AI never needs them, they can't leak that way. As of the mid-2025 MCP spec, the protocol standardized on OAuth 2.1 for authenticated servers, meaning access can be short-lived, scoped, and centrally revocable instead of a long-lived string pasted into a config file.

Read-only by design is enforceable. A well-built database MCP server can reject anything that isn't a SELECT. No UPDATE, no DROP, no DELETE. That lets an AI freely explore your data — count rows, profile columns, test hypotheses — with zero risk of it modifying anything. The right way to back this up is at the database itself: create a dedicated user with a read-only role and connect the server as that user, so even a bug can't write.

-- The database enforces what the broker promises
CREATE ROLE ai_readonly LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE app TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;
-- No INSERT/UPDATE/DELETE granted, ever

People don't need direct database access. This is the quiet win. A support engineer or a founder can ask questions in English and get answers, without you ever provisioning them a psql login. Access to ask is decoupled from access to connect.

Row-level security composes with it. If your database already uses RLS, those policies apply transparently to AI-generated queries too. Point each MCP connection at a per-user or per-tenant role, and the AI physically cannot return rows that role can't see — no matter how the prompt is phrased. That's what makes "give each customer natural-language access to only their own data" a realistic feature rather than a scary one.

Approach	Where credentials live	Write risk	Revoke access
Paste connection string into AI	Chat logs, prompt history	Full (whatever the string allows)	Rotate the secret everywhere
Give each person a DB login	Scattered across machines	Depends on grants	Per-user, but manual
MCP broker (read-only role + OAuth)	Only on the server	None if SELECT-only enforced	Central, revoke a token

Schema-awareness kills a lot of hallucinations

A subtle benefit: because the AI can call get_schema before writing SQL, it works from your actual table and column names instead of guessing. Half the frustration with AI-written SQL — SELECT customer_name FROM clients when your table is users and the column is full_name — comes from the model not knowing your schema. Give it the schema through a tool call, and hallucinated tables and columns drop sharply. You're grounding the model in reality instead of hoping it guessed your naming convention.

The gotchas nobody mentions up front

MCP fixes the credential-leak problem. It does not magically make AI-plus-database safe. A few things to keep front of mind:

Prompt injection is real, and databases are an attack surface. If your AI agent reads untrusted content — support tickets, user-submitted rows, log entries — an attacker can embed instructions in that text. In a mid-2025 incident, a support-ticket agent with privileged database access was manipulated into reading and leaking sensitive tokens, because it treated data from the database as trusted commands. The agent couldn't tell data from instructions. The defense is the same discipline as above: least privilege (read-only, scoped roles) so that even a hijacked agent can't do much damage.

"Read-only" has to be enforced, not just promised. A server that merely intends to run SELECTs isn't enough. Back it with a database role that literally lacks write grants. Belt and suspenders.

Least-privilege beats "connect as admin." It's tempting to point an MCP server at a superuser so "everything just works." Don't. Give it the narrowest role that does the job. A large fraction of documented MCP incidents trace back to over-broad permissions.

Not every MCP server is trustworthy. Community servers vary wildly in quality; one widely-forked example shipped a SQL-injection flaw into thousands of downstream projects. Read the code, or use a managed server from a source you trust, and validate inputs at every boundary.

Where this leaves you

If you take one thing away: MCP moves the trust boundary. The AI stops being something you feed credentials and starts being something that requests operations through a broker that holds the credentials. That's a better shape for security, for onboarding non-technical teammates, and for exposing safe, self-serve data access to customers.

You can self-host an open-source MCP server for Postgres, MySQL, or SQL Server, or use a managed one. As one example of the managed flavor, Draxlr runs an MCP server (docs) you connect over OAuth that's read-only by design and can list schema, run and save queries, and build dashboards — a concrete instance of the patterns above. But the pattern matters more than any one implementation: broker holds the connection, AI holds nothing.

Key takeaways

• MCP is an open protocol that connects AI tools to systems like databases through a structured tool interface instead of pasted credentials.
• A broker (the MCP server) holds the database connection; the AI never sees your secrets.
• Read-only roles, OAuth-based revocable access, and row-level security all compose cleanly with it.
• Schema-awareness through tool calls sharply reduces hallucinated tables and columns.
• It's not a security silver bullet — prompt injection and over-broad permissions still bite. Least privilege is your best friend.

Are you connecting AI to your database yet — self-hosted MCP, a managed server, or still copy-pasting into a chat window? What's worked and what's burned you? Drop it in the comments; I'd genuinely like to hear how teams are drawing the line.