Resource
How to build an MCP connector for a custom database
A custom database (Postgres, MySQL, SQL Server, or an internal one) is not in any connector directory, so there is nothing to install off the shelf. The way to give Claude useful access is a connector that turns specific queries and write actions into named tools. Here is how that connector is built, and how to keep it safe.
Key takeaways
- An MCP connector for a custom database is a small server that exposes specific queries and write actions as named tools Claude can call, not raw SQL access to your whole schema.
- The core work is mapping your tables and relationships to a handful of read and write tools, each scoped to the rows and columns Claude should touch.
- Reads (select, aggregate, search) run freely; writes that insert or update flow inside a conversation you start, while destructive actions like delete are gated behind a confirmation.
- The connector authenticates with a database role you define, so Claude never gets more access than that role already has.
- You can build it yourself against the MCP spec, or have it built and maintained for you so it keeps working as your schema changes.
How do I build an MCP connector for a custom database?
To build an MCP connector for a custom database, you write a small server that connects to the database with a scoped role and exposes specific queries and write actions as MCP tools. Claude calls those named tools over the Model Context Protocol instead of touching the database or its schema directly.
The connector sits between Claude and your database. On one side it speaks the Model Context Protocol to Claude; on the other it speaks SQL (or your driver of choice) to the database. The design work is deciding which operations to expose: a tool to search customers, a tool to fetch an order with its line items, a tool to create a ticket. Each tool is a deliberate, named capability, which is what makes the connector predictable. For the full picture of how MCP connectors fit together, see the complete guide to custom Claude connectors.
What are the steps to build a database connector?
The steps to build a database connector are: map the tables and relationships Claude needs, design a small set of read and write tools around real tasks, connect with a scoped database role, add confirmations for destructive actions, then host the server and add it in Claude. Maintenance follows as the schema changes.
- 01
Map the schema to tasks
Start from what people want to do, not from every table. List the questions Claude should answer and the records it should change, then trace those to the tables, joins, and columns involved. This is also where you decide which columns stay out of reach, like secrets or unrelated personal data.
- 02
Design named tools
Turn each task into a tool with a clear name and typed inputs: search orders by status, get a customer profile, create a support ticket, update a record's stage. Parameterize queries so inputs are bound, never concatenated, which keeps the tools safe from injection and easy to reason about.
- 03
Scope the database role
Create a dedicated database role or service account for the connector and grant it only the privileges its tools need: select on read tables, insert or update on write tables, nothing more. Claude then inherits exactly that role's reach and nothing beyond it.
- 04
Gate the risky writes
Let routine create and update tools run inside a conversation, and put a human confirmation in front of anything destructive or outbound (deleting rows, bulk updates, or actions that leave the system). The split is set during scoping so it matches how your team actually works.
- 05
Host, connect, and maintain
Run the server somewhere it can reach the database (inside the private network if needed), add the connector in Claude, and plan for upkeep. Schemas, drivers, and credentials change, so the connector needs maintenance to keep working rather than breaking on the first rename.
Should I expose raw SQL or named tools?
Expose named tools, not raw SQL, for almost every custom database. A run-any-SQL tool hands Claude your entire schema and every write path at once, which is hard to scope and easy to misuse. Named tools map to specific operations, so behavior stays predictable and access stays exactly where you drew the line.
| Concern | One raw SQL tool | Named, scoped tools |
|---|---|---|
| Access boundary | Whole schema and all writes | Only the tables, columns, and actions you expose |
| Predictability | Depends on the query Claude composes | Each tool does one known thing |
| Injection risk | High if any input is concatenated | Low with bound parameters |
| Confirmation gating | Hard to gate, every query looks the same | Destructive tools gated individually |
| Maintainability | Breaks quietly when the schema shifts | Failures localize to one tool |
There is a place for read-only exploratory querying behind a tightly scoped, read-only role, but it should be the exception, not the foundation. The dependable pattern is a small library of named tools that match the work your team does.
How do I keep writes to my database safe?
You keep database writes safe by scoping the role, naming the write tools, and gating the dangerous ones. The connector authenticates as a role with only the insert and update grants it needs, each write tool changes a known set of fields, and destructive actions like delete pause for a confirmation you approve.
The key property is that the connector never grants more access than the database role behind it already has, so it is a narrow extension of permissions you already trust, not a new and broader set. This is the same scoped read-write model we use for internal tools and in-house systems. If your database sits behind an application rather than being queried directly, the connector can call that application's API instead, and the same scoping rules apply.
Should I build it myself or have it built?
Build it yourself if you have engineers with the time to design the tools, scope the role, and own ongoing maintenance. Have it built if you would rather skip that and get a hosted, maintained connector. Either path produces the same architecture: named tools, a scoped role, and confirmations on destructive writes.
The part teams underestimate is maintenance. A connector is not a one-off script; it has to keep working as columns are renamed, drivers are upgraded, and credentials rotate. That is the difference between something that breaks the first week and something your team relies on in production. To see the databases and tools we already build connectors for, browse the connectors we support.
Frequently asked questions
How do I build an MCP connector for a custom database?
Should I let Claude run arbitrary SQL against my database?
Which databases can an MCP connector work with?
How does authentication and permission scoping work?
Can the connector reach a database that is not on the public internet?
Do I have to build and maintain it myself?
Have a custom database you want Claude to use?
Book a 30-minute scoping call. We'll map your schema to a small set of tools, scope the database role, and decide what stays gated.