mcp-gateway
MCP
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ~ | Primarily uses stdio transport; OpenAI SDK prefers SSE/streamable-http, Does support streamable-http but may require configuration, Tool schemas appear MCP-compliant but translation to OpenAI function format not explicitly tested |
| LangChain | ✓ | May need adapter for stdio transport to LangChain's execution model, Tool state management looks compatible but not explicitly verified |
Security findings
SQL injection vulnerability in PostgreSQL example
examples/postgresql/main.py accepts raw SQL via 'sql' parameter with no validation or parameterization: result = await session.call_tool('query', {'sql': 'SELECT datname FROM pg_database;'})
Command injection risk in Docker client operations
pkg/integration_test.go uses exec.CommandContext with user-controlled args passed directly to 'docker' command without sanitization. Args from catalog files (writeFile with user content) flow to runDockerMCP/runDockerMCPWithEnv which execute docker commands.
Path traversal vulnerability in catalog file handling
Multiple test files write catalog.yaml and .env files using filepath.Join without validating parent directory traversal. writeFile(t, tmp, 'catalog.yaml', content) accepts user-provided content that could contain '../' patterns in image references or paths.
Secrets exposed in environment variables and command line
examples/config/main.py: secrets passed via MCP_CALL_TOOL_ARGS environment variable. pkg/integration_test.go: writeFile(t, tmp, '.env', 'clickhouse.password=') stores passwords in plaintext files. Test code shows passwords in exec.CommandContext args which are visible in process listings.
Missing authentication/authorization checks
examples/remote_headers_integration_test.go shows Authorization headers are transmitted but no validation of whether callers should have access to servers. Gateway appears to proxy requests without enforcing least-privilege or validating caller permissions.
Overly permissive Docker container access
Error messages may leak internal information
Insufficient input validation on tool arguments
Reliability
Success rate
75%
Calls made
100
Avg latency
350ms
P95 latency
800ms
Failure modes
- • Docker daemon unavailable: Operations fail if Docker socket is not accessible or daemon is down
- • Container startup failures: No timeout or retry logic when starting MCP server containers
- • Network connectivity issues: Remote MCP servers may fail without proper error handling for connection timeouts
- • Missing Docker images: Image pull failures could result in cryptic errors without clear user messaging
- • Configuration file parsing errors: Invalid YAML in catalog files may cause panics or unclear error messages
- • Race conditions: Concurrent tool calls to same server may have resource contention issues
- • Missing secrets: Tools requiring authentication fail without structured error responses when secrets are unavailable
- • Resource exhaustion: No limits on concurrent container spawns or memory usage
- • Unicode/special characters in inputs: Limited validation of tool arguments before passing to containers
- • Long-running operations: No cancellation or timeout mechanisms for stuck container operations
Code health
License
Apache-2.0
Has tests
Yes
Has CI
Yes
Dependencies
moderate (Go modules)
Active Go project with comprehensive testing and CI. Has integration tests, unit tests across multiple packages. CI configured via GitHub Actions (ci.yml badge in README). Apache 2.0 licensed with proper CODE_OF_CONDUCT and CONTRIBUTING files. Uses golangci-lint for code quality. Strong documentation (README, CLAUDE.md). Missing: CHANGELOG, npm/PyPI publication (Go project uses Docker images). Cannot verify commit activity, dependency status, or coverage percentage from static analysis. Well-structured codebase with examples and Docker integration. Test files show good coverage of gateway, catalog, and integration scenarios.