MCP server becomes the firewall between PMS and AI vendors

The DSO wanted to build several AI agents on top of one practice-management system — a voice agent per location, a recall outreach agent, an insurance-verification agent — without each agent re-implementing API integration, auth, and audit.

What we built

• Remote MCP server with Streamable HTTP transport (per November 2025 spec), deployed in the client’s AWS account.
• OAuth 2.1 + PKCE for every tool invocation — no static API keys anywhere.
• Per-location tenant isolation enforced on every tool call — even though the underlying PMS is multi-tenant. The server re-verifies tenant context on every request to avoid the “confused deputy” pattern.
• Scoped tool surface: read-only for clinical, scoped-write for scheduling and recall outreach, no-access for billing.
• Audit log per tool call (caller identity, tenant context, parameters, result, latency) written to S3 with KMS encryption and a 7-year retention policy.
• Tool-injection defense: alert on any change to tool descriptions or response shapes after install.

Caveat

Production MCP is still ahead of the spec on some dimensions. Audit-trail standards are not in the November 2025 spec — we built our own. Multi-tenancy enforcement is not in the spec — we enforced it at the server layer. We pin to a spec version per client and document the gaps; clients who want “future-proof” instead get “current-spec + defensible upgrade path.”

The DSO’s IT director described the MCP server as “the firewall between our PMS and any AI vendor we work with going forward.”

Stack. Streamable HTTP transport · OAuth 2.1 + PKCE · AWS API Gateway + Lambda · CloudWatch + Langfuse for audit · scoped tool surface.

Three downstream agents (voice receptionist, recall outreach, insurance verification) now consume the same MCP surface — ~$22K saved on each subsequent agent build. Zero auth or tenant-isolation incidents in 6 months.