Lightweight, domain-agnostic embedded search engine exposed via MCP, optimized for serving SDK documentation to AI coding agents
docs-mcp exposes 2 well-named, read-only documentation tools with clear descriptions and properly typed input schemas. Both tools follow verb_noun naming (search_docs, get_doc) and include descriptions sufficient for LLM tool selection. However, critical gaps prevent a higher score: (1) No documented output schemas visible in source, LLMs cannot infer the structure of search results or doc chunk responses, forcing them to guess downstream field names; (2) Parameter descriptions are minimal (e.g., 'query' lacks format guidance or examples of semantic vs lexical use); (3) No pagination parameters despite being a search tool likely to return many results; (4) Error handling not visible in source, no recovery guidance for failed searches or missing docs; (5) No input validation or constraint documentation (e.g., max query length, character restrictions). The tools are READ_ONLY and well-scoped but lack the production-grade details that prevent LLM mistakes.
Retrieve a specific documentation chunk by its unique identifier. Use this when you need the full content of a specific documentation section.
Search documentation using hybrid (lexical + semantic) search. Returns the most relevant documentation chunks ranked by relevance. Use semantic search for meaning-based queries and lexical search as a fallback.
No documented output schemas for either tool. LLMs cannot infer the structure of search results (fields, data types, whether results are ranked, pagination info) or doc chunk responses (content format, metadata fields, chunk boundaries). This forces LLMs to make assumptions and risks incorrect downstream processing.
search_docs lacks pagination/limiting parameters despite being a search tool. If the index contains hundreds of documentation chunks matching a query, returning all results will blow the context window. Tool should accept limit (1 - 100) and offset/cursor parameters, and return a total_count or next_cursor in response.
Parameter descriptions are minimal and lack actionable constraints. 'query' for search_docs has no guidance on format, length limits, or when to use semantic vs lexical search (the tool description mentions both strategies but the parameter doesn't explain how to trigger them). 'id' for get_doc lacks examples of valid ID formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
No visible error handling or recovery guidance. What happens if a search returns zero results? If get_doc receives an invalid ID? If the documentation index is corrupted or unavailable? Source does not show error responses or recovery hints, leaving LLMs unable to self-correct.
search_docs description mentions 'hybrid (lexical + semantic) search' and advises 'Use semantic search for meaning-based queries and lexical search as a fallback,' but the input schema has no parameter to select the search strategy. LLMs cannot control which algorithm is used, this design mismatch will lead to mismatches between user intent and actual search behavior.
No input validation constraints visible. Are there limits on query length? Character restrictions? Disallowed keywords? If users or agents pass extremely long queries or malformed input, source code does not show how errors are handled or what feedback is returned.