That is the difference between a spec a model can answer questions from and one it has to chase through by hand. What it generates is built to be used rather than read: the cURL command arrives with a sample body, auth headers and parameters in place, and the TypeScript generation works from either a named component schema or an endpoint's request and response pair. One ordering rule governs the whole surface — load_spec first, and every other tool operates on whatever it loaded.
An OpenAPI specification client: one spec loaded from a URL or a file, then browsed, queried, validated against, and turned into code.
- load_spec from a URL or a local filePath, which has to run before anything else.
- list_endpoints filtered by method, tag and deprecation, and search_endpoints by keyword across path, summary, description and operationId.
- get_endpoint_details with the endpoint's parameters, request body, responses and security.
- Schemas resolved rather than referenced: get_request_schema returns the fully dereferenced request body, and get_response_schema returns the schema for a given status code.
- validate_payload, which checks a JSON payload against an endpoint's request schema, and generate_sample, which builds one from that schema with optional fields included or left out.
- get_auth_schemes for the authentication schemes and their per-endpoint requirements, and get_servers for the servers and their variables.
- generate_typescript_types from a named component schema or from an endpoint's request and response, and generate_curl, which produces a command with a sample body, auth headers and path and query parameters already filled in.
An OpenAPI specification reachable by URL or by local path, loaded through load_spec before any other tool will answer. Nothing else — no account, no key.
One command — npx --yes @blackkspydo/openapi-mcp