The Google Scholar MCP server defines a single tool with a well-structured schema and comprehensive parameter documentation. The tool name follows verb_noun convention (search_google_scholar), and the input schema is explicitly visible in server/src/tools.ts with proper JSON Schema types and constraints. Parameter descriptions are present and informative. However, the output schema is not formally documented, the tool returns JSON-stringified results without a declared output type specification, which limits LLM ability to plan downstream operations. Error handling is basic (try-catch with error message wrapping) but lacks categorization guidance. The server is well-implemented within its narrow scope but lacks some production-grade refinements around output documentation and sophisticated error recovery patterns.

• Document the output schema explicitly in the tool definition. Add a formal output type specification stating: 'Returns an object with properties: query (string), filters (object with author, yearRange), totalResults (number), results (array of objects with title, authors, abstract, url, year, citations, etc.).'
• Enhance error handling to categorize errors. For transient failures (network timeouts), return 'Retryable: temporary service unavailable, please retry in 5 seconds.' For invalid inputs, return 'User-fixable: query must be non-empty string; provided: {value}.' For fatal errors, return 'Fatal: Google Scholar API has deprecated this endpoint, the search_google_scholar tool is no longer supported.'
• Remove literal examples from the tool description. Instead of 'e.g. machine learning, neural networks', replace with a format hint: 'The search query string (e.g., academic domain like machine learning or neural networks).' Or better, let the description speak to the intent without examples.
• Add pagination support. Expose parameters like `page` (default 1) and document that results are capped at 20 per page. Or implement cursor-based pagination with a `next_cursor` field in the response to enable agents to retrieve subsequent result sets.
• Add conditional schema validation to prevent startYear > endYear at the schema definition level, or document this constraint more explicitly in parameter descriptions as a mutual dependency.
• Consider adding an optional `sort_by` parameter (e.g., enum: relevance, recency, citation_count) to enable richer search refinement, common in academic search APIs.

Inferred effective spec: 2026-07-28+.

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