kong插件poc
自定义Wordle MCP服务器的POC，通过Kong Gateway插件路由到客户端（例如Windsurf）。
这个项目可以在当地建造和运行。
建筑
关键部件：
- 香港门户：路由HTTP请求并提供API网关功能（身份验证、速率限制等）
- Kong MCP网桥插件 （Go）：将请求转发到MCP HTTP代理的简单HTTP代理
- MCP HTTP代理 （Go+MCP SDK）：实现流式HTTP传输（SSE），处理MCP协议
- MCP 服务器 （Go）：通过提供Wordle建议
get_wordle_suggestions工具
请求流
┌─────────────────┐
│ MCP Client │ (Windsurf, curl, etc.)
│ (Streamable │
│ HTTP/SSE) │
└────────┬────────┘
│ HTTP POST/GET (port 8000)
↓
┌─────────────────┐
│ Kong Gateway │ (API Gateway - routing, auth, rate limiting)
└────────┬────────┘
│ HTTP forward
↓
┌─────────────────┐
│ Kong MCP Bridge │ (Simple HTTP proxy plugin)
│ Plugin (Go) │
└────────┬────────┘
│ HTTP (port 9000, internal)
↓
┌─────────────────┐
│ MCP HTTP Proxy │ (MCP Go SDK - handles SSE, sessions, protocol)
│ (Go + SDK) │
└────────┬────────┘
│ stdio JSON-RPC
↓
┌─────────────────┐
│ MCP Server │ (Wordle tool implementation)
│ (Go) │
└─────────────────┘先决条件
- 确保Docker已安装并正在运行
- 安装 甲板 CLI版本1.43或更高版本
开始使用
快速开始
# Build and start Kong with the MCP plugin
make run-kong
# Test the integration
make test-kong步进
1.独立测试MCP服务器：
make test-mcp2.建设并运营香港：
make run-kong3.验证Kong是否正在运行：
curl http://localhost:8001/status4.测试MCP集成：
# Initialize MCP session
curl -X POST http://localhost:8000/mcp/wordle \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {},
"clientInfo": {"name": "test", "version": "1.0.0"}
}
}'
# Call the Wordle tool
curl -X POST http://localhost:8000/mcp/wordle \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_wordle_suggestions",
"arguments": {"guesses": ["slate", "crane"]}
}
}'预期响应（SSE格式）：
event: message
id: _0
data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"{\"suggestions\":[\"apple\"]}"}]}}5.运行测试脚本：
./test_streamable_http.sh项目结构
.
├── kong-plugin-mcp/ # Kong plugin (HTTP proxy)
│ ├── main.go # Plugin entry point
│ ├── config.go # Configuration schema
│ ├── http_proxy.go # HTTP forwarding handler
│ └── Makefile # Plugin build
├── mcp-http-proxy/ # MCP HTTP Proxy service
│ ├── main.go # Proxy using MCP Go SDK
│ └── go.mod # Go module with SDK dependency
├── mcp_server/ # MCP server
│ ├── main.go # Server entry point
│ ├── wordlemcpserver/ # Wordle tool implementation
│ └── test_request.sh # Standalone test
├── kong/
│ ├── Dockerfile # Kong image with all components
│ ├── kong.yml # Kong declarative config
│ └── start.sh # Startup script (runs proxy + Kong)
├── test_streamable_http.sh # Streamable HTTP tests
├── WINDSURF_SETUP.md # Windsurf integration guide
├── IMPLEMENTATION_SUMMARY.md # Technical details
└── Makefile # Main build automation参考
MCP 服务器
make build-mcp # Build MCP server binary
make test-mcp # Build and run standalone test
make clean-mcp # Remove built filesKong插件
make build-plugin # Build Go plugin (.so file)
make clean-plugin # Remove built files香港门户
make build-kong # Build Docker image with plugin and MCP server
make run-kong # Build and run Kong in background
make logs-kong # View Kong logs
make test-kong # Run integration tests
make stop-kong # Stop the container
make clean-kong # Remove Docker image全部
make all # Build everything
make clean # Clean everythingWindsurf集成
此Kong MCP代理可以与Windsurf和其他支持流式HTTP传输的MCP客户端一起使用。
增添 ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"wordle-kong-proxy": {
"disabled": false,
"headers": {},
"serverUrl": "http://localhost:8000/mcp/wordle"
}
}
}重新启动Windsurf后，您将可以访问 get_wordle_suggestions 工具。
更多信息
常见问题解答
为什么不将MCP HTTP代理和MCP服务器组合成一个组件呢？
关键原因是MCP SDK和Kong的插件模型之间存在不匹配，解决这些差异将导致严重的复杂性。其中一些挑战包括：
- 响应水平与长期运行：MCP SDK需要一个长时间运行的服务器进程来管理会话和SSE流，而Kong的插件模型遵循一个响应级模型，该模型期望同步请求/响应处理程序。
- 手动会话管理Kong运行多个不共享内存的工作进程；实现MCP代理需要大量的会话管理逻辑，并引入对缓存（如Redis）的依赖来存储会话状态。单个MCP HTTP代理避免了复杂的跨工作器会话同步或对Redis等外部会话存储的需求。
- SSE流媒体支持：Kong的插件开发工具包（PDK）不支持服务器发送事件流；分离允许代理处理SSE，而Kong只是转发流。
将MCP HTTP代理与Kong分开的其他原因：
- 故障隔离：如果MCP协议代码崩溃或内存泄漏，只有代理进程失败，而Kong继续为其他路由提供服务；合并后的建筑将使整个香港工人破产。
- 独立缩放：MCP HTTP代理可以根据MCP流量模式独立扩展，而不会影响Kong的路由容量，反之亦然。
- 关注点分离：Kong处理它最擅长的事情（HTTP路由、身份验证、速率限制），而MCP HTTP代理只关注MCP协议的复杂性（会话、SSE、JSON-RPC）。
- 可重用性：MCP HTTP代理可以由其他客户端或服务独立使用，无需Kong，使其成为跨不同部署场景的可重用组件。
- 简化测试：每个组件都可以单独测试——Kong插件测试HTTP转发，MCP代理测试协议合规性——而无需复杂的集成测试设置。
- 独立更新：MCP协议更改只需要更新代理；香港的安全补丁或配置更改不会影响MCP的功能。
- 行业最佳实践：这遵循了Istio和Dapr等生产系统使用的sidecar模式，其中专门的sidecar与主要服务一起处理特定于协议的问题。
为什么要使用Kong插件？Kong可以简单地将请求转发给MCP HTTP代理吗？
对于这个简单的例子，插件是不必要的——它只是执行HTTP转发。Kong可以使用此配置在本地实现等效功能：
# kong.yml - No plugin needed
services:
- name: mcp_wordle_service
url: http://localhost:9000 # MCP HTTP Proxy
routes:
- name: mcp_wordle_route
paths:
- /mcp/wordle
methods:
- GET
- POST
- DELETE
strip_path: false然而，这个项目的关键目标之一是创建一个自定义Kong插件，因为我需要额外的灵活性来进行未来的开发。