The nest-openapi MCP server exposes a single tool 'dynamic_openapi_tools' that is generated from OpenAPI specifications. However, critical quality issues prevent a higher score: (1) The tool description is vague and generic ('Dynamically generated tools from OpenAPI specification paths and operations'), providing no actionable guidance for LLM selection. (2) The input schema is described as 'dynamically generated' with no visible schema definition in the source code, only a JSON description object with no type constraints, properties, or required field list. (3) No evidence of parameter-level descriptions in the source. (4) The tool name 'dynamic_openapi_tools' (plural) suggests it returns multiple tools rather than executing a single operation, violating the single-responsibility principle. (5) No visible output schema documentation. The server's architecture dynamically generates tools from OpenAPI specs at runtime, which is conceptually sound, but the MCP tool wrapper itself lacks the definitional rigor required for production LLM agent interaction. Source: packages/mcp/src/openapi/tool-extractor.ts (mentioned but code not fully provided).

• Rewrite tool description to: 'Execute any operation defined in the loaded OpenAPI specification. Pass the operation ID (e.g., getUser, listPosts) and parameters as required by the spec. Returns the API response structured per the OpenAPI response schema.'
• Create an explicit static schema wrapper that documents: (1) required field for operation_id or operation_path, (2) optional field for parameters as an object, (3) type constraints and format hints.
• Add parameter descriptions: 'operation_id (string): The operationId from the OpenAPI spec (e.g., "getUserById")'; 'parameters (object): Key-value map of parameter names to values, matching the OpenAPI operation signature.'
• Document the output structure: 'Returns the API response body as per the OpenAPI response schema for the selected operation. May include fields like id, data, error, message depending on the operation.'
• Rename tool to a verb-noun pair: 'call_openapi_operation' or 'invoke_openapi_endpoint' to clarify it executes a single operation, not enumerates tools.
• Add error recovery guidance: 'If the operation fails, check: (1) operation_id matches the OpenAPI spec; (2) required parameters are provided; (3) parameter types match schema (e.g., numeric IDs vs strings); (4) API endpoint is reachable.'
• If the tool truly exposes all OpenAPI operations as individual MCP tools at runtime, document that in the server description instead. The 'dynamic_openapi_tools' wrapper should clarify whether it's a meta-tool for discovery or a pass-through executor.