The RAG MCP Server defines 4 tools with basic structure but significant quality gaps. All tools have names, descriptions, and input schemas visible in the source. However, descriptions are generic and lack depth; parameter descriptions are minimal; output schemas are not documented; and error handling guidance is absent. The tools follow a reasonable verb_noun naming pattern (search_*, add_*) but descriptions do not explain WHEN to use each tool vs. similar ones, do not guide recovery on failure, and do not indicate whether tools modify state. The server is STDIO-only, which is a hard cap at 50 for protocol readiness. Averaging the per-tool scores yields a definition quality of ~52, placing this server in the D (Poor) range, typical of early-stage community tools.

• Document the output schema for each tool. Specify all fields, their types, and when they may be absent. E.g., search_knowledge_base should return an array of objects with fields like {document_id, title, content, score, metadata}.
• Rewrite tool descriptions to be LLM-optimized (50-200 chars): explain WHAT each does, WHEN to use it vs. similar tools, and any side effects. E.g., 'Search local vector DB for documents matching the query. Use this for internal knowledge; use web_search for current events. Returns ranked documents with scores.'
• Add constraints to numeric parameters: top_k (1-100, default 10), max_results (1-50, default 20). For local_weight and web_weight, document whether they must sum to 1.0 or are normalized independently.
• Add parameter descriptions for filters (search_knowledge_base) and metadata (add_document). Specify structure, allowed keys, and validation rules. E.g., 'Optional dict of metadata filters, e.g. {"source": "pdf", "date_range": "2024"}'.
• Add error handling guidance to each tool description. E.g., 'If no results found: try broadening the query or lowering the similarity threshold. If Tavily times out: retry with fewer max_results.'
• Declare idempotence and state mutation. E.g., 'add_document modifies state and is NOT idempotent, calling twice with the same content will create two copies. Use an upsert variant if available or check for duplicates first.'
• Document pagination if tools support it. E.g., if results can be large, add offset/limit or cursor parameters and document total count or next_cursor in output.

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

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