opennih

Search OpenNIH NIH grants

search_grants

Read-onlyIdempotent

Use this tool when the user asks to find NIH grants — by topic, principal investigator, institution, NIH Institute/Center, activity code, fiscal year, or project number ('what NIH grants exist on CRISPR', 'show me Stanford's R01s in 2022', 'look up 5R01CA036569-02'). This is the primary entry point: results carry pi_profile_id, the NIH RePORTER PI identifier. Read-only bounded search over the entity-resolved NIH ExPORTER/RePORTER corpus; results include mechanism_class, funding_basis and provenance, and a null award_amount means not reported, never zero. pi_name matches either name order ('Michael Platt' = 'PLATT, MICHAEL'; corpus form is LAST, FIRST). Bounds: query/text_search/institution/pi_name 2-64 chars, project_num ^[A-Z0-9-]{1,24}$, activity_code ^[A-Z0-9]{1,5}$, fiscal years 1985-2100, limit 1-50 (default 20), offset 0-100000 (offset>10000 is rate-limited to 12/min — partition by fiscal_year instead). meta.total_funding is the full matching-slice sum, not the returned page. Results are cached for ~1 hour. Counting: one result is one source application-year row, so (project_num, fiscal_year) is NOT unique - a multi-component award (P/U center) emits one row per sub-project, so the same project_num can appear several times in one fiscal year with different PIs and titles. These are distinct NIH application records, not duplicates. Each row carries appl_id, the NIH application id and authoritative row identity - two rows sharing (project_num, fiscal_year) with different appl_id are distinct sub-project applications, and appl_id is the key to de-duplicate on. meta.total counts rows, not grants; meta.unique_project_nums counts distinct project numbers, and meta.distinct_awards (row field core_project_num) counts distinct awards.

Input Schema

Name	Required	Description
`ic`	No
`limit`	No
`query`	No
`offset`	No
`pi_name`	No	PI name in either order: 'Michael Platt' or the corpus form 'PLATT, MICHAEL' both match; a surname alone ('Platt') matches every PI with that surname.
`institution`	No
`project_num`	No
`text_search`	No
`activity_code`	No
`fiscal_year_end`	No
`fiscal_year_start`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / pi_name / description

Added value: +"PI name in either order: 'Michael Platt' or the corpus form 'PLATT, MICHAEL' both match; a surname alone ('Platt') matches every PI with that surname."

First observedOct 13, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavior beyond the annotations: caching for about one hour, offset rate limiting above 10,000, null award_amount semantics, PI name matching order, and row-level counting rules. It also explains that multi-component awards emit multiple application-year rows and identifies appl_id as the authoritative row identity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loads the intended use cases and key examples before moving into operational details. Most sentences carry useful constraints or caveats, though the counting and deduplication explanation is dense enough to feel somewhat overloaded.

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?

For a complex 11-parameter search tool with very low schema description coverage, the description covers most critical invocation behavior, including bounds, caching, rate limits, and row-counting semantics. The remaining gap is partial explanation of some parameter distinctions and matching rules, though the output schema exists and reduces the need to explain return fields.

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 description coverage is only 9%, so the description must compensate, and it does for many parameters by giving length bounds, regex constraints, fiscal-year range, limit/offset ranges, and PI name matching behavior. It leaves some ambiguity around ic, query vs text_search, and institution matching semantics, so it is strong but not complete.

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?

The description states a specific verb and resource: search NIH grants by topic, PI, institution, IC, activity code, fiscal year, or project number. It explicitly positions this as the primary entry point and differentiates it from analytics-style siblings by describing row-level grant search behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete user-intent examples such as finding grants on CRISPR, Stanford R01s in 2022, or looking up a specific project number. It clearly states when to use the tool, but does not explicitly compare against siblings like fetch, search, or get_pi_profile for adjacent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All opennih tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?