Un servidor de Protocolo de Contexto Modelo (MCP) para chatear con NIH RePORTER . Busque proyectos de investigación y publicaciones financiados por los NIH de forma conversacional. Entrada de blog complementaria aquí .
Busque proyectos de investigación financiados por el NIH con varios criterios:
Años fiscales
Nombres de los investigadores principales
Detalles de la organización (nombre, estado, ciudad, tipo, departamento)
Montos de financiación
Estado de la respuesta al COVID-19
Mecanismo de financiación
Códigos de instituto/centro
Términos del RCDC
Rangos de fechas
Buscar publicaciones asociadas con proyectos del NIH
Funcionalidad de búsqueda combinada para proyectos y publicaciones
Información detallada del proyecto y la publicación, incluidos resúmenes.
Límites de resultados configurables
Related MCP server: MedAdapt Content Server
Python 3.12 o superior
Administrador de paquetes UV (recomendado para una instalación más rápida de dependencias)
Clonar el repositorio:
git clone <repository-url>
cd mcp-nih-reporterCrear y activar un entorno virtual:
python -m venv .venv
source .venv/bin/activate # On Windows, use `.venv\Scripts\activate`Instalar dependencias usando UV:
uv pip install -e .Este servidor MCP proporciona acceso a la API NIH RePORTER a través de varias herramientas:
search_projects : Busque proyectos de investigación financiados por los NIH
search_publications : busca publicaciones asociadas con proyectos del NIH
search_combined : Búsqueda combinada de proyectos y publicaciones
test_connection : prueba la conexión API
Puede utilizar este MCP con cualquier cliente compatible con MCP, como:
Escritorio de Claude
Cursor
Otras herramientas habilitadas para 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"
]
}
}
}Los resultados de la búsqueda se devolverán en un formato estructurado que contiene detalles del proyecto, incluidos:
Título y resumen del proyecto
Información del investigador principal
Detalles de la organización
Información de financiación
Fechas y estado del proyecto
Se creará un archivo de registro en la carpeta raíz cuando el MCP intente ejecutarse en un cliente (por ejemplo, Claude Desktop). Consulte allí si tiene problemas.
El proyecto utiliza:
httpx para solicitudes HTTP asíncronas
mcp para la implementación del Protocolo de Control de Misión
python-dotenv para la gestión de variables de entorno
uv para la gestión de dependencias
Los registros se escriben en mcp-nih-reporter.log en el directorio raíz del proyecto. El nivel de registro predeterminado es INFO.
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios. Para cambios importantes, primero abra una incidencia para comentar qué desea cambiar.
Bifurcar el repositorio
Crea tu rama de funciones ( git checkout -b feature/amazing-feature )
Confirme sus cambios ( git commit -m 'Add some amazing feature' )
Empujar a la rama ( git push origin feature/amazing-feature )
Abrir una solicitud de extracción
Asegúrese de actualizar las pruebas según corresponda y seguir el estilo del código existente.
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
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