Search Daily-Updated Scientific Data
Scored across 2 tools
Lookup by DOI and search by query are clearly distinct operations with no overlap in purpose or parameters. An agent can easily select the right tool based on whether it has a specific identifier or a topic query.
Both tools follow a consistent verb_noun pattern (lookup_paper, search_papers) using lowercase snake_case. The naming is predictable and aligns with common conventions.
With only two tools, the surface feels thin for a scientific data server. While they cover core retrieval, the server lacks support for other common actions like listing papers by author or retrieving related papers, making the count borderline too few.
The server provides lookup and search, which are essential for a scientific data tool. However, there are notable gaps: no tools for listing papers by author, fetching citations, or exploring related work, which limits the server's utility for common research workflows.
Look up a single paper by its DOI.
Args: doi: The DOI of the paper (e.g. "10.1038/s41586-024-07386-0"). output_format: "evidence" for compact claim-level evidence (default), "legacy" for original paper metadata, or "full" for both.
Returns: An envelope with found status and the paper in result, or a not-found message. A found paper counts as one result.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| output_format | No | evidence |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful behavior: it returns an envelope with found status, a paper in result or a not-found message, and notes that a found paper counts as one result. It also explains the output_format options, providing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear 'Args' and 'Returns' sections, is appropriately concise, and front-loads the purpose. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter lookup tool with an output schema, the description is complete: it covers purpose, parameter semantics, return envelope structure, and the not-found case. No critical information appears to be missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: doi includes a concrete example, and output_format enumerates the three possible values ('evidence', 'legacy', 'full') with their meanings and the default. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Look up a single paper by its DOI.' This is a specific verb+resource combination that immediately distinguishes it from the sibling tool search_papers, which implies broader search behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a specific DOI and need a single paper, which is clear context. However, it does not explicitly mention the sibling tool search_papers as an alternative or provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search claim-level evidence extracted from full-text scientific papers.
Args: query: Search terms (e.g. "CRISPR gene editing efficiency"). SHORT, concise queries are best. English language only. Use days_back, num_results, min_citations, and study_type instead of adding years or filters to the query. num_results: Number of results to return (1-100, default 16). First 50 results are free, then metered per result for paid users. days_back: Only return papers published within the last N days. min_citations: Only return papers with at least this many references cited. study_type: Only return papers of this study type. One of: primary study | systematic review | meta-analysis | narrative review | protocol | dataset | commentary | other. output_format: "evidence" for compact claim-level evidence (default), "legacy" for original paper metadata, or "full" for both.
Returns: An envelope whose results list contains papers with claims, experiments, exact results, demonstrated scope, limitations, and provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| days_back | No | ||
| study_type | No | ||
| num_results | No | ||
| min_citations | No | ||
| output_format | No | evidence |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation readOnly and idempotent, and the description adds non-obvious behavior: claim-level extraction, English-only queries, a metering/rate-limit note after 50 results, and the envelope shape with claims/experiments/provenance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose sentence is front-loaded, followed by a lean Arg/Returns structure. Every line adds usable detail, and there is no repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no schema descriptions and one sibling, the description is complete: all parameters are explained, the return envelope is summarized, and annotations already cover safety. An agent can select and call this tool without further docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description does the work: it supplies defaults, ranges, allowed values for study_type and output_format, and query style guidance. The only weakness is that min_citations is defined as 'references cited', which could be confused with a paper's reference count rather than its citation count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Search claim-level evidence extracted from full-text scientific papers.' This clearly differentiates by scope from a single-paper lookup, but it never explicitly references lookup_paper, so it is not fully sibling-distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operating guidance: short English queries, use days_back/num_results/min_citations/study_type instead of stuffing filters into query text, and output_format choices. This tells an agent how to invoke the tool correctly, but it does not state when to prefer lookup_paper over search_papers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_papers2 fields changedInput schema / properties / min_citationsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Input schema / properties / study_typeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}lookup_paper3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / doi / descriptionRemoved value: -"The DOI of the paper (e.g. \"10.1038/s41586-024-07386-0\")."Input schema / properties / output_formatAdded value: +{
+ "default": "evidence",
+ "type": "string"
+}search_papers5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / days_back / descriptionRemoved value: -"Only return papers published within the last N days."Input schema / properties / num_results / descriptionRemoved value: -"Number of results to return (1-100, default 16). First 50 results are free, then billed at $0.01/result for paid users."Input schema / properties / output_formatAdded value: +{
+ "default": "evidence",
+ "type": "string"
+}Input schema / properties / query / descriptionRemoved value: -"Search terms (e.g. \"CRISPR gene editing efficiency\") Short, concise queries are best. English language only. Don't include years or filters — use the days_back and num_results params instead."lookup_paper2 fields changedInput schema / properties / api_keyRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
-}Input schema / properties / doi / descriptionAdded value: +"The DOI of the paper (e.g. \"10.1038/s41586-024-07386-0\")."search_papers4 fields changedInput schema / properties / api_keyRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null
-}Input schema / properties / days_back / descriptionAdded value: +"Only return papers published within the last N days."Input schema / properties / num_results / descriptionAdded value: +"Number of results to return (1-100, default 16). First 50 results are free, then billed at $0.01/result for paid users."Input schema / properties / query / descriptionAdded value: +"Search terms (e.g. \"CRISPR gene editing efficiency\") Short, concise queries are best. English language only. Don't include years or filters — use the days_back and num_results params instead."lookup_papersearch_papers
Add one secure layer between your agents and this server.