Safe AI access to business data (MCP servers)

Problem

Staff wanted to ask AI assistants plain-language questions of the systems the business ran on: a billing and support platform, a cloud data warehouse, a long history of customer-support conversations, and a library of client profiles used for content review. Handing an assistant broad credentials, or free rein to write SQL, risks changed or deleted data, runaway query cost, results that flood the model's context, and answers about the wrong customer.

Goal

Model Context Protocol servers that give AI assistants useful, compact and safe access: read-only by construction wherever possible, cost-capped, attributable to a person, gentle on production systems, and designed to refuse rather than guess.

My role

Designed and built the billing gateway, the warehouse server and the client-aware content-review bridge alone. For the support-conversation archive, owned the project: chose the architecture and wrote the product requirements, directed an autonomous coding agent through the build while reusing patterns from an earlier MCP server, then reviewed, tested, deployed and ran it.

Solution

There are four MCP servers, built on shared principles.

A read-only billing and support gateway: stateless, throttled and cached, with composite tools that answer common questions in one call and no write path at all.

A read-only data-warehouse server: three tools (list tables, describe a table, run a query) behind layered guardrails, with each person connecting under their own cloud identity.

A support-conversation archive and search server: an ingestion pipeline that keeps a full copy of support history current, plus search, statistics and LLM question-answering tools, including map-reduce analysis across hundreds of threads.

A client-aware content-review bridge: tools for hosted review agents that fetch the right client's verified facts, reference logo, shared documents and post history, resolving the client by exact match only.

How it works

Billing and support gateway.

Every request builds a fresh server and transport, so no session state is held and the service scales horizontally.

The API client throttles calls, retries server and network errors with capped exponential backoff and jitter, and caches only slow-changing reference data.

Tools come in two kinds: many thin read-only lookups that return compact text tables, and composite tools (a one-call customer summary and a daily digest of what needs attention) that replace many round trips. Only read actions are wrapped, so no write path exists.

Warehouse server.

The assistant launches the server locally. It authenticates with the person's own cloud credentials or a short-lived token, so every query runs, and is audited, as that person under read-only permissions.

Table names are sanitised, and a statement guard allows only read queries and rejects any write or schema-change keyword.

The warehouse itself enforces a hard ceiling on the data scanned per query, so an expensive query is refused before it costs money.

Results are capped at a fixed number of rows with a clear truncation note, and tool descriptions steer the model toward reporting views aggregated in advance to keep both scan cost and token use low.

Support-conversation archive.

A full initial load pages through every conversation with cursor pagination, a token-bucket limiter and retries with backoff, flattening each thread into searchable text plus metadata.

An hourly job syncs changes since a stored watermark, and signed real-time webhooks update single conversations as they change.

The server holds the archive in an in-memory cache and exposes keyword search with snippets, relevance-ranked search, fetch, filtered listing, aggregate statistics and summaries.

A co-occurrence scorer rewards capped keyword frequency, adjacent-phrase matches, several keywords appearing together and title matches, so results favour conversations about the whole question rather than one word of it.

A quick tool answers from the top matches with a fast model. A deep-analysis tool summarises up to hundreds of matching conversations in batches with a stronger model, then combines the batch summaries (map-reduce). A failed batch is noted in the answer rather than stopping it.

Client-aware content-review bridge.

A reviewer gives a hosted agent a draft and names the client; the agent calls the bridge.

The bridge resolves the client by exact name, slug or alias only. A near match returns candidates to confirm, and an unknown name returns an explicit refusal.

The profile comes back with every fact tagged by how well it is established, and the agent's instructions say how to treat each tag.

For image posts the agent fetches the known-good logo on demand. It reads a windowed post history (recent posts in full, older ones as a compact index) and appends confirmed posts with deduplication and an audit journal.

Shared documents are read through keyless, domain-delegated access. The bridge runs behind API-key middleware on a serverless platform, and scripts compare the live agents' configuration against versioned masters to catch drift.

Technical challenges

Keeping tool output small enough for a model's context: compact tables, composite tools that replace many round trips, views aggregated in advance, and row caps with truncation notes.

Protecting production APIs from AI-driven bursts: throttling, backoff with jitter, selective caching and token buckets during the initial load.

Defence in depth for AI-written SQL: a read-only identity, a statement guard and a warehouse-enforced cost ceiling, so no single layer has to be perfect.

Least privilege by construction rather than by policy: no write tools exist in the read-only servers.

MCP over HTTP with no session state, for horizontal scaling.

Answering questions over far more text than fits in one context (batching and map-reduce) while tolerating a failed batch, and choosing keyword relevance over a vector index because it is simpler to run and good enough at this scale.

Preventing wrong-client output: near matches surface candidates instead of picking one, and tool failures reach the model as explicit refusals.

Per-person accountability without a shared service account.

Capabilities

Plain-language billing and support queries
One-call customer summaries and a daily attention digest
Schema discovery and guarded ad-hoc SQL with per-query cost ceilings
A full support archive with an initial load, incremental sync and real-time updates
Relevance search, statistics, question answering and deep batch analysis
Client profiles with facts tagged by certainty, and refuse-don't-guess client resolution
On-demand logo checks and post-history deduplication
Per-user warehouse access
Configuration drift detection

Technology

Impact

Non-technical staff could get answers from billing, support, warehouse and client-profile data through their own AI assistant, with writes impossible wherever they were not needed, query cost bounded, every warehouse query attributable to a person, and content reviews that refuse rather than guess. No metrics are claimed.

Skills demonstrated

MCP server design and AI tool ergonomics
Design of resilient API clients
AI safety guardrails and SQL governance
Security by design and least privilege
Data ingestion under rate limits, with incremental sync
Retrieval, relevance scoring and map-reduce LLM synthesis
Handling provenance and uncertainty for LLMs
Prompt-injection hardening
Serverless deployment and keyless authentication
Directing autonomous coding agents from a written specification