用于与NIH RePORTER聊天的模型上下文协议(MCP)服务器。以对话方式搜索 NIH 资助的研究项目和出版物。随附博客文章在此。
按不同标准搜索 NIH 资助的研究项目：
财政年度
首席研究员姓名
组织详细信息（名称、州、城市、类型、部门）
资助金额
COVID-19 响应状态
资金机制
研究所/中心代码
RCDC 术语
日期范围
搜索与 NIH 项目相关的出版物
项目和出版物的综合搜索功能
详细的项目和出版物信息，包括摘要
可配置的结果限制
Related MCP server: MedAdapt Content Server
Python 3.12 或更高版本
UV 包管理器（推荐用于更快的依赖项安装）
克隆存储库：
git clone <repository-url>
cd mcp-nih-reporter创建并激活虚拟环境：
python -m venv .venv
source .venv/bin/activate # On Windows, use `.venv\Scripts\activate`使用 UV 安装依赖项：
uv pip install -e .该 MCP 服务器通过多种工具提供对 NIH RePORTER API 的访问：
search_projects ：搜索 NIH 资助的研究项目
search_publications ：搜索与 NIH 项目相关的出版物
search_combined ：同时搜索项目和出版物
test_connection ：测试 API 连接
您可以将此 MCP 与任何兼容 MCP 的客户端一起使用，例如：
克劳德桌面
光标
其他支持 MCP 的工具
{
"mcpServers": {
"nih-reporter": {
"command": "<fully qualified path to>/uv",
"args": [
"run",
"--with",
"mcp[cli]",
"mcp",
"run",
"<fully qualified path to>/mcp-nih-reporter/mcp-nih-reporter.py"
]
}
}
}搜索结果将以结构化格式返回，其中包含项目详细信息，包括：
项目名称和摘要
首席研究员信息
组织详细信息
资金信息
项目日期和状态
当 MCP 尝试在客户端（例如 Claude Desktop）中运行时，会在根文件夹中创建一个日志文件。如果您遇到问题，请检查该文件。
该项目采用：
httpx用于异步 HTTP 请求
mcp用于任务控制协议的实现
python-dotenv用于环境变量管理
uv用于依赖管理
日志写入项目根目录下的mcp-nih-reporter.log文件。日志级别默认为 INFO。
欢迎贡献代码！欢迎提交 Pull 请求。对于重大变更，请先提交一个 issue 来讨论您想要修改的内容。
分叉存储库
创建你的功能分支（ git checkout -b feature/amazing-feature ）
提交您的更改（ git commit -m 'Add some amazing feature' ）
推送到分支（ git push origin feature/amazing-feature ）
打开拉取请求
请确保适当更新测试并遵循现有的代码风格。
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
Search for NIH projects and their related publications in a single query
Args:
fiscal_years: Comma-separated list of fiscal years (e.g., "2022,2023")
pi_names: Comma-separated list of PI names
organization: Name of the organization
org_state: Two-letter state code (e.g., "CA", "NY")
funding_mechanism: Type of funding (e.g., "R01", "F32", "K99")
ic_code: Institute or Center code (e.g., "NCI", "NIMH")
min_amount: Minimum award amount
max_amount: Maximum award amount
covid_response: COVID-19 response category
include_publications: Whether to include related publications
publication_years: Comma-separated list of publication years
limit: Maximum number of results to return (default: 10, max: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| fiscal_years | No | ||
| pi_names | No | ||
| organization | No | ||
| org_state | No | ||
| funding_mechanism | No | ||
| ic_code | No | ||
| min_amount | No | ||
| max_amount | No | ||
| covid_response | No | ||
| include_publications | No | ||
| publication_years | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality but doesn't describe what the tool returns (e.g., format, structure), whether it's read-only or has side effects, performance characteristics, or error handling. The parameter list in the description adds some context but doesn't fully compensate for the lack of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by a bullet-point-like parameter list. Each parameter explanation is concise and informative. However, the parameter section is lengthy (12 items), which is necessary given the complexity but slightly reduces efficiency. No wasted sentences.
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?
Given the complexity (12 parameters, no annotations, no output schema), the description is partially complete. It excels in parameter documentation but lacks output details, behavioral context, and sibling differentiation. For a search tool with many parameters, more guidance on results and usage would be beneficial, but the parameter coverage is strong.
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?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed parameter semantics for all 12 parameters, including examples (e.g., '2022,2023' for fiscal_years, 'CA' for org_state), data types (e.g., 'comma-separated list', 'two-letter state code'), and defaults (e.g., 'default: 10, max: 50' for limit). This adds significant value 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 purpose: 'Search for NIH projects and their related publications in a single query.' This specifies the verb ('search'), resources ('NIH projects and their related publications'), and scope ('in a single query'). However, it doesn't explicitly differentiate from sibling tools like 'search_projects' or 'search_publications' beyond the 'combined' aspect, which is why it doesn't reach a perfect score.
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 provides no guidance on when to use this tool versus the sibling tools 'search_projects' or 'search_publications'. It doesn't mention prerequisites, alternatives, or specific contexts where this combined search is preferred over separate searches. The only implied usage is for combined queries, but this isn't explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for NIH funded projects with advanced criteria
Args:
fiscal_years: Comma-separated list of fiscal years (e.g., "2022,2023")
pi_names: Comma-separated list of PI names (will match any of the names)
organization: Name of the organization
org_state: Two-letter state code (e.g., "CA", "NY")
org_city: City name
org_type: Organization type
org_department: Department name
min_amount: Minimum award amount
max_amount: Maximum award amount
covid_response: COVID-19 response category (options: "Reg-CV", "CV", "C3", "C4", "C5", "C6")
funding_mechanism: Type of funding (e.g., "R01", "F32", "K99")
ic_code: Institute or Center code (e.g., "NCI", "NIMH")
rcdc_terms: Comma-separated RCDC terms for research categorization
start_date: Project start date (YYYY-MM-DD)
end_date: Project end date (YYYY-MM-DD)
newly_added_only: Only show recently added projects
include_abstracts: Include project abstracts in results
limit: Maximum number of results to return (default: 10, max: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| fiscal_years | No | ||
| pi_names | No | ||
| organization | No | ||
| org_state | No | ||
| org_city | No | ||
| org_type | No | ||
| org_department | No | ||
| min_amount | No | ||
| max_amount | No | ||
| covid_response | No | ||
| funding_mechanism | No | ||
| ic_code | No | ||
| rcdc_terms | No | ||
| start_date | No | ||
| end_date | No | ||
| newly_added_only | No | ||
| include_abstracts | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool searches with advanced criteria and provides parameter details, it doesn't describe important behavioral aspects like authentication requirements, rate limits, pagination behavior, error handling, or what the search results actually contain beyond the mention of abstracts.
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 a clear opening sentence followed by a comprehensive parameter list. While lengthy due to the many parameters, every sentence serves a purpose. The parameter explanations are efficient and avoid redundancy, though the overall length might benefit from some grouping or categorization.
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 complex search tool with 18 parameters and no output schema, the description provides excellent parameter documentation but lacks information about the search results format, pagination, sorting options, and how multiple criteria interact. Without annotations or output schema, the agent won't know what fields are returned or how results are structured beyond the mention of abstracts.
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?
The description provides extensive parameter documentation with clear examples and explanations for all 18 parameters, compensating completely for the 0% schema description coverage. It adds significant value beyond the basic schema by explaining format requirements (e.g., 'comma-separated list', 'YYYY-MM-DD'), providing examples, and clarifying parameter behavior (e.g., 'will match any of the names', 'default: 10, max: 50').
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 searches for NIH funded projects with advanced criteria, providing a specific verb ('search') and resource ('NIH funded projects'). However, it doesn't differentiate from sibling tools like search_combined or search_publications, which appear to be related search functions.
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 provides no guidance on when to use this tool versus alternatives like search_combined or search_publications. There's no mention of prerequisites, use cases, or exclusions that would help an agent choose between these similar-sounding search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for publications linked to NIH projects
Args:
pmids: Comma-separated list of PubMed IDs
core_project_nums: Comma-separated list of NIH core project numbers
limit: Maximum number of results to return (default: 10, max: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| pmids | No | ||
| core_project_nums | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality but doesn't describe what the search returns (e.g., publication metadata, project links), whether results are paginated, error conditions, or performance characteristics. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured with a clear purpose statement followed by parameter explanations. Each sentence adds value, and there's no redundant information. The formatting with 'Args:' section helps readability, though it could be slightly more polished.
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 search tool with 3 parameters and no annotations or output schema, the description adequately covers parameter semantics but lacks information about return values, error handling, and behavioral characteristics. It's minimally viable but has clear gaps in explaining what the tool actually returns and how it behaves.
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?
The description provides clear semantic information about all three parameters beyond what the schema offers. It explains that pmids are 'PubMed IDs', core_project_nums are 'NIH core project numbers', and limit controls 'maximum number of results to return' with default and maximum values. With 0% schema description coverage, this description fully compensates by explaining what each parameter means.
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 purpose: 'Search for publications linked to NIH projects'. It specifies the resource (publications) and scope (linked to NIH projects), which distinguishes it from sibling tools like search_projects. However, it doesn't explicitly differentiate from search_combined, which might be a more general search tool.
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 provides no guidance on when to use this tool versus alternatives like search_combined or search_projects. It doesn't mention prerequisites, constraints, or typical use cases. The only implicit guidance is that it searches publications linked to NIH projects, but this doesn't help an agent choose between available search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the connection to the NIH RePORTER API
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but reveals nothing about behavioral traits: no indication of what 'testing' entails (e.g., ping, authentication check, endpoint validation), what happens on success/failure, whether it has side effects, or what the response format might be. The description is minimal and lacks operational context.
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 a single, clear sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point without unnecessary elaboration.
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 zero-parameter connectivity test tool with no output schema, the description is minimally complete - it tells the agent what the tool does. However, without annotations or output schema, it lacks important behavioral context about what 'testing' means operationally and what results to expect. The description meets basic requirements but leaves significant gaps in understanding the tool's behavior.
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?
The tool has zero parameters, and schema description coverage is 100% (empty schema is fully documented). The description doesn't need to explain parameters, so it appropriately focuses on the tool's purpose. Baseline for zero parameters with full schema coverage is 4, as there's no parameter information to add.
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 action ('Test') and the target resource ('connection to the NIH RePORTER API'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (search_combined, search_projects, search_publications), which are all data retrieval tools while this is a connectivity test tool.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, typical use cases (e.g., verifying API availability before running searches), or relationship to the sibling search tools. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The three search tools have overlapping purposes that could cause confusion. search_combined appears to combine projects and publications, while search_projects and search_publications handle them separately. An agent might struggle to choose between search_combined and the other two for certain queries, though the descriptions provide some guidance about their different focuses.
All tool names follow a consistent verb_noun pattern with snake_case. search_combined, search_projects, search_publications, and test_connection all use clear, predictable naming conventions that make the tool set easy to understand at a glance.
Four tools is reasonable for an NIH RePORTER interface, though it feels slightly thin. The three search operations and one connection test cover the core functionality, but additional tools for retrieving specific projects or publications by ID might have made the surface more complete. The count isn't problematic, just minimal.
The tool set provides search capabilities but lacks obvious retrieval operations. There's no way to get a specific project or publication by identifier (like project number or PMID), which creates a gap in the CRUD lifecycle. Agents can work around this by searching with specific criteria, but direct lookup tools would make the surface more complete for the NIH RePORTER domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
Semantic search across 5 US government healthcare databases.
NIH RePORTER MCP — every NIH-funded research project (free, no auth)
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbdamask/mcp-nih-reporter'
If you have feedback or need assistance with the MCP directory API, please join our Discord server