This server exhibits significant quality gaps across naming, descriptions, parameters, and error handling. While tool names follow verb_noun patterns (scholarly-mode-start, get_articles_list, get_springer_article_data), most descriptions are extremely brief and lack actionable context. Parameter descriptions are missing or trivial. Schema documentation is absent. Error handling returns unstructured JSON strings instead of guiding recovery. The two 'scholarly-mode' tools are anti-patterns that attempt to manipulate agent behavior via prompt injection rather than providing legitimate API functionality. Overall definition quality is well below production baseline.
Two tools (scholarly-mode-start, scholarly-mode-stop) are prompt-injection anti-patterns that attempt to manipulate agent behavior via tool responses. These violate MCP principles: they do not perform data operations, they inject system instructions, and they represent a security and composition anti-pattern.
All four tools have descriptions under 30 characters. Descriptions like 'Get articles list' and 'Get Springer article data' lack context on WHAT the tool does, WHEN to use it, WHAT it returns, and any prerequisites. Minimum production baseline is 50 - 200 characters for LLM-optimized descriptions.
Parameters lack descriptions explaining format, range, and constraints. 'query' has no description at all. 'articles_per_page' has a generic description ('Optional number of results per page') with no min/max bounds or default behavior documented. This forces LLMs to guess valid inputs.
Recommendations
CRITICAL: Remove the 'scholarly-mode-start' and 'scholarly-mode-stop' tools. They are prompt-injection anti-patterns and do not belong in an MCP server. If the intent is to support different agent behaviors, use resource templates or server configuration, not tools.
Expand all tool descriptions to 80 - 200 characters, explicitly stating: WHAT the tool does, WHEN to call it (vs. similar tools), WHAT parameters it accepts, and WHAT it returns. Example: 'Search Springer Open Access articles by query string (title, author, keyword). Returns up to 20 article summaries with IDs for use with get_springer_article_data. Call this first to discover articles; then call get_springer_article_data with an article ID to fetch full content.'
Add parameter descriptions for 'query' and 'id': 'query': 'Search terms or keywords (e.g., machine learning, neural networks). Supports Springer query syntax (optional).' 'id': 'Springer article ID returned by get_articles_list. Format: opaque string identifier.'
Document the output schema for both data-fetching tools. For get_articles_list: 'Returns an array of article summaries. Each includes: title (string), authors (string array), doi (string), openaccess_url (string), publication_date (string, ISO 8601), and id (string for use with get_springer_article_data).' For get_springer_article_data: 'Returns full article metadata and content including: title, authors, abstract, full_text (if available), jats_xml (raw XML), publication_date, doi, url.'
Improve error handling: Instead of 'No results found', return 'No articles found for query "{query}". Try a broader search term or refine your keywords.' Instead of 'No article data found', return 'Article ID {id} not found or inaccessible. Verify the ID from your previous search results. If the ID is correct, the article may require authentication.'
Output schemas are not documented. Tools return stringified JSON objects with no indication of expected fields, types, or structure. LLMs cannot plan downstream tool calls or extract specific fields without explicit schema documentation.
Error handling is non-actionable. Tools return generic error messages (e.g., 'No results found', 'No article data found') as raw JSON strings without recovery guidance. Per the rubric, errors must state WHAT went wrong and WHAT TO DO NEXT (e.g., 'Try a different search query' or 'Verify the article ID from previous results').
No pagination or result-limit documentation. get_articles_list accepts 'articles_per_page' but does not document max page size, total result count, or how to retrieve subsequent pages. Pagination guidance is missing from both tool descriptions.
Missing dependency hints and prerequisites. get_springer_article_data requires an 'id' from get_articles_list, but this relationship is not documented. Description should state: 'First call get_articles_list to search for articles and obtain their IDs, then use this tool to fetch full article data for a specific ID.'
No API key leakage detected in tool parameters (good), but springer.ts has a hardcoded empty SPRINGER_API_KEY string. Recommend using only process.env.SPRINGER_API_KEY with a clear error if not set.
Document pagination in get_articles_list description: 'Max articles_per_page: 100. If total results exceed articles_per_page, implement pagination by making multiple calls with different start positions (if API supports it). Current implementation fetches only the first page; pagination not fully supported.'
Add a dependency note to get_springer_article_data: 'Prerequisite: Call get_articles_list first to search for and obtain article IDs.'
Remove hardcoded SPRINGER_API_KEY = '' from springer.ts. Validate that process.env.SPRINGER_API_KEY is set at startup and return a clear error if missing: 'SPRINGER_API_KEY environment variable not set. Configure it before running the server.'
Consider adding a third tool, 'describe_springer_search', that explains Springer's query syntax and search operators. This helps agents formulate better queries without trial-and-error.
Add error classification in tool responses: distinguish retryable errors (network timeout, rate limit) from user-fixable errors (invalid ID, no results) from fatal errors. Include suggested recovery action for each.