NIH RePORTER 와 채팅을 위한 모델 컨텍스트 프로토콜 (MCP) 서버입니다. 대화형 방식으로 NIH 지원 연구 프로젝트 및 출판물을 검색하세요. 관련 블로그 게시물은 여기를 참조하세요 .
다양한 기준으로 NIH 자금 지원 연구 프로젝트를 검색하세요.
회계연도
주요 연구자 이름
조직 세부 정보(이름, 주, 도시, 유형, 부서)
자금 조달 금액
COVID-19 대응 현황
자금 조달 메커니즘
연구소/센터 코드
RCDC 용어
날짜 범위
NIH 프로젝트와 관련된 출판물 검색
프로젝트와 출판물 모두에 대한 통합 검색 기능
초록을 포함한 자세한 프로젝트 및 출판 정보
구성 가능한 결과 제한
Related MCP server: MedAdapt Content Server
Python 3.12 이상
UV 패키지 관리자(더 빠른 종속성 설치를 위해 권장됨)
저장소를 복제합니다.
지엑스피1
가상 환경을 만들고 활성화하세요.
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)에서 실행될 때 루트 폴더에 로그 파일이 생성됩니다. 문제가 발생하면 해당 로그 파일을 확인하세요.
이 프로젝트에서는 다음을 사용합니다.
비동기 HTTP 요청을 위한 httpx
Mission Control Protocol 구현을 위한 mcp
환경 변수 관리를 위한 python-dotenv
종속성 관리를 위한 uv
로그는 프로젝트 루트 디렉터리의 mcp-nih-reporter.log 에 기록됩니다. 로깅 수준은 기본적으로 INFO로 설정됩니다.
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요. 주요 변경 사항의 경우, 먼저 이슈를 열어 변경 사항을 논의해 주세요.
저장소를 포크하세요
기능 브랜치를 생성합니다( git checkout -b feature/amazing-feature )
변경 사항을 커밋하세요( git commit -m 'Add some amazing feature' )
브랜치에 푸시( git push origin feature/amazing-feature )
풀 리퀘스트 열기
적절하게 테스트를 업데이트하고 기존 코드 스타일을 따르세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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