Strong tool naming and schema definitions across all 8 tools. All tools have clear, action-oriented names (corpus_info, term_frequency, freqs, etc.) that start with verbs and convey intent clearly. Descriptions are present and substantive (avg ~150-200 chars), meeting the 10-1024 char baseline well. All parameters have explicit type definitions and descriptions. However, output schemas are not documented, responses are returned as plain text via httpRequest without structured schema definition, limiting downstream tool chaining. Error handling is present but minimal, soft/hard error categorization exists but recovery guidance is absent. Tool annotations (readOnlyHint, idempotentHint, destructiveHint, openWorldHint) are correctly applied to all tools, demonstrating spec alignment. Parameter descriptions are consistently detailed and include CQL domain context. No security issues detected (no secrets in parameters, read-only operations only). Composition is clean, each tool has single responsibility, though output schema documentation would strengthen composition patterns.

• Document output schemas for all 8 tools. Specify JSON object structure, field types, and field descriptions. E.g., corpus_info should return {corpus_id: string, name: string, attributes: [{name: string, type: string}], ...}. This enables LLMs to plan chaining and extract the right fields.
• Add error recovery guidance. Update mcp.NewToolResultError() calls to include actionable hints. E.g., 'Corpus "xyz" not found. Available corpora: corpus_1, corpus_2. Call corpus_info(corpus_id) to see details.'
• Enhance parameter descriptions with constraint details. For 'q' parameter, add: 'CQL (Corpus Query Language) string. Max 10,000 chars. Common operators: word, lemma, tag, pos. See CQL documentation link.' For numeric params, add bounds: 'Integer, range 1 - 1000.'
• Add a discovery tool: get_available_corpora() returning {corpora: [{id: string, name: string, description: string}]}. This helps agents understand the corpus landscape before querying and prevents 'corpus not found' errors.
• Document pagination support. concordance has 'fromp' (offset) and 'pagesize' parameters but descriptions do not clarify total count or whether there is a next_cursor. Add: 'fromp: starting position (0-indexed). Returns up to pagesize results. Call again with fromp += pagesize to fetch next page.'
• Consider adding rate-limit guidance. Tools call external HTTP API (conf.APIUrl); if that API has rate limits, document expected throttling and retry guidance in error handling.

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

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