The mcp-openapi-server defines 3 tools for OpenAPI endpoint discovery and invocation. Naming follows verb_noun patterns (list-, get-, invoke-), which is appropriate. However, critical gaps exist across descriptions, parameter documentation, and schema completeness. Tool descriptions are present but generic. Most critically, the invoke-api-endpoint tool has severely incomplete schema definition: its 'params' parameter is defined as type 'object' with empty properties {}, providing no guidance on what fields are valid or required. Parameter descriptions are minimal or missing. No output schemas are documented. Error handling and recovery guidance are absent. The tools lack the structured, LLM-optimized documentation needed for confident agent selection and execution.
Get the JSON schema for a specified API endpoint
Invoke an API endpoint with provided parameters
List all available API endpoints
invoke-api-endpoint has a critically underdocumented 'params' parameter. Schema defines it as type 'object' with properties: {}, providing zero guidance on valid fields. LLMs cannot infer what parameters to pass, risking silent failures or malformed API calls.
No output schemas are documented for any tool. Callers cannot know what fields to expect in responses, breaking downstream tool composition and forcing LLMs to guess field names.
Tool descriptions are generic and lack guidance on when to use each tool or what they return. 'List all available API endpoints' does not explain what structure is returned (array of strings? objects with metadata?) or when to call it before other tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
The 'endpoint' parameter in get-api-endpoint-schema and invoke-api-endpoint has a basic description ('Endpoint path to invoke') but lacks format constraints, examples in text, or guidance on expected format (is it '/users/{id}' or 'users' or 'POST /users'?).
No error handling or recovery guidance. What happens if invoke-api-endpoint fails? Should the agent retry? Call a different tool? The tool provides no actionable error messages.
The invoke-api-endpoint tool is a WRITE operation (documented as risk: WRITE) but has no confirmation or dry-run capability. Agents could inadvertently invoke destructive API endpoints without safeguards.
list-api-endpoints accepts no parameters and returns an unspecified result. Does it return 10 endpoints? 1000? Is there pagination? Without documented limits and pagination, large APIs risk context window exhaustion.