libgen-mcp demonstrates solid definition quality with well-structured tool schemas and comprehensive descriptions. All three tools have explicit input schemas with typed parameters and detailed descriptions exceeding 200 characters. Tool naming follows clear verb_noun patterns (search, get_details, download). The primary strengths are thorough parameter documentation, explicit constraints (enums for topics/search_in/order/extra_sources in search tool, explicit mutual exclusivity in get_details and download), and realistic usage examples in descriptions. A notable weakness is the absence of output schema documentation, while the descriptions reference what is returned (md5, download links, BibTeX/RIS exports, URLs), the actual JSON response structure is not formally specified. Tool annotations (readOnlyHint, destructiveHint) are absent, preventing the protocol from automatically inferring which tools are safe to retry. The descriptions include important security warnings about treating results as untrusted third-party text, which is excellent for security posture. Parameter descriptions are generally strong (10-50 words per param), exceeding the 72-char baseline in aggregate. However, the rubric requires formal output schema documentation (pattern:tool), the descriptions document what fields exist but not the JSON structure LLMs should expect, reducing confidence in tool chaining.

• Formalize output schemas for all three tools. Define the response structure explicitly: search returns {results: [{md5, title, author, ...}], open_access: [...], total_count}; get_details returns {md5, identifiers, citations: {bibtex, ris}, ...}; download returns {path} or {url} depending on resolve_only. Include these in the tool definition or in accompanying documentation.
• Add tool annotations: mark search and get_details with readOnlyHint=true; mark download with destructiveHint=true (file write) or idempotentHint=true (if repeated calls to the same md5/id produce the same result).
• Convert mutual exclusivity constraints to JSON Schema oneOf for get_details and download. Example: 'oneOf: [{required: [md5]}, {required: [id, object]}, {required: [doi]}]' to prevent invalid parameter combinations.
• Constrain results_per_page to an enum [25, 50, 100] in the search tool schema rather than leaving it as an unbounded integer.
• Formalize the source parameter in download as an enum (e.g., [libgen, annas, unpaywall, arXiv, crossref, openlibrary, gutenberg, dblp, pubmed, eric]) so LLMs do not hallucinate invalid sources.
• Expand download tool description to match the detail level of search and get_details (target 200-300 chars). Include: when to use resolve_only, what happens if a source is unavailable, and which sources are preferred for different content types.
• Document pagination for search results. If results are capped at a limit (e.g., max page 100 to prevent resource exhaustion), state it explicitly: 'Paginate through results using page (1-based). The catalog limits searches to 100 pages (2,500 results). Use narrower queries or extra_sources to refine.'

Inferred effective spec: 2026-07-28+.

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