MCP Server for Database: Connect Claude, ChatGPT and Cursor Safely

A support engineer at a mid-sized SaaS company spends 20 minutes most mornings pulling account status, usage numbers and billing history out of the production database to answer a single Slack question from a customer success manager. Multiply that by six or seven questions a day across a small team, and it is easily 10-15 hours a week of people acting as a manual query interface between a database and a chat window. None of that time shows up on an invoice, but it is real payroll cost, and it delays the answers customers are waiting on.

The fix that teams in the US, UK, Canada, Singapore and the UAE are increasingly reaching for is an MCP server for database access — a small, permissioned service that lets Claude, ChatGPT or Cursor query the database directly, using read-only tools with defined scopes, instead of a person running SQL by hand or copying rows into a spreadsheet. Done properly, it turns "can someone check the database" into a 10-second AI-assisted lookup, with logging and rate limits attached.

This guide covers what such a server actually does, how it gets built and deployed, what it costs, and the compliance questions worth asking before you connect any AI assistant to production data. Bharat AI Saathi builds these as a fixed-scope product called Custom MCP Server; details are on the offer page.

What Custom MCP Server actually does

Model Context Protocol (MCP) is the open standard that Anthropic introduced for connecting AI assistants to external tools and data sources over a defined transport. A database is not naturally "speakable" by an AI model — an MCP server sits between the two and exposes a fixed set of tools, each one mapped to a specific, reviewed action: get_customer_by_id, list_open_invoices, search_orders_by_date_range, and so on.

This is a deliberate design choice, not a shortcut. The server does not hand an AI model raw SQL access to your production database. Each tool has a defined schema, input validation, and — in our implementation — a scope boundary (read-only by default, write actions only where explicitly approved). The server also handles authentication (OAuth or API key), request logging, and rate limiting, so every query an AI assistant makes is attributable and auditable.

The deliverable is a working server built on the TypeScript or Python MCP SDK, using streamable HTTP transport, deployed to Cloudflare Workers or Docker, with conformance tests, documentation, and a listing in the official MCP registry so the tools are discoverable from Claude Desktop, Cursor and ChatGPT client configs.

How it works, step by step

1. Kickoff call — we map your database schema, your API layer (if one already exists in front of the database), and the specific questions staff or customers currently ask by hand.
2. Tool design — each recurring query becomes a named MCP tool with an input schema (e.g. customer_id: string) and an output schema, typically 3-6 tools for a first release, up to 15 for larger scopes.
3. Auth and access layer — we wire OAuth 2.1 or scoped API keys, and decide per-tool whether it is read-only or has write permission, matched against your existing role-based access rules.
4. Server build — implementation in TypeScript or Python against the official MCP SDK, with input validation, rate limiting and structured logging on every call.
5. Conformance testing and deployment — automated tests against the MCP spec, then deployment to Cloudflare Workers (or Docker on your own infra) with monitoring in place.
6. Registry listing and client configs — the server is listed in the official MCP registry, and we hand over ready-to-paste configuration for Claude Desktop, Cursor and ChatGPT.
7. Daily operation — staff or customer-facing AI assistants query the server directly; every call is logged for review.

Trigger: Support lead in Claude Desktop asks, "What's the current plan and last payment date for account acme-corp?" Action: Claude calls the get_account_billing_summary tool with account_slug: "acme-corp". Action: MCP server validates the request, checks the caller's API key scope, queries the read replica, returns plan tier, renewal date and last payment status. Customer: Response appears in Claude within seconds, with a note that the query was logged under the support lead's key.

Before and after

What it costs and what is included

No lock-in: the server, code and registry listing are yours, and the care plan can be cancelled without losing the underlying system. The payback logic is straightforward — if manual database lookups currently consume even a few hours of staff time a week, a one-time setup fee is typically recovered within a few months of reduced ad hoc query load, though actual savings depend on your team's current workflow.

Delivery timeline

Day 0 — Kickoff

Schema review, tool list agreed, auth method (OAuth vs API key) decided, access scopes signed off.

Days 1-7 — Build

Tool schemas implemented, server built against the MCP SDK, auth and rate limiting wired in, conformance tests written and run.

Days 8-10 — Go-live

Deployment to Cloudflare Workers or Docker, registry listing submitted, client configs delivered for Claude, Cursor and ChatGPT, walkthrough call.

What you need to have ready

• Read access to (or a description of) your database schema
• A list of the queries or actions staff currently perform manually
• Decision on which actions should be write-enabled versus strictly read-only
• Existing API layer credentials, if a REST or GraphQL layer already sits in front of the database
• Sign-off from whoever owns data access policy (security, compliance, or engineering lead)
• Any data residency requirements (e.g. EU data must stay in EU-hosted infrastructure)
• A production-adjacent staging database or read replica for testing, if available

Doing it yourself vs done-for-you

Compliance and risk notes

• Scope every tool to the minimum data it needs to return — avoid exposing full-table access through a single overly broad tool.
• Treat AI-assistant queries as you would any other application access: log them, and review logs periodically, not just at setup.
• Confirm data residency requirements before choosing a hosting region, especially for customer data covered by GDPR or similar regimes.
• Keep write-enabled tools to a deliberate, reviewed minimum — read-only is the safer default for most database use cases.
• Review the terms of service for each AI platform (Anthropic, OpenAI, client apps) regarding how query data may be retained or used.
• This is general operational guidance, not legal advice — consult your own counsel or compliance team for regulated data categories such as health or financial records.

Mistakes buyers make

• Exposing raw SQL instead of scoped tools — fix: define named tools with fixed schemas, never a generic "run query" tool against production.
• Skipping rate limiting — fix: set per-key limits from day one; an AI assistant can generate call volume faster than a human user would.
• No distinction between read and write access — fix: default everything to read-only, and add write tools only with explicit sign-off.
• Forgetting to plan for spec updates — fix: the MCP spec evolves; either budget in-house time to track it or use a care plan that covers it.
• Building against production directly during testing — fix: test tools against a staging database or read replica before go-live.

FAQ

What is an MCP server for a database, in plain terms?

It is a small service that sits between your database and an AI assistant, exposing a fixed set of safe, named actions (tools) instead of open query access, with authentication and logging attached to every call.

Can this work with my existing REST API instead of a raw database connection?

Yes — if you already have an API layer, the MCP server typically wraps that layer rather than connecting to the database directly, which usually simplifies auth and reduces risk.

Will this give AI models write access to my database?

Only if you explicitly choose to enable specific write tools. The default approach is read-only, and write actions are added deliberately, scoped narrowly, and reviewed before go-live.

How many tools do we actually need to start?

Most teams start with 3-6 tools covering their most common manual lookups, then expand. The base package covers up to 15 tools, and the care plan adds 2 new tools per month afterward.

What happens to the server if we cancel the monthly care plan?

The server keeps running as deployed; you lose ongoing hosting management, spec-version updates and new tool additions, but there is no lock-in forcing continued payment.

Do we need to be technical to use this once it is built?

No — day-to-day use is through Claude, Cursor or ChatGPT with the provided client configs. Technical involvement is mainly needed at the schema and access-scope review stage.

Next step

Email support@bharataisaathi.com or message via WhatsApp with your database type, existing API layer (if any), and the top 3-5 queries your team currently runs by hand. See the full scope on the Custom MCP Server offer page, or read how we work before kickoff.