Provides tools for searching PubMed via NCBI E-utilities, returning PMIDs, titles, journals, years, and publication types.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BioLit MCP What is the evidence that semaglutide lowers cardiovascular risk? Cite PMIDs."
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.
Citation-grounded biomedical literature review for Claude. An MCP server over PubMed, Europe PMC, NCBI Gene and UniProt, an Evidence Review agent skill, and a 50-question benchmark that measures whether answers can be trusted.
Scientists don't adopt AI research assistants that invent citations. BioLit is built around one rule: Claude may only cite papers it has actually retrieved and read in the session, and the benchmark checks that every cited PMID exists and supports its claim.
flowchart LR
U[Scientist] --> C[Claude + Evidence Review skill]
C -- MCP --> S[BioLit server]
S --> P[PubMed E-utilities<br/>search]
S --> E[Europe PMC<br/>abstracts + citation check]
S --> G[NCBI Gene]
S --> UP[UniProt Swiss-Prot]
C --> A[Answer: claims → PMIDs]
A --> B[Benchmark: PMID exists? claim supported?]Tool | Source | Returns |
| NCBI E-utilities | PMIDs, titles, journals, years, publication types |
| Europe PMC | Abstracts + metadata; non-existent PMIDs listed in |
| NCBI Gene | Official name, chromosome, cytogenetic location, aliases, summary |
| UniProt | Reviewed accession, protein name, length, function |
All tools are read-only. Production details: request timeouts, retry with exponential backoff on 429/5xx, NCBI rate limiting (3 req/s, or 10 req/s with NCBI_API_KEY), input validation, and error messages that are safe to show the model.
Related MCP server: mcp-europepmc
Requires Python 3.11+ and uv.
Claude Code
claude mcp add biolit -- uvx --from git+https://github.com/sanikacentric/biolit-mcp biolit-mcp
mkdir -p ~/.claude/skills && cp -r skills/evidence-review ~/.claude/skills/Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"biolit": {
"command": "uvx",
"args": ["--from", "git+https://github.com/sanikacentric/biolit-mcp", "biolit-mcp"],
"env": { "NCBI_EMAIL": "you@example.com" }
}
}
}Remote (Streamable HTTP): biolit-mcp --transport streamable-http
Optional environment variables: NCBI_API_KEY (higher rate limit), NCBI_EMAIL (recommended by NCBI).
Then ask: "What is the evidence that lecanemab slows cognitive decline in early Alzheimer's disease?"
skills/evidence-review/SKILL.md gives Claude a scientist's workflow: resolve entities → run focused searches → read abstracts → write one claim per sentence with PMIDs → self-check every citation before answering. The output separates the bottom line, evidence, strength & gaps, and references.
evals/ runs 50 questions with and without the BioLit tools:
30 fact questions: UniProt accession + chromosome for well-characterized human genes, scored exactly.
20 literature questions: across oncology, cardiometabolic, neuro, gene therapy and structural biology. Every cited PMID is checked live against PubMed, and an LLM judge decides whether the cited abstracts support each claim.
Metric | What it measures |
| Accession and chromosome both correct |
| Cited PMIDs that exist |
| Cited PMIDs that don't exist |
| Claims supported by their cited abstracts |
pip install -e ".[eval]"
export ANTHROPIC_API_KEY=...
python evals/run_eval.py --mode both # full run (~100 agent runs)
python evals/run_eval.py --mode tools --limit 3 # smoke testResults go here after the first full run (evals/results/*.json).
pip install -e ".[dev,eval]"
pytest # unit tests with recorded API responses; no network or API key needed
ruff check . && ruff format --check .Evidence is read from abstracts, not full text.
The claim-support judge is an LLM. Spot-check its verdicts before relying on the numbers.
Not for clinical decision-making.
MIT
Fetch abstracts and metadata for PMIDs. PMIDs that do not exist are returned in not_found. Use this to read papers before citing them and to verify citations.
| Name | Required | Description | Default |
|---|---|---|---|
| pmids | Yes | Up to 20 PubMed IDs, e.g. ['12345678'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower. The description still adds real behavioral value: it discloses that non-existent PMIDs are surfaced in a not_found field rather than failing, which matters because no output schema is provided.
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?
Two compact sentences with zero filler; the core action and the key error behavior are front-loaded before the usage hint.
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 single-parameter read tool with full annotation coverage, the definition is nearly sufficient, and it partially compensates for the missing output schema by describing not_found. It does not sketch the shape of the returned abstract/metadata fields, leaving one small gap.
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?
Only one parameter, and the schema already documents it fully at 100% coverage including the 20-ID cap and an example. The description adds no syntax or format detail beyond the schema, so baseline 3 applies.
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?
States a specific verb (fetch) and resource (abstracts and metadata) keyed by a named identifier type (PMIDs), which cleanly separates it from search_pubmed. It does not explicitly name the sibling it complements, so it stops short of a 5.
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?
Gives concrete usage context — read papers before citing them and verify citations — which tells the agent when this tool is appropriate rather than search. No explicit 'when not to use' or named alternative, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a gene in NCBI Gene: full name, chromosome, cytogenetic location, aliases and summary.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Official gene symbol, e.g. 'BRCA1' | |
| taxon_id | No | NCBI taxonomy ID; 9606 = human, 10090 = mouse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety and repeatability profile is covered. The description adds the concrete return contents, which is useful since no output schema exists, but it says nothing about unknown-symbol behavior, default-species scope, or NCBI rate limits.
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?
A single front-loaded sentence with no filler; the action is stated first and the return payload second. The trailing comma list of fields is dense but earns its place given there is no output schema.
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 simple, read-only, two-parameter lookup whose annotations carry the safety profile and whose schema is fully documented, the description covers purpose and return shape adequately. It stops short of the operational caveats (species default, not-found handling) that would make it fully self-sufficient.
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?
Schema description coverage is 100%, with both 'symbol' (example 'BRCA1') and 'taxon_id' (9606 = human, 10090 = mouse) fully documented in the schema. The description contributes no additional parameter meaning, so the baseline of 3 applies.
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?
Specific verb ('look up') plus resource ('a gene in NCBI Gene'), and it enumerates the fields returned (full name, chromosome, cytogenetic location, aliases, summary), so the agent knows exactly what it gets. It does not, however, distinguish itself from the sibling lookup_protein, which follows the same lookup pattern and could plausibly be confused for the same request.
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?
Usage is only implied: an agent can infer it should call this when it has a gene symbol and needs gene-level metadata. There is no explicit when-to-use, no when-not-to-use, and no pointer to search_pubmed, get_abstracts, or lookup_protein for adjacent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the reviewed (Swiss-Prot) UniProt entry for a gene: accession, protein name, length, function.
| Name | Required | Description | Default |
|---|---|---|---|
| taxon_id | No | NCBI taxonomy ID; 9606 = human | |
| gene_symbol | Yes | Gene symbol of the protein, e.g. 'EGFR' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower. The description nevertheless adds real behavioral context by restricting scope to reviewed Swiss-Prot entries, telling the agent non-curated TrEMBL records will not appear. It does not say what happens when a symbol is ambiguous or unmatched, which keeps it out of 5 territory.
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?
A single front-loaded sentence that names the datasource, the input unit, and the returned fields, with zero filler. Every clause earns its place.
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 read-only lookup with no output schema, the description compensates by enumerating the returned fields and the reviewed-entry restriction. Remaining gaps are edge-case behavior (no-match handling, multi-entry gene symbols), which are minor for a tool this shape.
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?
Schema description coverage is 100%: taxon_id is documented with its default (9606 = human) and gene_symbol with an example ('EGFR'). The description adds no syntax, format, or defaulting detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb (look up) plus a precisely scoped resource (the reviewed Swiss-Prot UniProt entry for a gene) and enumerates what comes back: accession, protein name, length, function. This is clearly distinguishable from siblings like lookup_gene, search_pubmed, and get_abstracts.
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?
Usage is implied by the description (use it when you have a gene symbol and want its curated protein record), but there is no explicit when-to-use, when-not-to-use, or named alternative such as lookup_gene. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed. Returns PMIDs, titles, journals, years and publication types (no abstracts).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | PubMed query; supports PubMed syntax, e.g. 'semaglutide AND cardiovascular outcomes' | |
| min_year | No | Only papers published in or after this year | |
| max_results | No | Number of results (1-50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds value by enumerating the exact return fields and excluding abstracts, but it omits notable operational traits such as PubMed rate limits or result-count behavior.
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?
Two tight sentences, zero waste, with the core purpose front-loaded and the return shape immediately after. Every clause earns its place.
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?
With no output schema, the description appropriately enumerates return fields, and the safety profile is covered by annotations. Minor gaps remain around pagination/rate limits, but nothing essential for calling the tool correctly is missing.
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?
Schema description coverage is 100%, so query, min_year, and max_results are fully documented in the schema (including the 1-50 bound and PubMed syntax example). The description adds no parameter meaning beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ('Search PubMed') and clarifies the returned fields, including the negative constraint 'no abstracts', which implicitly distinguishes it from the sibling get_abstracts. It stops short of naming that sibling explicitly, so the routing hint is only partial.
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 '(no abstracts)' note implies a two-step workflow where get_abstracts follows, but the description never states when to use this tool versus the alternatives or any preconditions. Usage is only implied, not spelled out.
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.
v0.1.0get_abstractslookup_genelookup_proteinsearch_pubmedScored across 4 tools
Each tool has a clearly distinct role: search_pubmed finds PMIDs, get_abstracts retrieves full text by PMID, lookup_gene and lookup_protein target different NCBI/UniProt resources. The search-then-fetch pipeline is explicit and no two tools could be confused.
All four names follow a clean verb_noun snake_case pattern (search_pubmed, get_abstracts, lookup_gene, lookup_protein). The verbs vary (search/get/lookup) but each is accurate for its action, and the convention is uniform throughout.
Four tools is on the lean side but each earns its place and matches the narrow literature-lookup scope. A slightly richer surface (e.g. full-text or citation helpers) would round it out.
Core workflow of searching literature, reading abstracts, and resolving gene/protein metadata is covered, including not_found handling. Gaps remain around full-text retrieval, citation formatting, and sequence/variant detail, but agents can work around them.
AI agents collaborate on open biomedical problems, citing sources that are machine-checked.
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
Ground answers in scientific literature. Search full text, evaluate trust, access full-text articles
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
