Buddha MCP provides 6 tools for searching and fetching Buddhist and Sanskrit texts from CBETA, GRETIL, and other historical databases. Tools have clear action-verb names (search_, fetch, pipeline) and are READ_ONLY operations on a specialized knowledge domain. However, several definition quality issues reduce the score: (1) Parameter descriptions are present but many are generic/repetitive across similar tools without clear guidance on when to use each variant; (2) Output schemas are not explicitly documented in the source code provided, only input schemas visible; (3) Error handling and recovery guidance are not evident in the tool definitions; (4) The pipeline tools bundle multiple concerns (search + auto-fetch + context extraction) which violates single-responsibility; (5) Many optional parameters lack clear defaults or mutually-exclusive relationship documentation. The tools themselves are well-named and input parameters are typed, which prevents a lower score.

• Document output schemas for all tools. Include sample response structures showing what fields are returned by cbeta_title_search (e.g., 'results: [{id, title, score}]'), cbeta_fetch (e.g., 'text, metadata, highlights, page_info'), and pipeline tools (e.g., 'search_results, fetched_texts, context_snippets'). This enables LLMs to plan chaining and field extraction.
• Split pipeline tools into simpler components: keep cbeta_search and gretil_search as title search, use cbeta_fetch and gretil_fetch for both ID and regex query lookup, and move autofetch logic into a separate tool or make it a boolean flag on fetch with clear documentation of behavior when enabled.
• Add a 'Disambiguation' section to cbeta_fetch and gretil_fetch descriptions: explain when to use 'id' vs 'query', when 'part' applies vs 'start_char'/'end_char', when 'line_number' vs 'page', and whether multiple slicing modes can be combined. Example: 'If you have a text ID, use id. If you have search text, use query. Use part for structural divisions (juan), or start_char/end_char for character ranges, but not both.'
• Replace generic parameter descriptions with constraint-aware ones. E.g., 'context_before: Number of lines to include before the target (0-1000; default 5). Use higher values for longer context around matching terms.' Add similar guidance for context_after, max_chars, page_size.
• Add error recovery guidance to tool descriptions. E.g., 'cbeta_fetch: If text ID not found, try cbeta_title_search first with a partial title. If regex fails, check that special regex characters are escaped (use \\ for backslash).'