Which integrations are available for this server?

Provides tools for biomedical entity normalization, relation mining, and article search using PubTator3, which annotates PubMed articles with entities, relations, and evidence. Provides tools to search academic papers, retrieve paper metadata, traverse citation graphs, and get paper recommendations using the Semantic Scholar API.

How do I use paperSearch?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@paperSearch Find recent papers on immunotherapy for cancer." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

paperSearch

by FreddieWho

Overview Schema Source Related Servers Discussions Admin

Python

Local

SearchPaper

中文文档

SearchPaper is a literature-first infrastructure layer for agent-assisted research. It searches open scholarly literature, normalizes identifiers, merges duplicate records conservatively, preserves provenance, and exports traceable results for downstream agents or human review.

SearchPaper is not a full research agent, systematic-review engine, evidence evaluator, PDF parser, or Zotero replacement. It provides structured literature records and provenance; interpretation stays with the user or a downstream research workflow.

🔎 At a Glance

Area	What SearchPaper provides
📚 Sources	PubMed, Crossref, OpenAlex, Europe PMC, arXiv, bioRxiv, medRxiv, Semantic Scholar, Unpaywall, OpenCitations, PubTator3
🧬 Biomedical workflows	MeSH lookup, PubMed related articles, DOI/PMID/PMCID conversion, PubTator3 literature signals
🔗 Identifiers	DOI, PMID, PMCID, arXiv, OpenAlex, Semantic Scholar IDs
🧾 Provenance	Source records, merge reasons, conflicts, warnings, trace fields
🧠 Agent access	CLI plus MCP tools for OpenCode, Codex, Claude, and other MCP clients
📦 Exports	JSON, JSONL, BibTeX, RIS, NBIB, ENW, Markdown, Zotero CSV, Obsidian notes, APA, MLA
🔓 API keys	Core workflows are no-key usable; optional keys improve rate limits and coverage

Related MCP server: mcp-semanticscholar

✨ What It Does

Multi-source literature search across open scholarly APIs.
Identifier resolution for common scholarly IDs.
Conservative duplicate merge with provenance and conflict preservation.
Local SQLite cache for speed and reproducibility.
Full-text readiness via OA links, Europe PMC XML anchors, and full-text availability fields.
Structured literature signals from PubTator3 with explicit interpretation warnings.
CLI-first workflows plus a small, stable MCP tool surface.
Agent integration helpers for OpenCode, Codex, and Claude.

⚡ Quick Start

git clone <repo-url> ~/Publish/PaperSearch
cd ~/Publish/PaperSearch
uv sync --extra dev
uv run pytest -q

Task	Command
Search literature	`uv run searchpaper search "HCC TACE PD-1" --json`
Resolve a DOI	`uv run searchpaper resolve --doi 10.1038/s41586-021-03819-2 --json`
Check source health	`uv run searchpaper sources status --json`
Run diagnostics	`uv run searchpaper doctor`
Start MCP server	`uv run searchpaper serve --mcp`

For an editable local install:

uv pip install -e .

After installation, the package provides the searchpaper CLI.

⚙️ Configuration

SearchPaper reads ~/.config/searchpaper/config.json. Environment variables override file values.

{
  "semantic_scholar_api_key": "YOUR_KEY",
  "crossref_email": "you@example.com",
  "openalex_email": "you@example.com",
  "ncbi_api_key": "YOUR_NCBI_KEY",
  "cache_path": "~/.cache/searchpaper/cache.db"
}

Variable	Maps to	Description
`SEARCHPAPER_CACHE`	`cache_path`	SQLite cache file
`SEARCHPAPER_CONFIG`	`config_path`	Config file path
`SEMANTIC_SCHOLAR_API_KEY`	`semantic_scholar_api_key`	Optional Semantic Scholar key
`CROSSREF_EMAIL`	`crossref_email`	Crossref polite-pool email
`OPENALEX_EMAIL`	`openalex_email`	OpenAlex polite-pool email
`NCBI_API_KEY`	`ncbi_api_key`	Optional NCBI key

🧭 Core CLI Workflows

Workflow	Command
Plan source routing	`searchpaper plan "query" --profile auto --json`
Search literature	`searchpaper search "query" --json`
Get work by PMID	`searchpaper get --pmid 12345 --json`
Resolve identifier	`searchpaper resolve --doi 10.xxx --json`
Expand from a seed work	`searchpaper expand --doi 10.xxx --by citations,references --json`
Build context pack	`searchpaper context --doi 10.xxx --json`
Fetch full-text anchors	`searchpaper get --pmcid PMC8371605 --sources europepmc --anchors --json`
Probe sources	`searchpaper sources preflight --sources pubmed,arxiv --json`
Explain source behavior	`searchpaper sources explain pubmed`
Diagnose source health	`searchpaper sources diagnose --json`
Save project trace	`searchpaper search "query" --json --save`
Export saved trace	`searchpaper project export <trace_id> --format bibtex`
Lookup MeSH	`searchpaper pubmed mesh "term" --json`
Find related PubMed articles	`searchpaper pubmed related 12345 --json`
Convert PubMed IDs	`searchpaper pubmed convert-ids 10.xxx --json`
Batch process inputs	`searchpaper batch queries.jsonl --format jsonl --output results.jsonl`
Verify references	`searchpaper references verify refs.txt --output-format markdown`
Export results	`searchpaper export results.json --format bibtex`
Inspect capabilities	`searchpaper capabilities --json`

🧩 MCP and Agent Integration

Start the default stdio MCP server:

searchpaper serve --mcp

Start a remote HTTP/SSE MCP server with searchpaper[remote] installed:

searchpaper serve --mcp --transport http --host 127.0.0.1 --port 8000 --path /mcp

Tool	Purpose
`search_literature`	Multi-source literature search
`plan_literature_search`	Source-routing plan without a live search
`get_work`	Fetch one work by identifier
`resolve_identifiers`	Resolve and merge multiple identifiers
`get_source_status`	Source health and optional catalog
`lookup_mesh`	PubMed MeSH descriptor lookup
`find_related_articles`	PubMed related article IDs
`convert_identifiers`	DOI/PMID/PMCID conversion
`search_literature_signals`	Biomedical entity/relation signals
`expand_from_work`	Citations, references, and related papers
`export_records`	Export structured records

Agent	Install command	Output
OpenCode	`searchpaper install --target opencode`	MCP config plus `literature-search` skill
Codex	`searchpaper install --target codex`	MCP snippet plus SearchPaper instructions
Claude	`searchpaper install --target claude`	MCP snippet plus SearchPaper instructions
All	`searchpaper install --target all`	Scaffolds all supported integrations

Review generated files and enable the searchpaper MCP server in your agent settings.

📖 Full-Text Readiness

SearchPaper reports full-text availability without requiring PDF parsing. Records may include full_text_availability, open_access_pdf, and canonical URLs such as doi, pubmed, pmc, oa_url, and oa_pdf_url.

searchpaper resolve --doi 10.1038/s41586-021-03819-2 --json
searchpaper get --pmcid PMC8371605 --sources europepmc --anchors --json
searchpaper context --doi 10.1038/s41586-021-03819-2 --json
searchpaper get --doi 10.1038/s41586-021-03819-2 --download-pdf paper.pdf --json
searchpaper get --pmcid PMC8371605 --download-xml paper.xml --json

PDF parsing remains optional and out of scope.

🛡️ Failure Modes and Signal Rules

Topic	Behavior
Source degradation	Public APIs can fail; optional sources warn and continue
Required sources	`--require pubmed` or `--source-mode pubmed:required` returns exit code 1 on failure
Preferred sources	`source:preferred` emits louder warnings but does not fail the full search
Biomedical signals	PubTator3/co-mention signals are not proof of causality
Evidence evaluation	Out of scope; SearchPaper returns records, provenance, and signals

🗂️ Cache, Privacy, and Project Mode

Default cache: ~/.cache/searchpaper/cache.db
Bypass cache: searchpaper search "query" --no-cache --json
Project mode:

searchpaper init
searchpaper search "HCC TACE PD-1" --json --save
searchpaper project traces
searchpaper project export <trace_id> --format bibtex

The cache may contain raw API responses and query identifiers. Store it accordingly.

🧪 Development

uv sync --extra dev
uv run pytest -q
uv run ruff check .
uv run ruff format .

CI should rely on fixture-backed tests. Live public APIs are useful for manual checks but should not be required for routine validation.

📜 License

MIT

Available Tools

11 tools

convert_identifiersC

Convert DOI/PMID/PMCID identifiers through the NCBI ID converter.

ParametersJSON Schema

Name	Required	Description	Default
`identifiers`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, any network dependencies, rate limits, or error conditions. The phrase 'through the NCBI ID converter' hints at an external call but does not elaborate. This is insufficient for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that communicates the core function efficiently. It is front-loaded and contains no unnecessary words, earning top marks for conciseness and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description is too sparse for the tool's context. It does not clarify the conversion direction, possible limitations, or what the output represents beyond the schema. The tool has one parameter and no annotations, so the description should carry more contextual weight than it does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single 'identifiers' parameter with minimal type info, and the description provides no additional meaning about the parameter—such as acceptable formats, examples, or expected identifier syntax. With schema description coverage at 0%, the description fails to compensate, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Convert' and names the resource 'DOI/PMID/PMCID identifiers through the NCBI ID converter,' clearly stating what the tool does. It lacks an explicit distinction from the sibling tool 'resolve_identifiers,' so it does not fully meet the 'distinguishes from siblings' criterion for a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'resolve_identifiers' or 'search_literature.' The description simply states the action without any context or exclusionary guidance, so it fails to help an agent decide between similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

expand_from_workC

Expand from a known work by citations, references, or similar papers.

ParametersJSON Schema

Name	Required	Description	Default
`by`	No
`limit`	No
`sources`	No
`identifier`	Yes
`source_modes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description gives no behavioral details such as whether the operation is read-only, what the output shape is, or how edge cases are handled. The burden is on the description, and it does not carry it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence with no filler. It is concise and front-loads the core purpose, though it could be expanded with more detail without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, zero parameter descriptions, and no usage guidance, the description is insufficient for an agent to confidently invoke the tool correctly. There is no mention of output behavior or how to configure the expansion despite the presence of five parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only hints at the 'by' parameter through 'citations, references, or similar papers.' It does not explain 'identifier', 'limit', 'sources', or 'source_modes', leaving most parameters semantically opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool expands from a known work using citations, references, or similar papers, providing a specific verb and resource. It is reasonably distinct from siblings like search_literature, though it overlaps with find_related_articles on 'similar papers'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage from a known work but provides no explicit guidance on when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites. Sibling tools are not referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

export_recordsC

Export a list of works to a supported format.

ParametersJSON Schema

Name	Required	Description	Default
`works`	Yes
`format`	No		jsonl

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'export' without explaining output format options (beyond 'supported format'), side effects, permissions, or whether the tool returns data or writes to a file. There is no mention of destructive actions, rate limits, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. It front-loads the key information and is appropriately concise for a simple export tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is too thin for a tool with no annotations. It omits usage context, format enumeration, and any behavioral warnings. The tool is simple, but the description should still clarify supported formats or provide pointers to sibling tools for context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does allude to 'list of works' (mapping to 'works') and 'supported format' (mapping to 'format'), but gives no details on the structure of the 'works' objects, allowed format values, defaults (e.g., 'jsonl'), or constraints. This is minimal added meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Export a list of works to a supported format' clearly states the action (export), the resource (list of works), and the target (supported format). It is distinct from sibling tools like search_literature or get_work, though it does not explicitly differentiate itself from them by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when not to use it. Sibling tools are not referenced, leaving the agent to infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_related_articlesC

Find PubMed related article PMIDs.

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that a valid PMID is required, how the limit parameter affects results, or any error/edge-case behavior. The description only states the output type without any behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words, and the key resource is front-loaded. However, it is so brief that it borders on under-specification, though for the purpose of conciseness it earns a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters and no annotations, the description is incomplete. It does not explain the role of the input PMID or the meaning of limit, nor does it provide usage context. The output schema exists, so return values need not be described, but the lack of parameter and usage context makes it insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not add any meaning to the parameters 'pmid' or 'limit'. Since the schema provides no descriptions, the text should have explained these parameters but does not, leaving the agent without semantic guidance for invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Find PubMed related article PMIDs.' uses a clear action verb 'Find' and identifies the resource as PubMed related article PMIDs. It implicitly distinguishes from sibling tools like search_literature, which searches by query, and expand_from_work, which likely expands from a work record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios such as 'use when you have a PMID and want related articles' or exclude cases better served by search_literature or expand_from_work. The description merely states functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_source_statusB

Return the health status of all configured sources.

ParametersJSON Schema

Name	Required	Description	Default
`include_catalog`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states 'Return the health status' with no additional context about network access, side effects, or what 'configured sources' entails. The read-only nature is implied by the name but not disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no wasted words. It is well-structured for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with an output schema, the description covers the core purpose. However, it lacks any explanation of the `include_catalog` parameter and provides no usage context, making it minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the `include_catalog` parameter at all. With schema coverage at 0%, the parameter's meaning and effect are entirely undocumented, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with the verb 'Return' and the resource 'health status of all configured sources.' This distinguishes it from the sibling tools, which all focus on literature search, identifiers, or records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It merely states what it does, without any exclusions, prerequisites, or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_workB

Get a work by identifier (DOI, PMID, PMCID, arXiv, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`sources`	No
`identifier`	Yes
`source_modes`	No
`identifier_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the retrieval action and does not disclose whether the operation is read-only, any required permissions, rate limits, or data completeness expectations. This is a significant gap given the lack of annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the essential purpose. Every word is informational and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the core function is clear, the tool has four parameters and multiple sibling tools. The description does not explain how optional parameters affect behavior, nor does it provide usage context or contrast with related tools. For a tool with moderate complexity and no annotations, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has four parameters with zero coverage in the description. Only 'identifier' is implicitly explained via the phrase 'by identifier'; sources, source_modes, and identifier_type are entirely unexplained. The description fails to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'get' and resource 'work', and enumerates identifier types (DOI, PMID, PMCID, arXiv), which clearly defines the tool's scope. This distinguishes it from sibling tools like convert_identifiers or resolve_identifiers that focus on identifier mapping rather than retrieving the full work record.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as resolve_identifiers or convert_identifiers. It implies usage when an identifier is at hand but does not state exclusions or mention alternatives, leaving the agent to infer the correct choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_meshC

Lookup MeSH descriptors for a biomedical term.

ParametersJSON Schema

Name	Required	Description	Default
`term`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states a basic lookup action without disclosing any behavioral details like authentication requirements, return format limitations, or query behavior (e.g., exact vs fuzzy matching). This is insufficient for transparent behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately conveys the core function. It is efficiently front-loaded with no wasted words, earning a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple and an output schema exists, the description lacks contextual guidance on when to use it and what behavioral caveats exist. Given no annotations and minimal description, the overall context is incomplete for an agent to confidently select and invoke this tool appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 0% of parameters in descriptions. The description only hints at 'a biomedical term,' which corresponds to the 'term' parameter, but it does not explain the 'limit' parameter or the expected input format. Given the zero schema description coverage, the description fails to compensate for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Lookup') with a clear resource ('MeSH descriptors') and input ('a biomedical term'). It is distinct from sibling tools like search_literature and resolve_identifiers, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description does not mention relationships to sibling tools or any exclusions, leaving usage context entirely implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_literature_searchC

Plan source routing and ranking without running a live search.

ParametersJSON Schema

Name	Required	Default
`sort`	No	relevance
`query`	Yes
`profile`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It discloses that the tool does not run a live search, but it does not explain what it actually returns, whether it is read-only, or any side effects. For a planning tool, this is a significant gap in behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that avoids waste. However, it is somewhat under-specified, and the lack of structure or elaboration makes it only minimally adequate. It earns a middle score for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description is too thin to understand the tool's purpose fully. It doesn't explain what 'source routing' or 'ranking' mean, or how the query influences the plan. For a 3-parameter tool with no annotations, this is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no explanation of the parameters (query, sort, profile). It does not add any meaning beyond the raw schema, leaving the agent without guidance on how to populate or interpret these parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Plan' and clearly differentiates from a live search by saying 'without running a live search.' This distinguishes it from sibling tools like search_literature. However, the phrase 'source routing and ranking' is somewhat vague and not fully explained, keeping it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a user wants to plan or preview rather than execute a live search. It does not explicitly name alternatives, but the contrast with 'live search' gives clear context. There are no explicit exclusions, but the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_identifiersC

Resolve a list of identifiers across sources and return merged records.

ParametersJSON Schema

Name	Required	Description	Default
`sources`	No
`identifiers`	Yes
`source_modes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only states that identifiers are resolved and merged records are returned, but does not disclose whether the operation is read-only, how missing identifiers are handled, what 'merging' entails, or any authorization/rate-limit concerns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tightly worded sentence that front-loads the verb and resource. There is no unnecessary information, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no annotations, and a non-trivial merging behavior, the one-line description is insufficient. It does not explain parameter semantics, usage conditions, or edge cases. The presence of an output schema covers return values but not the tool's operational nuances.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 3 parameters with 0% description coverage. The description alludes to 'sources' but does not explain the identifiers, sources, or source_modes parameters, their formats, defaults, or how they interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Resolve') and the resource ('a list of identifiers across sources') and the output ('return merged records'). It differentiates from sibling tools like convert_identifiers by focusing on lookup and merging rather than simple conversion, though it could be more explicit about the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool over alternatives such as convert_identifiers or search_literature. It implies its purpose but lacks explicit context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_literatureC

Search open scholarly literature across configured sources.

ParametersJSON Schema

Name	Required	Default
`sort`	No	relevance
`year`	No
`limit`	No
`query`	Yes
`venue`	No
`profile`	No	default
`sources`	No
`no_cache`	No
`source_modes`	No
`open_access_only`	No
`min_citation_count`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It fails to mention how results are ordered, how sources are selected, caching behavior, or any side effects. The tool remains opaque beyond the basic search function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundancy or extraneous content. It is concise, though under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, output schema present), the description is severely incomplete. It lacks any context about return behavior, source configuration, or search semantics, making it difficult for an agent to invoke correctly without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides no parameter semantics. With 11 parameters, including filtering options like venue, year, and open_access_only, the description does nothing to clarify their usage or meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches open scholarly literature, using a specific verb and resource. It distinguishes from sibling tools like get_work (retrieving specific works) or resolve_identifiers (ID mapping), though it doesn't explicitly differentiate from other search variants like plan_literature_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states its primary function without mentioning specific use cases, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_literature_signalsC

Search biomedical literature signals via PubTator3.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	No
`entity1`	No
`entity2`	No
`entity2_type`	No	chemical
`relation_type`	No	interact

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Search' and 'via PubTator3', which implies a read-only external lookup but does not explain result behavior, rate limits, authentication, or the meaning of 'signals'. This is insufficient for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and includes a meaningful qualifier ('via PubTator3'). It contains no fluff or redundancy, but the brevity comes at the cost of critical detail, which is a completeness concern rather than a conciseness flaw.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations, six optional parameters, and the existence of a closely related sibling 'search_literature', this one-sentence description is inadequate. It does not explain what a 'signal' is, when to prefer this tool, or how parameters combine. The presence of an output schema helps but cannot compensate for the lack of contextual guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description was expected to explain the roles of the 6 parameters, especially 'entity1', 'entity2', 'entity2_type', and 'relation_type'. It adds no parameter information beyond the raw property names, leaving the interaction between parameters and the 'signal' concept completely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Search' and identifies the resource as 'biomedical literature signals via PubTator3', which distinguishes it from the generic sibling tool 'search_literature'. However, 'signals' is not defined, so the purpose is clear but not fully precise about what constitutes a signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as 'search_literature' or 'find_related_articles'. There are no exclusions, prerequisites, or context cues about appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv0.1.0Aug 10, 2026
- First observedconvert_identifiers
- First observedexpand_from_work
- First observedexport_records
- First observedfind_related_articles
- First observedget_source_status
- First observedget_work
- First observedlookup_mesh
- First observedplan_literature_search
- First observedresolve_identifiers
- First observedsearch_literature
- First observedsearch_literature_signals

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-08-10 12:15 across 11 tools

Disambiguation3/5

Several tools have overlapping purposes: search_literature vs. search_literature_signals both search, resolve_identifiers vs. convert_identifiers both handle IDs, and find_related_articles vs. expand_from_work both find related works. Descriptions clarify differences, but confusion is possible.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (search_literature, get_work, resolve_identifiers, export_records). Minor deviations like expand_from_work (verb-preposition) and lookup_mesh (terse) exist but do not disrupt overall predictability.

Tool Count5/5

With 11 tools, the set is well-scoped for a literature search server. Each tool serves a distinct step in discovery, retrieval, and export without unnecessary redundancy or bloat.

Completeness4/5

The tool set covers the core scholarly search workflow: planning, searching, retrieving by ID, converting identifiers, expanding from known works, and exporting. Minor gaps exist, such as full-text retrieval or advanced citation analysis, but they are not critical for the stated purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Noodle Biomedical Literature Discovery MCP A
io.github.helena-bioinformatics
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
Bioinformatics Biology & Medicine Search
71
pubmed-mcp-server A
io.github.cyanheads
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Search Research & Data Biology & Medicine
114148
paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21
ExMachina AI — agent research rooms A
io.github.SecondStageTurbine
AI agents collaborate on open biomedical problems, citing sources that are machine-checked.
Biology & Medicine Research & Data Autonomous Agents
231

Related MCP Servers

PubMed MCP Server
Search Biology & Medicine Research & Data
PancrePal-xiaoyibao
A
license
A
quality
C
maintenance
Provides structured PubMed literature data for LLM agents, supporting search, caching, and open-access full-text downloads via the MCP protocol.
Updated 4 months ago (2026-05-10 03:34 UTC)
5
51 npm
11
Apache 2.0
mcp-semanticscholar
Research & Data Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to query the Semantic Scholar Academic Graph for scholarly paper data, supporting tools for search, retrieval, and analysis.
Updated 2 days ago (2026-09-18 23:27 UTC)
5 npm
MIT
pubmed-evidence
Biology & Medicine Research & Data
Tianyu-Qu
A
license
Not graded
quality
A
maintenance
Enables PubMed literature search, metadata retrieval, BibTeX export, and evidence table generation for biomedical research agents.
Updated 2 months ago (2026-07-14 10:22 UTC)
2
MIT
Paper Chaser MCP
Research & Data Search
joshuasundance-swca
A
license
Not graded
quality
B
maintenance
Enables AI assistants to conduct academic research workflows such as paper discovery, literature mapping, citation chasing, author pivots, citation repair, and regulatory or species document retrieval.
Updated 2 months ago (2026-07-25 20:03 UTC)
MIT