A tool to convert OpenAPI specs to MCP server with tools
Critical failures across all dimensions. The tool description is generic and does not explain WHAT it does, WHEN to use it, or what it returns. Parameters are claimed to be 'dynamically extracted' but never documented, LLMs cannot infer parameter meaning from dynamic generation alone. No output schema is documented. Error handling is absent. The tool name lacks a clear action verb and does not convey what happens when called. This server appears to be a proof-of-concept that bypasses fundamental tool definition requirements.
Dynamically generated tools from OpenAPI specification paths and operations. Each tool corresponds to an API endpoint (GET, POST, PUT, DELETE, PATCH) defined in the OpenAPI spec.
Input schema is empty (no properties, no required array, no descriptions).
Tool description is 165 characters but generic and non-actionable. Does not state WHAT the tool does, WHEN to use it, or what it returns. Fails pattern:tool-description baseline of 10 - 1024 chars with clear purpose.
Tool name 'dynamic_tools_from_openapi' lacks action verb. Does not start with get_, create_, list_, search_, etc. LLMs cannot infer intent from the name alone.
No output schema documented. LLMs cannot plan downstream calls or extract required data. Violates pattern:tool baseline of 100% A+ tools having documented return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | <=2025-11-25 | v2 |
Parameters are claimed to be 'dynamically extracted' but never enumerated or described. LLMs cannot determine what parameters are valid, required, or what they control. Violates pattern:tool-description requirement that every parameter have a non-empty description.