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）で実行しようとすると、ルートフォルダにログファイルが作成されます。問題が発生した場合は、ログファイルを確認してください。
このプロジェクトでは以下を使用します:
非同期HTTPリクエスト用のhttpx
ミッションコントロールプロトコル実装のためのmcp
環境変数管理のためのpython-dotenv
依存関係管理のためのuv
ログはプロジェクトのルートディレクトリにあるmcp-nih-reporter.logに書き込まれます。ログレベルはデフォルトでINFOに設定されています。
貢献を歓迎します！お気軽にプルリクエストを送信してください。大きな変更については、まず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