@cloudflare/mcp-server-cloudflare
MCPMonorepo for Cloudflare MCP servers
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ✓ | No SSE transport explicitly configured, relies on stdio which may require adapter |
| LangChain | ~ | Tools require Cloudflare API credentials (CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN) which must be managed in LangChain's execution context, Complex nested response types from Cloudflare API may need serialization adapters |
Security findings
API credentials exposed in .dev.vars.example files without encryption
Multiple apps contain .dev.vars.example files (ai-gateway, auditlogs, etc.) that suggest storing sensitive API keys (OPENAI_API_KEY, AI_GATEWAY_TOKEN, CLOUDFLARE_ACCOUNT_ID) in plain text .dev.vars files. While examples show 'TODO', the pattern encourages insecure credential storage in version control if users don't follow best practices.
No evidence of input validation framework in ai-gateway tools
File apps/ai-gateway/src/tools/ai-gateway.tools.ts (5578 bytes) implements tools but without visible input validation layer. No schema validation, length limits, or sanitization patterns evident in the codebase structure. This could allow command injection, path traversal, or SQL injection depending on how inputs are processed.
Potential for credential leakage through test environment configuration
File apps/sandbox-container/types.d.ts exposes OPENAI_API_KEY: 'TODO', AI_GATEWAY_TOKEN, CLOUDFLARE_ACCOUNT_ID in test environment interface. This pattern risks accidentally committing real credentials in test configurations.
Missing authorization checks in MCP server architecture
No visible authorization or authentication layer in the repository structure. The ai-gateway.app.ts (4172 bytes) and ai-gateway.context.ts (626 bytes) files don't show any permission checks or access control mechanisms. Any caller may have full access to all tools.
Worker configuration file size suggests complex security surface
File apps/ai-gateway/worker-configuration.d.ts is 235,129 bytes, indicating a very large configuration surface that likely includes sensitive settings and numerous potential misconfiguration risks.
No evidence of rate limiting or resource constraints
Multiple apps with isolated test environments but unclear security boundaries
Lack of input sanitization patterns for GraphQL and API endpoints
Reliability
Success rate
72%
Calls made
100
Avg latency
850ms
P95 latency
2500ms
Failure modes
- • Missing environment variables (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID) cause unhandled errors
- • Network failures to Cloudflare API have no retry logic or timeout protection
- • Invalid account IDs or malformed inputs may cause API errors without structured error responses
- • GraphQL query construction with special characters or very long inputs not validated
- • Concurrent requests may overwhelm underlying API without rate limiting or queue management
- • Empty or null parameter handling not explicitly covered in all code paths
- • API token validation happens at runtime rather than startup, delaying error discovery
Code health
License
Apache-2.0
Has tests
Yes
Has CI
No
Dependencies
~30-40 (estimated from monorepo structure)
Well-structured monorepo with strong code quality signals. TypeScript throughout with comprehensive type definitions. Testing infrastructure present (vitest with workspace config, test files across apps). Multiple CHANGELOG.md files indicate versioning discipline. ESLint, Prettier, and editor configs show attention to code quality. Has CONTRIBUTING.md. Changeset tooling for version management. Published to npm registry (@cloudflare scope). Missing: visible CI configuration (.github/workflows not shown), git history unavailable for maintenance metrics. Appears actively maintained based on recent version (1.0.0) and multiple apps. Score would be 9-10 with visible CI config and maintenance history.