opennih

Get NIH PI profile

get_pi_profile

Read-onlyIdempotent

Use this tool when the user asks about one researcher — 'how much NIH funding does Dr. X have', 'list this PI's grants', 'who does she collaborate with'. profile_id is the NIH RePORTER PI identifier carried in grant-search results' pi_profile_id field and is not guessable. Read-only PI profile: grants, collaborators, publications, funding totals; the headline name/institution follow the PI's LATEST grant. A fiscal-year window with no grants returns the profile with total_grants=0, not an error. COUNT SEMANTICS (#762): profile.grant_count counts project-year rows (one per fiscal year a grant was funded), while profile.active_grants counts DISTINCT active awards — core project numbers — whose rows are active, so a continuing award counted across several fiscal years in grant_count counts ONCE in active_grants. fiscal_year_start/fiscal_year_end scope EVERY aggregate section — grants, profile totals AND collaborators all report only that window (issue #342; collaborators previously ignored it and returned the all-time list). COLLABORATOR COVERAGE: the collaborator sidecar covers only SOME fiscal years, so an empty collaborators list can mean 'unknown for these years' rather than 'none'. meta.collaborator_coverage.window_covered distinguishes the two: false = no data for any year in the window, and true with window_fully_covered=false means PARTIAL coverage, with the uncovered years listed in missing_fiscal_years_in_window. fiscal_years_with_collaborator_data lists the years that do have it. PI ROLE (#761): each grant carries pi_role — contact (this person is the row's contact PI) or co_investigator (matched via the corpus multi-PI list, so awards someone else leads still count toward totals); meta.multi_pi_ids_loaded=false means the corpus predates that list and only contact-PI rows can match, and meta.present_only_as_non_contact_pi=true means the id is never a contact PI anywhere (headline name/institution are then empty). SUBPROJECT ROWS (#761): award_amount NULL with subproject_component=true marks a component row of a multi-project award whose dollars are carried by another row of the same project and fiscal year — subproject_note names that amount; NULL WITHOUT the flag means not reported. Bounds: profile_id 1-20 digits (^[0-9]{1,20}$), fiscal years 1985-2100, limit 1-50 (default 20), offset 0-100000.

Input Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`profile_id`	Yes
`fiscal_year_end`	No
`fiscal_year_start`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavioral context beyond them: count semantics for grant_count vs active_grants, collaborator coverage gaps, PI-role matching limits, and subproject NULL meaning. Slightly reduced only because it leans heavily on issue-numbered jargon that an agent must decode.

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?

Front-loaded with the usage trigger, then organized into clearly labeled sections (COUNT SEMANTICS, COLLABORATOR COVERAGE, PI ROLE, SUBPROJECT ROWS, Bounds), so it stays navigable despite its length. Some density comes from issue references (#762, #761, #342) that add noise rather than actionable guidance.

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?

Given an output schema exists and safety is covered by annotations, the description supplies the semantic caveats needed to interpret results: aggregate scoping, collaborator coverage flags, PI-role flags, and subproject NULL handling. Only minor gaps remain, such as explaining what limit/offset paginate over.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates fully: profile_id is explained as the NIH RePORTER identifier carried in pi_profile_id, not guessable, with a digit regex; fiscal year parameters are shown to scope every aggregate section; and limit/offset bounds and defaults are stated.

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?

States a concrete verb+resource ('Read-only PI profile: grants, collaborators, publications, funding totals') and immediately conveys the object is one researcher, with distinguishing detail that the headline name/institution follow the latest grant. An agent can distinguish it from institution-level siblings like get_institution_profile.

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?

Opens with an explicit trigger ('when the user asks about one researcher') plus example utterances, explains where profile_id comes from, and clarifies that an empty fiscal-year window is not an error. It does not explicitly name a competing sibling tool to route away from, so it falls short of a full when/when-not/alternatives statement.

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?