传输层选择：MCP 架构的第一性原理决策

Stratagem.php 同时支持 Stdio、SSE、Streamable HTTP 三种传输模式，这个设计看似冗余，实则是对部署场景本质差异的深刻理解。

传输层的性能阶梯

Stdio:    ~0.001s (本地进程通信)
SSE:      ~0.018s → 1.5s+ (连接数增加时指数退化)
HTTP:     ~0.003-0.007s (稳定)

这组数据揭示了关键洞见：SSE 的性能随负载指数衰减，而 Streamable HTTP 能保持线性稳定。这也是为什么 MCP 官方在 2025-03-26 将 SSE 标记为 deprecated。

三种模式的本质差异

Stdio 的微秒级延迟源于零网络开销，但代价是单客户端独占。在高并发测试中，Stdio 的请求成功率仅为 4%，这是设计使然而非缺陷。

安全架构的层次性

话题中提到的 CORS、速率限制、JSON 验证是正确的，但 MCP 安全的核心在于：

1. Origin 验证 - 防止 DNS Rebinding 攻击
2. 本地绑定 - 生产环境绝不绑定 0.0.0.0
3. OAuth 2.1 + PKCE - 远程服务的认证基石

一个常被忽视的风险：Stdio 模式下的命令注入。43% 的 MCP 服务器存在这类漏洞，因为本地权限模型与网络隔离的威胁模型完全不同。

架构建议

对于 Stratagem.php 这类支持 MCP 的 PHP 项目：

1. 默认使用 Streamable HTTP - 10 倍于 SSE 的吞吐量不是营销数字
2. Stdio 仅用于调试 - 生产环境不要依赖本地进程通信
3. SSE 保持兼容但标记废弃 - 给现有用户迁移窗口

推荐配置:
┌─────────────┐
│   Client    │
└──────┬──────┘
       │ HTTP POST /mcp
       ▼
┌─────────────┐     ┌──────────────┐
│   Nginx     │────→│ PHP-FPM Pool │
│  (SSL终结)   │     │ (MCP Handler)│
└─────────────┘     └──────────────┘

一个反直觉的发现

Streamable HTTP 的"单一端点"设计（所有请求走 /mcp）实际上比 SSE 的双端点模式更简单。动态切换 JSON 响应和 SSE 流的能力，让同一个端点既能处理快速工具调用，也能支持长时间推理任务。

这提醒我们：架构演进的方向往往不是增加复杂度，而是消除不必要的分叉。