Docusaurus plugin that exposes your docs and OpenAPI specs as an MCP server, so AI agents can search the docs and inspect API endpoints.
Strong foundation with clear verb-noun naming (search_docs, read_doc, list_*, get_endpoint) and comprehensive parameter schemas using Zod. All 6 tools have descriptions (avg ~150 chars) and input schemas with type constraints. Tool annotations (readOnlyHint) present. Key gaps: output schemas not formally documented in code; error handling lacks recovery guidance; some parameter descriptions could be more prescriptive about formats/constraints.
Full detail of one API operation or webhook: parameters, request body, and responses with $refs resolved. Identify by operationId, or path (+ optional method). Pass spec to disambiguate when it exists in multiple specs.
List the indexed OpenAPI specs with title, version, server URLs, and operation/webhook counts.
List the documentation categories with a page count for each.
Return the full markdown of a documentation page. Accepts the URL from search_docs (or a source path).
Search API endpoints and webhook events across the OpenAPI specs by path, operationId, summary, or tag. Use get_endpoint for full detail of a match.
Full-text search across the documentation. Returns ranked matches with a URL, title, category, and snippet. Use read_doc with a returned URL to get the full page.
Output schemas not formally documented. Tools return structured content via result() helper, but LLMs cannot see the exact field names/types of returned objects (e.g., search_docs returns 'hits' array, but structure is inferred from implementation, not declared).
Error handling lacks recovery guidance. read_doc returns {found: false, suggestions: []} on miss, but description does not tell LLM to call search_docs first or how to interpret suggestions. get_endpoint returns {error, suggestions} but no actionable next step.
Parameter descriptions lack format/constraint details. 'url' in read_doc says 'Page URL or path from search_docs' but does not specify format (relative vs absolute, with/without .md extension). 'query' in search_api lacks guidance on syntax (AND/OR operators, wildcards).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Pagination not explicitly documented. search_docs and search_api accept 'limit' but no 'offset' or 'cursor' parameter. If results exceed limit, LLM cannot fetch next page. Description should clarify whether results are ranked/sorted and how to iterate.
get_endpoint parameter validation unclear. 'operationId' and 'path' are both optional but at least one is required. Description says 'Required if operationId is omitted' for path, but no validation error message shown if both are missing or both provided.