Issue

The current FastMCP architecture relies on direct server mounting and HTTP calls for external services, leading to several critical challenges:

Lack of Domain Isolation: Direct server mounting forces co-location, violating security requirements such as PCI compliance for payment processing.
Transport Incompatibility: Inconsistent communication protocols between stdio-based domain servers and HTTP-accessible clients.
No Unified Protocol: Mixing MCP tools with direct HTTP API calls (e.g., vLLM integration) creates fragmentation in monitoring and middleware support.
Performance Bottlenecks: Single-instance domain servers lack load balancing, causing timeout spikes under high traffic.
Distributed Security Enforcement: Security logic is scattered across servers, complicating compliance and auditability.

Culprit

The core architectural issues include:

Tight Coupling: Direct server mounting (main_mcp.mount()) requires all domain servers to run in the same process or container, eliminating physical separation for security-critical components.
Protocol Fragmentation: vLLM services use HTTP, Stripe/AWS use direct SDK calls, and internal tools use MCP stdio, creating an inconsistent interface for monitoring and middleware.
Missing Transport Abstraction: No built-in way to expose stdio servers via HTTP, limiting integration with external clients.
Security Boundary Violations: Payment processing shares memory space with public-facing services, failing PCI DSS isolation requirements.
Load Balancing Limitations: No native support for round-robin routing, failover handling, or cross-cluster communication.

To address these challenges, the following proxy-based solutions were implemented:

A proxy layer was introduced to expose stdio servers via HTTP without modifying domain logic. This enables:

Accessibility for CLI tools and third-party integrations.
A unified architecture where external clients communicate with HTTP proxies, which then relay requests to stdio domain servers.

To achieve PCI compliance, a secure architecture was deployed:

Payment processing servers were isolated in a dedicated cluster with dedicated network access.
HTTP proxies were configured to forward requests to secure endpoints, ensuring no co-location with public-facing services.

A proxy wrapper was created to standardize communication with vLLM services, providing:

A unified MCP interface for inference tasks, including progress tracking and tool composition.
Compatibility with other MCP services for seamless integration.

A round-robin proxy was implemented to distribute traffic across multiple domain server instances:

A role-based access control (RBAC) proxy was introduced to enforce security policies:

Logs all tool access attempts with user roles, timestamps, and success/failure status.
Validates permissions before processing tool calls, reducing the risk of unauthorized access.

Use Case	Recommended Pattern	Priority
PCI-compliant payment processing	HTTP Proxy to isolated cluster	HIGH
CLI/partner API access	Transport Bridging Proxy	HIGH
vLLM integration	MCP Wrapper Proxy	MEDIUM
High-traffic domain servers	Load Balancing Proxy	MEDIUM
Multi-tenant RBAC	Security Gateway Proxy	LOW

Latency vs. Flexibility: Proxying introduces latency (~200-500ms per call), while direct mounting offers zero overhead. Mitigation includes using direct imports for high-performance needs.
Development Complexity: Additional server processes are required for proxies. Local testing is supported via FastMCP.dev_proxy().
Protocol Conversion: HTTP ↔ stdio bridging has serialization overhead, which can be optimized by batching small messages into single RPC calls.

These changes improved security compliance, scalability, and maintainability while introducing minimal performance overhead.