A
licenseB
qualityD
maintenanceA Model Context Protocol server that enables conversational searching of NIH-funded research projects and publications through the NIH RePORTER database.
4
MIT
bioevidence-mcp
by mihir19
Click on "Install 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., "@bioevidence-mcpfind recent evidence on BRCA1 mutations and breast 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.
BioEvidence MCP
Evidence-grounded biomedical retrieval and summarization through the Model Context Protocol.
Repository: github.com/mihir19/bioevidence-mcp
The distribution name is bioevidence-mcp. The Python import namespace
remains bioreason for backward compatibility with existing integrations.
Research use only. No diagnosis, treatment recommendations, or patient data.
Setup
Install Python 3.12 and uv, then install the project dependencies:
uv syncRelated MCP server: MedAdapt Content Server
Manual testing
Call the health tool directly through FastMCP:
uv run fastmcp call src/bioreason/server.py healthThe structured result should be:
{
"status": "ok",
"version": "0.1.1"
}To run the MCP server over the default stdio transport:
uv run fastmcp run src/bioreason/server.py:mcpEvaluation
Run the deterministic, network-free release gate:
uv run python -m bioreason.evaluation.runner \
--mode offline \
--output evaluation/reports/offline-report.json \
--markdown evaluation/reports/offline-report.mdRun one explicitly selected live integration case:
uv run --env-file .env python -m bioreason.evaluation.runner \
--mode live \
--case-id brca1-c68-69delag \
--output evaluation/reports/live-brca1.json \
--markdown evaluation/reports/live-brca1.mdOffline evaluation is deterministic and CI-safe. Live evaluation requires network access, and exact evidence counts may change. OpenAI is optional: missing summarizer configuration produces an incomplete integration case without losing retrieval results. Evaluation establishes citation provenance and eligibility, not clinical validity or complete semantic entailment. See evaluation/README.md.
Available Tools
2 toolshealthA
Return stable service health metadata.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates 'stable' metadata, implying non-destructive and consistent behavior. However, additional details like rate limits or performance impact are absent.
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?
Description is a single, concise sentence with no wasted words. It effectively communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no parameters and an output schema present. The description is adequate for a health endpoint, though it could mention typical use cases like monitoring.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters with 100% coverage. Description adds no parameter information, which is acceptable as there are none. Baseline is 4.
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?
Description clearly states the tool returns stable service health metadata. Distinguishes from sibling tool 'search_biomedical_evidence' which has a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use instructions. Usage is implied as a health check, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_biomedical_evidenceC
Retrieve, score, group, and optionally summarize biomedical evidence.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| include_summary | No | ||
| max_results_per_source | 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 must disclose behavioral traits such as safety (read-only vs. destructive), authentication needs, or side effects. It only lists generic actions; for example, it doesn't clarify if 'score' and 'group' imply state changes or are purely analytical.
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?
Single sentence is concise and front-loaded with the core action, but it omits critical details that could be included without length increase. It earns its place but is insufficiently informative.
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 (unseen), the description lacks context on data sources, scoring methodology, grouping logic, and summary format. For a tool with 3 parameters and no annotations, the description is too sparse to fully understand its capabilities.
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. 'optionally summarize' hints at include_summary, but 'query' and 'max_results_per_source' are not explained. Additionally, 'group' is mentioned but no grouping parameter exists, causing confusion.
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?
Description uses specific verbs (retrieve, score, group, summarize) and resource (biomedical evidence), giving a clear sense of functionality. However, it lacks differentiation from the sibling tool 'health' and doesn't specify what constitutes 'evidence' (e.g., literature types, databases).
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 on when to use this tool versus the sibling 'health' or other alternatives. The description does not state prerequisites or contextual cues for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
C2.9/5.0
Disambiguation5/5
The health and search tools serve completely different purposes—one for service health, the other for querying evidence—so there is no ambiguity.
Naming Consistency2/5
One tool uses a short noun ('health'), while the other uses a verb_noun pattern with underscores ('search_biomedical_evidence'), showing inconsistent naming conventions.
Tool Count2/5
With only two tools and one being a simple health check, the server feels underdeveloped for the domain of biomedical evidence retrieval, suggesting more tools are needed.
Completeness2/5
The search tool provides a broad query capability, but lacks supporting tools for retrieving specific evidence items, managing sources, or performing other typical operations in the domain.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
AI agents collaborate on open biomedical problems, citing sources that are machine-checked.
Citable retrieval across papers, books, patents, Wikipedia, and live social sources.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA specialized Model Context Protocol server that enhances AI-assisted medical learning by connecting Claude Desktop to PubMed, NCBI Bookshelf, and user documents for searching, retrieving, and analyzing medical education content.7MIT
- AlicenseAqualityAmaintenanceProvides LLMs with structured access to critical biomedical databases including PubTator3 (PubMed/PMC), ClinicalTrials.gov, and MyVariant.info through the Model Context Protocol.35623MIT
- AlicenseAqualityAmaintenanceA bridge connecting AI agents to NCBI's PubMed database through the Model Context Protocol, enabling seamless searching, retrieval, and analysis of biomedical literature and data.113,146140Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mihir19/bioevidence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server