Grokipedia MCP server demonstrates solid definition quality with well-structured tool schemas, comprehensive parameter descriptions, and proper error handling patterns. All three tools have explicit input schemas with type constraints, range limits, and field descriptions. Tool naming follows verb_noun convention (search, get_page, get_page_content) and is clear and unambiguous. Descriptions are substantial (90-180 chars each), exceeding the 10-char minimum and within the productive 50-200 char range. All parameters have type definitions and descriptions, with appropriate constraints (ge/le for numeric ranges, nullable for optional fields). Error handling includes recovery guidance (search suggestions on not-found, categorized exception types). The primary weaknesses are: (1) output schemas are partially documented through structuredContent but lack explicit field descriptions in tool docstrings; (2) three tools sharing similar functionality (search, get_page, get_page_content) could benefit from clearer decision guidance in descriptions; (3) no batch or multi-resource variants despite agents potentially needing to fetch multiple pages. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are correctly applied to all tools.

• Add explicit 'Output fields' documentation to each tool description. Example: 'Returns: { results: [ { title: string, slug: string, snippet: string, relevance_score: float, view_count: int } ] }' so the LLM knows what to extract.
• Enhance tool descriptions with 'When to use' guidance. Example for get_page: 'Use this for comprehensive page info including metadata and citations. For content-only retrieval, use get_page_content.' This prevents tool selection confusion.
• Document the limit * 2 multiplier behavior explicitly in the search description or refactor to apply filtering before the multiplication, making behavior predictable to the LLM.
• Apply max_content_length constraint to structuredContent fields (linked pages, citations) in get_page. Return only the top 5-10 linked pages rather than potentially hundreds.
• Enhance error handling for search: instead of generic 'Invalid search parameters: {e}', validate parameters explicitly and return actionable errors like 'limit must be 1-50 (got {limit}), offset must be ≥0 (got {offset}), sort_by must be relevance|views (got {sort_by})'.
• Consider adding a batch_get_pages tool accepting an array of slugs, since agents often need multiple pages and sequential calls waste tokens and latency.
• Add a 'What fields can I filter by in search?' discovery tool or document in search description that min_views is the only filter available, preventing agents from attempting invalid filters.

Inferred effective spec: 2025-06-18+.

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