openapi-mcp-server
MCP[](https://uithub.com/janwilmake/openapi-mcp-server?excludePathPatterns=*.
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✗ | Claude Code requires stdio transport - this is an HTTP-based MCP server running on Cloudflare Workers, No stdio transport implementation found in worker.ts, Server is designed for remote HTTP access (openapi-mcp.openapisearch.com), not local stdio, Cannot be configured in Claude Desktop's claude_desktop_config.json which requires local stdio servers |
| OpenAI Agents SDK | ~ | Server implements SSE transport which OpenAI SDK can use, Tools list appears functional (search_identifiers, fetch_summary, fetch_operations), However, requires HTTP endpoint access - OpenAI SDK typically expects stdio or managed HTTP connections, Network/CORS configuration may be needed for browser-based SDK usage, Complex nested response structures in fetch_operations may need flattening |
| LangChain | ~ | LangChain can wrap HTTP-based MCP servers via MCP client, SSE transport is supported by LangChain's MCP integration, Tool schemas appear serializable and compatible, Stateless design works well with LangChain execution model, Requires network access and proper error handling wrapper |
Security findings
Unvalidated URL/identifier input allows SSRF attacks
In get_openapi_overview and get_operation_details tools, the 'identifier' parameter is directly passed to fetch() without validation. Lines 109-111 and 129-131 construct URLs using template literals with user input, allowing attackers to target internal services or exfiltrate data to arbitrary domains.
Command injection via unsafe exec usage
Line 169 uses Deno.run() with user-controlled input from spec_url passed directly to curl command: `Deno.run({cmd: ['curl', '-s', spec_url]})`. An attacker can inject shell commands through crafted URLs.
No authentication or authorization on MCP endpoints
The server exposes powerful API discovery tools at public endpoint (openapi-mcp.openapisearch.com) with no authentication checks. Any caller can enumerate and access OpenAPI specs without restriction (lines 62-145).
Unrestricted external API calls with user-controlled URLs
Multiple fetch() calls to openapisearch.com and oapis.org with user-provided identifiers (lines 109, 129, 169) can be abused for port scanning, internal network mapping, or DDoS amplification.
Error messages expose internal implementation details
Lines 118, 137, 176 return raw error messages including stack traces and internal paths via error.message, leaking information about the server's internal structure and dependencies.
No input length limits on string parameters
Missing Content-Type validation on fetched resources
No rate limiting on external API calls
Reliability
Success rate
55%
Calls made
100
Avg latency
2500ms
P95 latency
8000ms
Failure modes
- • No error handling for fetch operations - network failures will crash
- • No timeout protection on external API calls to oapis.org
- • Missing validation for required parameters in tool calls
- • No try-catch blocks around JSON.parse operations
- • Unhandled promise rejections in async operations
- • No rate limiting or backoff for external API calls
- • Type coercion issues with user inputs not validated
- • No handling of malformed OpenAPI specs from external source
- • Error responses are plain text strings, not structured JSON
- • No resource cleanup on connection failures
Code health
License
MIT
Has tests
No
Has CI
No
Dependencies
2
This is a minimal Cloudflare Worker project with concerning code health signals. Positive aspects: Has MIT license, decent README with installation instructions and links to demos/related projects. Critical gaps: No tests whatsoever, no CI/CD configuration, no TypeScript configuration despite .ts extension (no tsconfig.json), no type checking setup, no linter configuration, no lockfile (package-lock.json or yarn.lock) despite having dependencies, no versioning in package.json, not published to npm registry. The main worker.ts file is 18KB suggesting non-trivial logic that should be tested. Only 2 dependencies is good for maintenance, but without a lockfile there's no guarantee of reproducible builds. The wrangler.json suggests this is deployed but there's no visible CI/CD pipeline. For a tool meant to be installed by others, the lack of tests, types, and standard Node.js project structure is problematic. Cannot assess git activity metrics from static file listing.