Nih Reporter

Search Grants

search_grants

Read-onlyIdempotent

Search NIH-funded research projects. Filter by free-text query (topic/subject matter — matches title/abstract/terms, NOT the awardee), PI name, organization (the funded company/university/institution — use THIS, not query, for "what grants has <company/university> received"), fiscal year, US state, or NIH institute code (NCI, NHLBI, NIAID, etc.). Returns project number, PI, institution, fiscal year, award amount, and abstract preview.

Input Schema

TableJSON Schema

Name	Required	Description
`ic`	No	NIH Institute/Center code (e.g., "NCI", "NHLBI", "NIMH")
`limit`	No	Results per page (1-500, default 25)
`query`	No	Free-text search over project title/abstract/terms — an AND match on the SUBJECT MATTER words you pass (e.g. "cancer immunotherapy"), not a lookup by funding recipient. Do NOT put a company, institution, or organization name here: the name rarely appears verbatim in grant text, so it instead AND-matches on the name's individual common words and can return thousands of unrelated grants. For "what NIH grants has <company/university/institution> received", use `organization` instead.
`state`	No	US state code (e.g., "CA")
`offset`	No	Pagination offset (default 0)
`pi_name`	No	PI last name (or any name part)
`fiscal_year`	No	Fiscal year (e.g., 2024)
`organization`	No	The funded organization — the company, university, hospital, or institution that RECEIVED the award (e.g., "Stanford University"). This is the correct filter whenever the question names a specific organization/company/institution as the funding recipient — use it INSTEAD of `query`, which searches grant CONTENT, not the awardee.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	Total number of matching grants
`grants`	Yes	Array of grant records
`returned`	Yes	Number of grants returned in this response

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 26, 2026

changedInput schema / properties / organization / description

Previous value: -"Institution name (e.g., \"Stanford University\")"New value: +"The funded organization — the company, university, hospital, or institution that RECEIVED the award (e.g., \"Stanford University\"). This is the correct filter whenever the question names a specific organization/company/institution as the funding recipient — use it INSTEAD of `query`, which searches grant CONTENT, not the awardee."

changedInput schema / properties / query / description

Previous value: -"Free-text search across title, abstract, terms"New value: +"Free-text search over project title/abstract/terms — an AND match on the SUBJECT MATTER words you pass (e.g. \"cancer immunotherapy\"), not a lookup by funding recipient. Do NOT put a company, institution, or organization name here: the name rarely appears verbatim in grant text, so it instead AND-matches on the name's individual common words and can return thousands of unrelated grants. For \"what NIH grants has <company/university/institution> received\", use `organization` instead."

Changed2 schema fields changedMay 22, 2026

addedInput schema / examples

Added value: +[
+  {
+    "fiscal_year": 2024,
+    "ic": "NCI",
+    "limit": 25,
+    "query": "cancer immunotherapy"
+  },
+  {
+    "limit": 50,
+    "organization": "Stanford University",
+    "pi_name": "Smith",
+    "state": "CA"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "grants": {
+      "description": "Array of grant records",
+      "items": {
+        "properties": {
+          "appl_id": {
+            "description": "NIH application ID",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "award_amount": {
+            "description": "Total award amount in dollars",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "award_notice_date": {
+            "description": "Award notice date",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "contact_pi": {
+            "description": "Contact principal investigator name",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "core_project_num": {
+            "description": "Core project number",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "fiscal_year": {
+            "description": "Fiscal year of award",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "nih_institute": {
+            "description": "NIH Institute/Center abbreviation or code",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "nih_institute_name": {
+            "description": "Full name of NIH Institute/Center",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "org_city": {
+            "description": "Organization city",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "org_country": {
+            "description": "Organization country",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "org_state": {
+            "description": "Organization state code",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "organization": {
+            "description": "Organization/institution name",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "pis": {
+            "description": "List of principal investigator names",
+            "items": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "type": "array"
+          },
+          "project_end": {
+            "description": "Project end date",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "project_num": {
+            "description": "Project number",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "project_start": {
+            "description": "Project start date",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "reporter_url": {
+            "description": "Direct link to project on NIH Reporter",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "terms_preview": {
+            "description": "Preferred terms/keywords preview",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "description": "Project title",
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "returned": {
+      "description": "Number of grants returned in this response",
+      "type": "number"
+    },
+    "total": {
+      "description": "Total number of matching grants",
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "returned",
+    "grants"
+  ],
+  "type": "object"
+}

First observedMay 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that by clarifying that `query` matches title/abstract/terms rather than the awardee, and by specifying the returned fields such as project number, PI, institution, fiscal year, award amount, and abstract preview.

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

Conciseness5/5

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

The description is three sentences with no filler: it front-loads the purpose, lists the key filters, and closes with the return fields. Every sentence earns its place, and the critical query-versus-organization clarification is integrated naturally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, detailed annotations, and presence of an output schema, the description is complete enough for correct invocation. It covers the main filter dimensions, the key semantic trap around `query`, and the expected return content, leaving no critical gap for an agent deciding how to call the tool.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already provides rich explanations for `query` and `organization`, including the critical distinction between subject-matter search and recipient lookup. The description condenses this guidance but does not add meaning beyond what the schema already documents, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches NIH-funded research projects and enumerates the available filters and return fields. It is specific about the resource and verb, but it does not explicitly differentiate itself from sibling NIH tools such as nih_new_grant_awards or nih_grant_award_history.

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

Usage Guidelines3/5

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

The description gives strong within-tool guidance, especially the instruction to use `organization` instead of `query` for recipient lookups. However, it does not state when to prefer this tool over sibling alternatives or mention any exclusions, so the agent must infer usage context from the sibling list.

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

All Nih Reporter 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.