Contents

  1. Background — MCP enters the production phase in spring 2026
  2. Challenge 1: SSO-Integrated Auth — Connecting to the organizational identity layer
  3. Challenge 2: Gateway Design — The authorization propagation problem
  4. Challenge 3: Audit Logging and Compliance
  5. Challenge 4: Configuration Portability
  6. KanseiLink data: Where Japanese SaaS stands today
  7. The roadmap's approach: The extension strategy
  8. Implications for Japanese SaaS vendors
Sources and Disclosure

This report is based on the official Model Context Protocol roadmap blog (published April 2026), The New Stack analysis, WorkOS commentary, and KanseiLink MCP server operational data as of April 16, 2026. Roadmap implementation timelines are subject to change.

Background — MCP Enters the Production Phase in Spring 2026

Model Context Protocol (MCP), open-sourced by Anthropic in late 2024, has grown to over 5,800 servers as of April 2026. But the industry's attention has clearly shifted — from "how many servers exist" to "how do enterprises run this reliably in production."

On April 8, 2026, the official MCP roadmap was updated and for the first time publicly named the real enterprise deployment challenges. The same day, Clare Liguori (AWS Senior Principal Engineer) joined the Core Maintainer group and Den Delimarsky joined as Lead Maintainer. AWS's deep commitment signals that MCP's enterprise trajectory is being shaped by those who build at scale.

The roadmap defines four primary enterprise blockers. Each maps precisely to what KanseiLink observes in Japanese SaaS production data.

5,800+
MCP servers
(April 2026)
Source: MCP official roadmap
4
Enterprise deployment
blockers named
Source: MCP official roadmap
90%
freee MCP
success rate (212 calls)
Source: KanseiLink production
91%
Slack MCP
success rate (113 calls)
Source: KanseiLink production

Challenge 1: SSO-Integrated Auth — Connecting to the Organizational Identity Layer

The first wall enterprises hit when deploying MCP at scale is integrating with existing identity infrastructure. Current MCP servers each manage their own credentials and authentication flows independently. That's fine for a proof-of-concept, but when multiple teams across a company share the same pool of MCP servers, administration complexity explodes.

The roadmap's target model: route access through an organization's existing SSO layer (Okta, Microsoft Entra, Google Workspace Identity, etc.) as the access broker. The flow becomes: SSO login → scoped token issued → MCP connection established — with IT retaining full visibility and control.

Impact on Japanese SaaS

Of the 225 Japanese SaaS services tracked by KanseiLink, approximately 60% support OAuth 2.0 or better. However, full SSO integration (SAML/OIDC) is limited to top-tier services — most mid-market Japanese SaaS still relies on per-service API keys. If SSO integration becomes a standard MCP requirement, non-compliant services risk exclusion from enterprise shortlists.

KanseiLink's production data shows freee MCP logging 4 auth_expired errors out of 212 calls — all caused by OAuth 2.0's 24-hour token lifetime. In long-running overnight batch workflows, tokens silently expire mid-operation. SSO-brokered scoped token issuance would structurally eliminate this entire class of failure.

Challenge 2: Gateway Design — The Authorization Propagation Problem

Enterprise MCP deployments almost never look like a direct agent-to-server connection. In practice, API gateways, security proxies, and load balancers sit in between. This gateway and proxy pattern is the area where the current MCP spec is most silent.

The Undefined Core Problem

When a request passes through a gateway, how does the downstream MCP server verify what the original client was authorized to do? The current spec does not answer this. This is the single biggest source of architectural uncertainty in enterprise MCP deployments today.

Without a defined mechanism for authorization propagation through gateways, deployments face a binary failure: either requests are processed with excessive permissions, or all requests get blocked. Neither is acceptable for production.

The leading proposed solution is a standard protocol for gateways to propagate the original client's authorization scope to downstream servers in a verifiable form. A JWT claims-based approach is being discussed, but the spec work is ongoing.

Gateway Issue 1

Authorization Propagation

No standard method for a gateway to pass a client's authorization scope to downstream servers in a verifiable way

Spec in progress
Gateway Issue 2

Configuration Portability

Gateway behavior definitions (rate limits, routing, failover) cannot be reliably moved between environments

Spec in progress
Gateway Issue 3

Audit Log Consistency

Log formats between gateways and MCP servers diverge, fragmenting the audit trail

Under discussion
Gateway Issue 4

Failover Behavior

No standard spec for how agents should behave when a gateway goes down

Under discussion

Challenge 3: Audit Logging and Compliance

The moment enterprises start connecting AI agents to internal systems, legal, compliance, and security teams ask the same question: "What did the agent do, when, and to whom — and can we prove it?"

For Japanese enterprises, the stakes vary by sector: Financial Services Agency (FSA) guidelines for financial firms, APPI (Act on Protection of Personal Information) for any service handling personal data, ISO 27001 for manufacturers. If an agent's action history cannot be recorded in a form that satisfies these audit requirements, production approval is realistically unobtainable.

The current MCP spec defines no standard format for audit logs. Each MCP server emits logs in its own format, making it structurally difficult to assemble a coherent audit trail across multi-server agent workflows.

Current Practical Workaround

The pragmatic answer before standardization arrives is OpenTelemetry (OTel) tracing. MCP servers emit OTel spans, which are aggregated by a central observability platform (Datadog, Grafana, AWS CloudWatch, etc.). Anthropic's enterprise Claude Cowork includes native OpenTelemetry integration — a signal that OTel-based audit logging is the near-term industry direction.

Challenge 4: Configuration Portability

Enterprise development requires strict environment separation: Development → Staging → Production. Current MCP configurations — server URLs, credentials, scope settings — tend to get hardcoded per environment or managed through custom tooling, resulting in low portability across environments.

No standard integration pattern exists for IaC tools (Terraform, Pulumi) or secrets management systems (Vault, AWS Secrets Manager), which means DevOps teams building MCP into CI/CD pipelines must roll their own implementations.

The roadmap explicitly recognizes "configuration portability" and plans to address it through guidance and best practices before any spec changes — an appropriately scoped starting point given the diversity of enterprise tooling.

KanseiLink Data: Where Japanese SaaS Stands Today

KanseiLink's AEO data for Japanese SaaS confirms that all four roadmap challenges are already manifesting in production:

Data Point: freee MCP (KanseiLink production)

freee MCP (AA grade, 90% success rate) recorded 21 errors across 212 calls. 4 of those (19%) were auth_expired. The only verified workaround is manual OAuth token refresh every 24 hours. The root fix requires SSO-brokered token management — the exact capability the MCP roadmap is working toward.

The Roadmap's Approach: The Extension Strategy

The most architecturally significant aspect of the roadmap is its decision to implement enterprise capabilities as extensions rather than core spec changes.

This preserves the core protocol as a "lightweight protocol for everyone" while letting enterprises opt into SSO, audit, and gateway capabilities as needed:

Combined with MCP's donation to the Linux Foundation under the AAIF (Agentic AI Foundation), this signals MCP maturing into a vendor-neutral standard — not Anthropic's proprietary protocol.

Implications for Japanese SaaS Vendors

With the MCP enterprise roadmap now clearly defined, the action items for Japanese SaaS vendors are correspondingly clear.

Short-term (Q2–Q3 2026): Top priorities

  1. Migrate to OAuth 2.1: Prepare for the deprecation of the implicit flow and mandatory PKCE (already reflected in KanseiLink AEO scoring)
  2. Implement OpenTelemetry logging: Don't wait for the standard audit log format — instrument with OTel spans now as the pragmatic interim solution
  3. Test with enterprise identity providers: Verify SSO behavior against Okta, Microsoft Entra, and Google Workspace before customers ask

Medium-term (Q4 2026 and beyond): Building competitive advantage

Enterprise MCP readiness is on track to become a key SaaS selection criterion within 12–24 months. KanseiLink's AEO grading will progressively incorporate SSO integration, audit logging, and configuration portability as evaluation axes. Services that act early will gain both higher AEO scores and a defensible enterprise positioning advantage.

Check Your SaaS's Enterprise MCP Readiness

KanseiLink's AEO ratings give you a baseline for auth, audit, and gateway readiness today — and track your progress as the roadmap lands.

Contact us