Internal integration
Your internal systems, inside Claude, without handing over the keys
One internal system, exposed to your team inside Claude and Cursor as a small, read-first set of tools. Read replica, least-privilege role, statement timeouts, no DDL, full audit log. Two weeks, from$2,000 plus $250/mo. Read-only is the default; a write happens only when you decide it should, one tool at a time, and most internal builds ship read-only and never enable one at all.
Security first, because you lead with risk
Most vendors bury the safety section on page nine. For an internal build it belongs here, because the objection is not "can it work" but "what can it reach". The answer is: exactly the tables you name, through a role that cannot do anything you did not grant, and nothing else.
Read versus write
Reading answers most of what a team wants: "what did this customer order", "which invoices are overdue", "show me last week's signups". Writing is a different risk class and a different conversation. When you need it, every write tool runs a dry-run first and returns what it would do, so a human confirms before anything changes.
CREATE ROLE mcp_read NOLOGIN;
GRANT CONNECT ON DATABASE app TO mcp_read;
GRANT USAGE ON SCHEMA public TO mcp_read;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_read;
ALTER ROLE mcp_read SET statement_timeout = '5s';
-- no INSERT / UPDATE / DELETE / DDLA worked example: eight tools
| Tool | Access |
|---|---|
| customers.search | read |
| orders.for_customer | read |
| invoices.overdue | read |
| signups.recent | read |
| inventory.levels | read |
| ticket.note_add | write · dry-run |
Where it runs
- Our infrastructure: fastest to start, lowest setup cost.
- Your infrastructure: stays inside your network boundary, small setup delta stated up front.
Internal integration questions
- Can it write to our production database?
- Only if you decide it should, one tool at a time. The default is a read replica and a least-privilege role that cannot write at all. When a write is genuinely needed, it is scoped, it requires a dry-run, and it never includes a destructive delete. Most internal builds ship read-only and stay that way.
- Which systems is this usually for?
- Three, in order: a production database people keep asking questions of, a CRM, and an internal API that already exists but is painful to query. If your data lives only in spreadsheets and PDFs, there is nothing to expose yet, and we will tell you that before you pay us.
- Where does it run?
- Your infrastructure or ours. Ours is faster to stand up and cheaper to start; yours keeps everything inside your network boundary and costs a little more to set up. We state the cost delta before you choose, as of 2026-08-05, rather than defaulting you into whichever is easier for us.
- How long does it take?
- Two weeks from a signed manifest, with a ten-prompt acceptance script defining "done". The slow part is usually access: a read-replica connection string and a sign-off on which tables the tools may touch.
- What does it cost?
- From $2,000 to build and $250 per month to maintain, for one system with up to eight tools. The retainer covers spec-revision migrations, upstream drift and monitoring. The 2026-07-28 revision is exactly the kind of change the retainer exists to absorb.