Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
The server defines 12 academic paper search/retrieval tools with complete input schemas and descriptions. Naming follows the verb_object convention (search_papers, get_paper_details) which is appropriate for the domain. All tools are read-only academic lookups. However, the evaluation reveals significant gaps: descriptions are present but brief (Chinese language, averaging ~30-50 chars), parameter descriptions lack operational guidance and constraints, output schemas are completely undocumented, and error handling is not visible in the provided code. The schema definitions are well-structured JSON Schema with proper types and enums, but the server lacks guidance on what fields LLMs should expect back or how to chain tools together. Tool descriptions are in Chinese and generic, they explain WHAT the tool does but not WHEN or WHY to call it versus alternatives.
Output schemas are completely undocumented. The code shows only input schemas. LLMs cannot determine what fields to expect in responses (e.g., does search_papers return title, authors, abstract, publication_date, url? In what format?). This prevents chaining tools and forces LLMs to guess field names for downstream lookups.
Tool descriptions are in Chinese and very brief (30-50 chars). While 'description' field exists, it lacks operational context: WHEN should an agent call search_papers vs search_papers_by_discipline? What are the tradeoffs? Minimal descriptions force LLMs to infer intent, increasing misuse.
Expand tool descriptions to 100-150 chars including operational context. Example: 'search_papers: General-purpose academic paper search across arXiv, PubMed, Crossref. Use for broad topic searches. For disciplined research (e.g., machine learning only), use search_papers_by_discipline for better results.'
Add constraints to parameter descriptions: 'max_results: integer, 1-100 (default 10). Higher values may cause timeouts. Recommend pagination for result sets > 50.'
Add pagination support: accept optional offset/limit or page/page_size, return total_count and has_more/next_cursor
Consolidate overlapping search tools: combine search_papers, search_papers_by_discipline, search_papers_by_author into a single parameterized search_papers tool with a mode/search_type parameter (general, by_author, by_discipline, by_journal, by_conference)
Document error scenarios and recovery paths in the implementation. Example: 'If paper_id is not found in source database, return {error: "Paper not found in [source]. Available formats: arXiv ID (1234.5678), DOI (10.xxxx/yyyy), PubMed ID (numeric). Try searching with search_papers() first."}'
Add idempotency hints: mark all search/get tools as idempotent (safe to retry) with @idempotentHint annotation if supported by client
Parameter descriptions lack operational constraints. Example: 'max_results' has no min/max guidance (what happens if agent passes 10000?), 'discipline' has no enumeration of valid values, 'source' enums lack priority/coverage information. Rubric baseline: 100% of A+ tools have descriptive parameter annotations including constraints and formats.
No visible error handling logic. If a paper_id is invalid or a source API fails, no recovery guidance is provided to the LLM. Rubric critical check: 'Error responses must tell the LLM what to do next, a raw error code or stack trace gives the agent nothing to act on.'
Tool descriptions do not specify what data is returned or what to do with results. A description should answer: 'What does it do? When should I call it vs a similar tool? What do I get back?' Currently only the first question is partially answered.
No pagination guidance in tool schemas or descriptions. Search tools accept max_results (default 10) but no offset/page/cursor parameters. Large result sets will be truncated without the agent's awareness. Rubric baseline: tools returning lists should accept page/offset and limit, and return total count or next_cursor.
Multiple search tools (search_papers, search_papers_by_discipline, search_papers_by_author, search_papers_by_journal, search_papers_by_conference) have overlapping purposes. LLMs will struggle to select the right one without clear differentiation. Rubric note: 'Avoid multiple tools that do the same thing differently.'
get_open_access_link requires DOI parameter only, but search tools may return paper_ids in other formats (arXiv ID, PubMed ID). No guidance on format conversion or when this tool is applicable. Creates a broken tool chain.
get_open_access_link
Document tool chaining requirements: specify which output fields from search tools feed into get_paper_details, get_citation_info, etc.
Translate descriptions to English and provide bilingual support if targeting international users
Add examples to descriptions in a separate 'examples' field rather than inline: '{"name": "search_papers", "description": "...", "examples": ["Search for transformer neural networks", "Find papers by Yann LeCun", "Trending topics in quantum computing"]}'
Implement rate limiting and timeout handling; document in descriptions what happens when APIs are unreachable
Add per-source coverage documentation: which tool works best for which data source, e.g., 'arXiv has the best preprint coverage for computer science; PubMed for biomedical; DBLP for computer science conferences'