We gave Claude hands: MCP from internal tool to product feature

One morning an agent was investigating a production bug - the kind where you need to know whether a bad database row is a one-off or a pattern before you write the fix. It ran the query itself: read-only, inside our VPC, capped and time-boxed. Then it wrote the fix, with the answer in hand.

Nobody SSH'd into anything. Nobody pasted credentials into a console. The agent used the same thing our engineers now use from their editors: a small MCP server we built in an afternoon.

This post is about giving AI hands - and about the moment we realized the protocol we'd adopted for ourselves was actually a product feature.

Agents that can think but can't look

Model Context Protocol is the boring-in-a-good-way standard for connecting AI tools to real systems. Before it, our agents could reason about production but couldn't observe it, and every engineer's day contained some version of "can someone run this query for me?" - a context switch for the asker and the askee both.

The fix was deliberately small.

The server we built: read-only, capped, in-VPC

Our RDS MCP server is one Lambda, deployed twice - one instance for the beta database, one for prod. Four design choices did most of the work:

1. It sits behind API Gateway. A bare Lambda Function URL would have been simpler, but our org policy blocks unauthenticated Function URLs - and the constraint made the design better. Auth is a bearer token checked on every request.
2. The token lives in the same Secrets Manager secret as the app's database credentials. No separate secret to manage, no separate rotation runbook: rotate the secret and the server picks it up within five minutes.
3. Read-only is enforced twice. An allowlist accepts only SELECT, SHOW, DESCRIBE, EXPLAIN, and WITH - and then the database session itself is opened read-only. The allowlist is the belt; the session flag is the suspenders. A clever prompt injection can't write what the connection can't write.
4. It's bounded. Results cap at 5,000 rows, queries time out at 15 seconds, and the Lambda runs inside the VPC with no internet egress. The worst case is a slow, truncated read.

Total footprint: one Python file and one Terraform module.

The second internal server cost even less: zero code. Databricks ships a native MCP endpoint for SQL, so our warehouse was one CLI command away from every engineer's Claude session. That's the build-vs-buy lesson in miniature - check whether your vendors already speak MCP before you write anything. A third, for AWS Partner Central, checks our CRM deals for co-sell funding eligibility across four AWS programs.

Day to day, the change is bigger than it sounds. The fixer agents from earlier in this series verify production data mid-investigation instead of guessing. Engineers query beta and prod from the editor they're already in. The phrase "can someone check prod for me" has essentially left our vocabulary.

Then customers asked our question

Our customers - sales teams living in their AI assistants more every quarter - started asking the exact question our engineers had asked: why can't my AI see this data?

Because we'd already built the internal version, we knew the answer's shape. So we productized it:

1. An MCP Integrations page in the product, where an org generates credentials and connects Claude to their own Aithon data.
2. OAuth discovery endpoints implementing RFC 9728 and RFC 8414, so clients can discover and authorize the server the standard way - no bespoke setup docs.
3. A first cohort of customer orgs is live in production, feature-flag gated, one org at a time.

The internal demo that sold it: an MCP workflow that drafts a follow-up email from your calendar, your meeting notes, and the live deal context - the kind of thing that used to be a product roadmap item and is now a protocol away.

Real numbers

1. 2 internal servers we run (beta + prod RDS), 1 we got for free (the vendor's native endpoint), 1 for co-sell (4 AWS programs checked automatically).
2. 5,000-row cap, 15-second timeout, zero internet egress on the database server.
3. ~1 afternoon to build the RDS server; ~1 command to wire the vendor one.
4. First customer cohort live on the productized MCP surface, with standards-based OAuth discovery.

Where the humans sit

The internal servers are read-only by construction - two independent layers deep - so the human gate isn't a review step here, it's the design itself. Anything that writes still goes the only way writes go in this whole series: an agent opens a PR and a person merges it. On the customer side, MCP access is opt-in per organization, flag-gated, and OAuth-consented - an admin turns it on, not us.

Steal this

Your first MCP server should be a read-only query tool over the database you already have. One Lambda, an allowlist plus a read-only session, a row cap, a timeout. It's an afternoon of work, it makes every agent and engineer sharper the same day, and its security story fits in one sentence. And before you build the second one - check your vendors. The best MCP server is the one you don't write.

In two weeks, the most uncomfortable experiment we've run: agents with judgment, agents with hands, pointed at us. We asked the fleet to audit how we use AI, and it found two mistakes in our own math. Next Tuesday, the product track walks the AWS partner-funding maze.

---

This post is part of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.