CogniDocs provides 4 tools for documentation search with reasonable structure, but exhibits moderate quality gaps. All tools have descriptions and visible input schemas in the source, but descriptions are brief and lack actionable guidance. Parameter descriptions exist but are minimal. No output schemas are documented. Tool naming follows verb-noun convention (list, search, get, agentic_search), which is good. However, the tool set lacks error recovery guidance, and descriptions don't address when to use one tool vs. another. The agentic_search tool is interesting (extractive QA without external LLM), but the distinction from search_documentation is not clearly explained. No tool annotations (readOnlyHint, etc.) are present despite all being read-only operations.

• Expand tool descriptions to 100-200 characters. Include: (1) what the tool does, (2) when to use it (vs other similar tools), (3) any prerequisites. Example: 'search_documentation: Retrieve relevant passages from a documentation set using semantic search. Use this when you need context from multiple sources. Returns up to 10 passages with relevance scores. Requires a valid documentation set ID from list_documentation_sets().'
• Document output schemas for all tools. Specify what fields are returned (e.g., setId, name, description for list_documentation_sets; passages, scores, metadata for search_documentation). Include example structures in comments or a separate schema block.
• Add tool annotations: Set readOnlyHint=true for all 4 tools since they perform no mutations. This signals safety to clients and simplifies agent planning.
• Clarify agentic_search purpose. Rename to 'extract_qa_from_documentation' or add explicit description: 'Same as search_documentation, but also extracts a synthesized answer from top results using built-in QA extraction (no external LLM required). Use when you want a single concise answer instead of raw passages.'
• Enhance parameter descriptions with format and discovery hints. Example: 'setId (string): The unique identifier of a documentation set. Get valid IDs by calling list_documentation_sets(). Format: UUID or alphanumeric slug.'
• Add error handling examples in code comments. Document common failure modes: invalid setId (suggest list_documentation_sets), empty query, limit out of bounds. Return specific error messages with recovery guidance, not generic 500 errors.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry