Server has 16 tools with complete input schemas and descriptions, but quality is inconsistent. Most tool descriptions are adequate (100-250 chars) and follow verb_noun naming. However, parameter descriptions lack specificity on constraints, formats, and error recovery. Output schemas are not documented. Error handling is minimal, tools return raw API responses without actionable guidance. No tool annotations (readOnlyHint, destructiveHint). Composition is reasonable (single-responsibility tools), but several tools lack natural-language parameter acceptance (e.g., cite_record requires record_id OR doi, but no guidance on resolution). Average tool score: 58/100.

• Document output schemas for all tools. Specify field names, types (string, integer, array, object), and which fields are required. Example: 'Returns {records: [{id: int, title: string, doi: string, files: [{name: string, size: int, url: string}]}], total: int, next_page: int|null}'.
• Add enum constraints to parameter descriptions. For 'sort', state: 'Sort order: bestmatch (relevance) or mostrecent (publication date).' For 'format', state: 'Output format: json, yaml, bibtex, ris.'
• Add min/max bounds to numeric parameters. E.g., 'page: integer, 1-indexed, default 1' and 'size: integer, 1-100, default 10 (max 100 per API limit)'.
• Document error scenarios and recovery paths. E.g., 'If record not found (404), try search_records() with keywords. If DOI invalid, use resolve_doi() first to validate.'
• Add readOnlyHint: true to all tool definitions to signal to clients that these are safe to cache and retry without side effects.

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

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