Search open and upcoming US federal grant opportunities on Grants.gov and get full grant details.
Scored across 3 tools
The three tools have clearly distinct roles: search_grants discovers opportunities, list_grant_filters maps user language to valid filter codes, and get_grant_details retrieves one record. Descriptions explicitly cross-reference each other, so an agent can tell exactly which to pick.
All three names follow a consistent verb_noun pattern (search_grants, list_grant_filters, get_grant_details) with snake_case throughout. No deviations or mixed conventions.
Three tools is lean for a read-only Grants.gov search server but each earns its place and the discovery-to-detail workflow is covered end to end. Slightly thin, but not artificially fragmented.
The surface covers the core read-only lifecycle: filter vocabulary, search, and full detail retrieval, including eligibility, dates and award ranges. Minor gaps exist (no pagination/result-window control beyond the 30-match limit, no saved-search or export), but agents can work around them.
Get the full Grants.gov record for one federal grant opportunity by its numeric opportunity ID (from search_grants), its funding opportunity number, or its Grants.gov URL. Returns the description, eligibility text, eligible applicant types, award floor and ceiling, total funding, expected number of awards, cost-sharing, open and close dates (or forecast dates), agency contact, assistance listing numbers and how to apply. Use when the user asks about a specific grant, whether they qualify, or how to apply. Descriptions are clipped; the full announcement on Grants.gov is authoritative.
| Name | Required | Description | Default |
|---|---|---|---|
| opportunity | Yes | Numeric Grants.gov opportunity ID (e.g. '363998'), funding opportunity number (e.g. 'OST-OSDBU-2027-SBTTAC-REGION3-FY2027-1') or a grants.gov/search-results-detail URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description still adds real behavioral context beyond them: descriptions are clipped and the full Grants.gov announcement is authoritative, which tells the agent the returned text may be truncated and not to treat it as final.
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 purpose and input forms are front-loaded in the first sentence, and the usage trigger follows in the third. The middle enumeration of return fields is long, but with no output schema it is load-bearing rather than padding; only mild tightening is possible.
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?
With no output schema, the description compensates by enumerating the returned fields (eligibility, award floor/ceiling, dates, contacts, assistance listings, how to apply), and it flags the clipping caveat. An agent has everything needed to choose and call it correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by tying the accepted input forms to their provenance ('numeric opportunity ID (from search_grants)'), which helps the agent know where to obtain a valid value rather than just what shape it takes.
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?
States a specific verb and resource ('Get the full Grants.gov record for one federal grant opportunity') and explicitly scopes it to a single opportunity. It also distinguishes itself from search_grants by naming it as the source of the ID, so an agent can route between lookup and search without opening either schema.
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?
Gives clear usage triggers ('Use when the user asks about a specific grant, whether they qualify, or how to apply') and points to the sibling search_grants as the origin of the identifier. It does not state an explicit when-not or a rule for what to do if the ID is ambiguous, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the valid values for search_grants filters: applicant eligibility types and funding categories (with Grants.gov codes and how many open or forecasted grants each has right now) and federal agencies with their codes. Pass an agency code to also list its sub-agencies. Use to map a user's description of their organization, topic or preferred agency onto valid filter values before searching.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | No | Optional top-level agency code (e.g. 'HHS', 'USDA') to list its sub-agencies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower. The description adds real value beyond that: it discloses the returned entity types, their identifier codes, and that counts reflect open or forecasted grants 'right now' (i.e., time-sensitive/volatile data). No auth or rate-limit details, but the return characterization is solid.
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?
Two sentences, front-loaded with what gets listed and followed by the application guidance. Efficient, though the first sentence is dense enough that the parenthetical about codes and counts takes a moment to parse.
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?
With no output schema, the description must convey return content, and it does: entity types, their codes, per-category counts, and the conditional sub-agency listing. Combined with annotations covering safety and the fully documented single parameter, an agent has everything needed to invoke it correctly.
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?
Schema coverage is 100% and the description's 'Pass an agency code to also list its sub-agencies' largely restates what the schema field already documents (the 'agency' property with example codes). Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no new syntax or constraints.
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?
States a specific verb and resource ('List the valid values for search_grants filters') and enumerates exactly what is returned: eligibility types, funding categories with Grants.gov codes and counts, and federal agencies with codes. This clearly distinguishes it from search_grants, which performs the actual search, and get_grant_details.
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?
Explicitly prescribes when to use it: 'Use to map a user's description of their organization, topic or preferred agency onto valid filter values before searching.' This gives a concrete sequencing rule relative to the search sibling rather than leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open (posted) or upcoming (forecasted) US federal grant opportunities on Grants.gov by keyword, applicant eligibility type, funding category and agency. Returns each grant's title, opportunity number, agency, open and close dates, award floor and ceiling, eligible applicant types and Grants.gov link, sorted by soonest close date by default (among the 30 best keyword matches when a keyword is given). Use when the user wants to find federal grants for an organization, project or topic. Covers federal grants listed on Grants.gov only, not state, local, foundation or corporate grants. Eligibility filtering uses Grants.gov's applicant-type codes; always confirm eligibility with get_grant_details or the full announcement.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 'closing_soon' = soonest deadline first among the best keyword matches (default); 'relevance' = best keyword match first; 'newest' = most recently posted first. | closing_soon |
| limit | No | How many grants to return (1-15). | |
| agency | No | Agency code from list_grant_filters, e.g. 'HHS', 'USDA', 'NSF', or a sub-agency code like 'HHS-NIH11'. A top-level code includes all its sub-agencies. | |
| status | No | 'posted' = accepting applications now (default); 'forecasted' = announced as coming but not yet open. | posted |
| keyword | No | Topic words to match, e.g. 'rural broadband', 'youth mental health', 'women entrepreneurs'. Leave empty to browse by filters only. | |
| category | No | Funding categories to filter by, e.g. ['health'] or ['agriculture','energy']. | |
| eligibility | No | Applicant types to filter by, e.g. ['nonprofit_501c3'] or ['small_business']. Grants matching ANY listed type are returned. | |
| include_unrestricted | No | When filtering by eligibility, also include grants marked 'unrestricted' (open to any entity type). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, open-world profile, so the bar is lower; the description still adds real behavior: the returned field set, the default sort, and the non-obvious cap of '30 best keyword matches when a keyword is given'. It omits rate limits and pagination behavior, keeping it short of a 5.
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?
Three tightly packed sentences, front-loaded with purpose and scope before return details and caveats. Dense but nearly every clause carries new information; slightly long, which keeps it from a 5.
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?
No output schema exists, and the description compensates by enumerating returned fields (title, opportunity number, agency, dates, award floor/ceiling, eligibility types, link) and the default ordering. For a read-only, zero-required-parameter search tool this is sufficient to call correctly.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema with the hidden 30-match keyword cap, the default sort rationale, and the warning that eligibility codes must be confirmed against full announcements.
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?
States a specific verb and resource ('Search ... US federal grant opportunities on Grants.gov') plus the dimensions searched (keyword, eligibility, category, agency) and the source scope. It is clearly distinguishable from get_grant_details (single-grant lookup) and list_grant_filters (filter enumeration).
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?
Explicit when-to-use ('when the user wants to find federal grants for an organization, project or topic'), explicit when-not ('not state, local, foundation or corporate grants'), and it routes to an alternative ('always confirm eligibility with get_grant_details'). The schema additionally points to list_grant_filters for agency codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_grant_detailslist_grant_filterssearch_grantsSearch US grants + federal contracts (Grants.gov + SAM.gov) from any LLM.
Grants.gov search and USAspending grant data. 4 MCP tools for grant discovery.
Grants.gov MCP — open federal grant opportunities (free, no auth)
Search verified-open US grants (federal, state, foundation). Read-only MCP for AI agents.
Add one secure layer between your agents and this server.
