We Built a Customer-Facing MCP Server. Here's What the Spec Didn't Prepare Us For.

The first time we connected our MCP server to Claude Desktop, OAuth completed successfully — and then everything stalled.

Tool discovery never finished. No error. No logs pointing anywhere useful.

The root cause? A trailing slash mismatch between how we advertised our endpoint and how the client resolved it.

It took longer to diagnose than implementing the entire OAuth flow.

That was the moment we understood something important:

Shipping an MCP server in production is not the same thing as getting one working in the inspector.

At Bastion, we build compliance automation for startups — SOC 2, ISO 27001, and security workflows designed to handle sensitive data by default. When we decided to expose parts of our platform through an MCP server, we assumed tool design would be the hard part.

It wasn't.

The real complexity lives in everything the spec assumes you'll figure out yourself: authentication edge cases, identity provider incompatibilities, client divergence, multi-tenant authorization, and supply chain risk.

This is what we learned building a production-grade, customer-facing MCP server — not the abstraction, but the operational reality.

TL;DR

Quick Answer: The MCP specification gets the abstraction right. What it can't encode are production realities: IdP limitations, registration trust boundaries, client divergence, multi-tenant authorization, and supply chain exposure. If you're shipping an MCP server to customers — especially in security-sensitive domains — each of these deserves deliberate architecture, not incidental handling.

The OAuth Spec Reads Cleanly. Production Does Not.

The MCP authorization model builds on OAuth 2.1 with PKCE and Dynamic Client Registration (RFC 7591). On paper, it's elegant:

1. A client discovers your server
2. It registers dynamically
3. It authenticates the user
4. It calls tools

In practice, the elegance stops where your identity provider starts.

Dynamic Client Registration (DCR) assumes your authorization server supports runtime client onboarding.

Most don't.

AWS Cognito does not support DCR natively. Microsoft Entra ID typically doesn't either. If your IdP doesn't speak DCR, you're not just implementing a spec — you're adapting your infrastructure around it.

We evaluated three approaches:

1. Pre-register every client manually

This works internally. It collapses for public connectors.

2. Build a custom OAuth server

This gives you full control — and full operational burden.

3. Add a DCR translation layer in front of our IdP

This is what we shipped.

We exposed a standards-compliant /register endpoint and translated incoming RFC 7591 requests into our identity provider's native client creation APIs. From the MCP client's perspective, it's standard OAuth. Internally, we're bridging a gap most IdPs haven't closed yet.

But implementation complexity isn't the only issue.

DCR introduces a trust boundary.

If you expose /register publicly, anyone can claim to be "Claude Desktop" or "Cursor." The spec does not inherently validate that claim.

We mitigated that risk through:

• Strict redirect URI validation
• Metadata sanitization to prevent SSRF
• Rate limiting and anomaly detection
• Minimal default client permissions

More importantly, we designed with the ecosystem's evolution in mind.

The introduction of Client ID Metadata Documents (CIMD) shifts the trust model away from open registration and toward verifiable, domain-controlled identity. That's a stronger long-term direction.

If you're building today: support what clients require, but architect for where the trust model is heading.

Interoperability Is a Protocol Discipline, Not a Client Whitelist

One of the most underestimated challenges in MCP is client divergence.

The spec defines the protocol. It does not define how each client implements it.

We support multiple MCP clients. Each handles details slightly differently:

• Redirect URI normalization
• URL trailing slash handling
• HEAD probes before connection
• Redirect status code expectations
• Discovery parsing strictness

Spec compliance alone does not guarantee real-world compatibility.

The naive solution is: test against every client continuously.

That's necessary — but it's not the scalable answer.

The scalable answer is protocol discipline.

We shifted from "client testing" to conformance enforcement.

1. Automated Protocol Conformance Testing

We built a test harness that validates:

• Discovery document correctness
• OAuth + PKCE flows
• DCR semantics
• Redirect behavior
• Token exchange lifecycle
• Tool listing structure

These tests validate behavior against the specification — not against a specific client implementation.

If you fail conformance, you fix the protocol — not the client.

2. Treat URLs and HTTP Semantics as Security-Critical

Small inconsistencies cause large failures.

Trailing slashes. Redirect codes. Content types. Method support. JSON casing.

We enforce strict normalization and contract tests before every release. No endpoint ships without automated verification.

Interoperability isn't a QA task. It's a systems design discipline.

3. Version Explicitly and Preserve Backward Compatibility

Client ecosystems evolve independently.

We introduced:

• Explicit endpoint versioning
• Backward compatibility guarantees
• Controlled deprecation windows
• Strict schema stability

The goal is predictability.

Client testing becomes validation — not your only safety net.

Every Tool Is a Permission Boundary

The MCP spec defines tools as callable functions. It does not define authorization semantics at the tool level.

That distinction matters.

OAuth scopes are coarse-grained. MCP tools are precise operations that may:

• Retrieve compliance progress
• Access questionnaire data
• Trigger remediation workflows
• Surface repository metadata

Each operation touches different data and carries different risk.

In a multi-tenant SaaS environment handling compliance artifacts, authentication alone is insufficient.

Identity answers who.

Authorization must answer what and within which tenant.

We treat every MCP tool as an independently secured API surface.

Our model is defense-in-depth:

• Tenant context embedded directly in tokens
• Explicit tenant scoping required for tool execution
• Per-tool authorization checks
• Resource ownership validation independent of upstream filtering

No tool inherits trust implicitly from authentication.

Many demo implementations authenticate once and allow every tool to execute under that session. That's acceptable for prototypes.

In production systems handling sensitive security data, every tool must enforce its own boundary.

Design tool-level authorization deliberately. Don't let it emerge accidentally.

MCP Servers Sit Inside Your Trust Boundary

An MCP server often runs with the same privileges as the authenticated user. That places it squarely inside your security perimeter.

The ecosystem is still maturing.

In the past year alone, we've seen:

• Path traversal vulnerabilities affecting large numbers of MCP servers
• Prompt injection attacks enabling unintended data exfiltration
• Malicious packages deploying credential-harvesting connectors

The pattern is consistent: powerful integrations, limited hardening. The OWASP MCP security guide documents this across the ecosystem.

This extends to how you manage secrets in MCP configurations. Hardcoded credentials in MCP config files are already a documented attack vector — one that becomes significantly more dangerous when the server has access to compliance or production data.

We treat MCP dependencies like any other high-privilege component in our stack:

• Source review where feasible
• Vulnerability scanning
• Strict secret handling policies
• Runtime monitoring

When an MCP server can access compliance data, repositories, or production systems, a compromised dependency is not a nuisance.

It's an incident.

If you're connecting AI agents to sensitive systems, your supply chain review must match that reality.

The Spec Is a Foundation. Production Is an Architecture.

The MCP specification is well-designed. It gets the abstraction right.

What it cannot encode are production realities:

• Identity provider limitations
• Registration trust boundaries
• Client divergence
• Multi-tenant authorization
• Supply chain exposure

The first generation of MCP servers proved the concept.

The next generation will harden it.

If you're building an MCP server for internal experimentation, the bar is functionality.

If you're building one for customers — especially in regulated or security-sensitive domains — the bar is different:

• Enforce protocol conformance.
• Validate contracts automatically.
• Version deliberately.
• Treat every tool as a security boundary.
• Audit your supply chain.
• Design for failure containment.

The question is not whether your MCP server works.

The question is whether it fails safely.

At Bastion, when AI touches compliance infrastructure, that distinction is non-negotiable.

Ready to build security and compliance that keeps up with AI-driven workflows? Get started with Bastion.

Sources

• Model Context Protocol Specification — Official MCP specification and authorization model
• RFC 7591 – OAuth 2.0 Dynamic Client Registration Protocol — IETF standard for dynamic client registration
• OAuth 2.1 Draft Specification — The OAuth 2.1 specification with PKCE requirements
• MCP Authorization Specification — MCP-specific OAuth 2.1 authorization flow details