"How many orders did we ship to Mumbai last week?" "What's the status of the ticket the client asked about?" In most companies, questions like these go to an engineer, who stops what they're doing to run a query. It's a small interruption, twenty times a day.
As an engineer, I know how quickly those interruptions add up. There's now a clean, safe way to let people answer them themselves.
What it looks like
- 1Someone asks in plain English
- 2Claude decides which tool to check
- 3Runs a read-only query
- 4Answers in a sentence or table
- 5Everything logged
Someone in operations types "Which customers haven't reordered in 60 days?" and gets a table back. No SQL, no ticket to engineering, no waiting.
What MCP is, briefly
The Model Context Protocol is an open standard for connecting AI assistants to other systems. Instead of building a custom integration for each tool, you run small "MCP servers" for your database, your ticket tracker (like Linear or Jira) and your docs (like Notion). Claude can then use them when it needs to.
Doing it safely
This is the part I care about most, and it's where I'd be strict:
- Read-only database user. It can look, never change.
- Scoped by role. Sales sees sales data, not payroll.
- A replica, not production, if the database is busy.
- Every query logged: who asked, what ran, what came back.
- No secrets in prompts. Credentials stay on the server.
Good first questions to support
- Order, shipment and inventory lookups.
- "What's the status of…" for tickets and projects.
- Finding the right internal doc or decision.
- Simple weekly numbers that someone currently builds by hand.
Questions people ask me
Do we need to use Claude specifically?
MCP started with Claude and is now supported by other assistants too. We usually recommend Claude for this, but the setup isn't locked to it.
Can it make changes, like updating a ticket?
It can, but I'd start read-only. Add write actions one at a time, each with a confirmation step.
We set this up as part of custom AI builds and enterprise projects.
Founder of Overtake. I was a founding engineer at four startups, two of them in Y Combinator. I write about the AI systems I build for small businesses: what works, what doesn't, and how to start.
About meFollow on X