Skip to main content
Glama

Search Grants & Foundations

search_grantsplus
Read-onlyIdempotent

GRANTS & FOUNDATIONS — Search grants, prizes, fellowships, SBIR/STTR, and private foundations. Excludes procurement/contracts for clean results. Use when user wants: funding, grants, fellowships, research money, SBIR, foundation grants. Also returns matching private foundations automatically. Examples: "cancer research funding", "clean energy small business grants", "HVAC grants in Arizona". BATCH MODE (paid): pass a queries[] array of 2-5 variations instead of query to run them in parallel, dedupe, and return all unique results in one call — this replaces the former batch_search_grantsplus tool. Paid plans show new listings the day they open; the free plan reaches the same listings after 10 days. Counts toward your monthly searches. A batch counts as 1 call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results (default: 25)
queryNoNatural language search query. Provide either query (single search) or queries (batch mode) — exactly one.
sinceNoStateless alternative to posted_within_days/new_within_days: ISO 8601 instant. Only opportunities ingested at/after this instant. Store the previous response newSince.newest and pass it here to manage your own watermark.
cursorNoPagination cursor from previous response
offsetNoBatch mode only: number of merged results to skip for pagination (default 0). Ignored in single-query mode.
sourceNoFilter to a specific source/domain, e.g. "grants.gov", "deq.nc.gov", or "sam.gov".
statusNoFilter by status
compactNoReturn compact results (default: true). Set to false for full details.
queriesNoBATCH MODE (paid, replaces batch_search_grantsplus): array of 2-5 search queries to run in parallel, dedupe, and merge. Example for clean energy: ["renewable energy grants", "solar wind funding", "clean energy nonprofit", "sustainability grants", "green technology funding"]. When set, query is ignored and the batch response params (detail_level, max_results, offset, max_response_tokens) apply.
max_resultsNoBatch mode only: maximum merged results to return (default 10). Ignored in single-query mode (use limit).
min_qualityNoMinimum quality threshold (default: medium)
detail_levelNoBatch mode only: controls response verbosity (minimal/compact [default]/full). Ignored in single-query mode.
organizationNoFilter by funding organization
user_contextNoUser context for better filtering
grants_filtersNoGrants.gov specific filters
new_within_daysNoBackwards-compatible alias for posted_within_days. Only opportunities WE ADDED (ingested) in the last N days for recurring/delta checks ("what is new since my last check"). Additive to all other filters. In queryless browse mode without a single source, the recency window is sampled across sources round-robin by ingest recency so one bulk harvester cannot own the digest; each source remains newest first. The response includes newSince and windowCoverage: sourcesSampled counts distinct sources returned by the grouped provider query before MCP quality, judge, recency-withhold, and page filters; it is absent when no grouped sample was available, including when sampling was not attempted, and 0 means the grouped query succeeded but returned no sourced rows; sourcesServed counts distinct sources delivered on this page. windowCoverage.order is "recency" for the queryless browse digest or "relevance" when a query is present. windowIncomplete/incompleteReason is separate from ceilingTruncated, which is true only when the 2,000-row ceiling excluded records; ceilingTruncated and hardCeiling are present only when order is "recency" and are omitted entirely under "relevance" (query mode never walks past a single bounded fetch, so no ceiling logic runs). Not the opportunity posted date or deadline.
posted_within_daysNoPreferred alias for new_within_days: only opportunities WE ADDED (ingested) in the last N days. In queryless browse mode without a single source, the recency window is sampled across sources round-robin by ingest recency so one bulk harvester cannot own the digest; each source remains newest first. In windowCoverage, sourcesSampled counts distinct sources returned by the grouped provider query before MCP quality, judge, recency-withhold, and page filters; it is absent when no grouped sample was available, including when sampling was not attempted, and 0 means the grouped query succeeded but returned no sourced rows; sourcesServed counts distinct sources delivered on this page. windowCoverage.order is "recency" for the queryless browse digest or "relevance" when a query is present. windowIncomplete/incompleteReason is separate from ceilingTruncated, which is true only when the 2,000-row ceiling excluded records; ceilingTruncated and hardCeiling are present only when order is "recency" and are omitted entirely under "relevance" (query mode never walks past a single bounded fetch, so no ceiling logic runs). Uses the same ingest freshness field as newSince/recurring checks; not the opportunity posted date or deadline. If both posted_within_days and new_within_days are supplied, posted_within_days wins.
include_foundationsNoAlso search private foundations matching the query (default: true). Returns foundations that have historically funded similar work.
max_response_tokensNoBatch mode only: token budget for the response (default 4000). Server auto-caps results to fit. Ignored in single-query mode.
deadline_within_daysNoOnly opportunities closing within N days

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this read-only/idempotent, and the description adds substantial operational behavior: it dedupes merged batch results, returns matching private foundations automatically, reveals paid vs. free freshness delays, and explains that a batch counts as one monthly search. No contradiction with annotations.

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 a dense, well-ordered paragraph with the purpose front-loaded, followed by examples and the batch/plan details. Each sentence earns its place, and none of the schema detail is needlessly repeated.

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 20-parameter tool with no output schema, the description covers selection criteria, batch mode, exclusions, and plan limitations. It does not explain queryless browse or all filtering options, but the 100% schema coverage fills those gaps, making the overall context sufficient.

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%, so the baseline is 3. The description adds examples and clarifies that queries[] replaces the old batch_search_grantsplus tool, but it does not add meaning for the many other parameters (limit, since, cursor, status, user_context, grants_filters, etc.) beyond what the schema already provides.

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 starts with a clear verb+resource: 'Search grants, prizes, fellowships, SBIR/STTR, and private foundations.' It explicitly excludes procurement/contracts, which immediately differentiates it from sibling tools like search_procurement and search_grants_and_procurement.

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?

'Use when user wants: funding, grants, fellowships, research money, SBIR, foundation grants' gives an explicit trigger list, and the exclusion of procurement supplies a when-not signal. However, it does not name the alternative tools (e.g., search_procurement) for procurement-only requests.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clear distinct purposes. Some overlap exists (e.g., search_grantsplus and search_foundations both return foundations, but descriptions clarify the distinction). Also batch_ variants are comprehensive versions of the standard searches. Overall, agents can differentiate well.

Naming Consistency4/5

Tool names predominantly follow verb_noun pattern in snake_case (e.g., search_grantsplus, get_opportunity, list_saved_searches). Minor deviation with 'whats_new' (no underscore) and 'check_connection' (different verb form). Otherwise consistent.

Tool Count4/5

26 tools is slightly above the typical 3-15 range but still reasonable for a comprehensive funding landscape server covering grants, procurement, foundations, saved searches, account management, and utilities. Each tool serves a clear purpose.

Completeness4/5

The tool surface covers core search, detail retrieval, saved search management, account information, and feedback. Missing are profile management or direct payment modification tools (only links provided). Minor gaps but overall complete for the domain.

Resources