Skip to main content
Glama

foundation-discovery

by io.github.Kindora-PBC

Get Foundation Grants

get_foundation_grants
Read-only

View grants made by a funder across IRS, web-extracted, and registry records.

Merges five stores. (1) IRS 990-PF filings — structured grant lines from the ~143K US private foundations that file 990s, keyed by EIN. (2) Web-extracted grant records — our enrichment pipeline crawls funder websites and an LLM extracts their grant lists. This second store covers ~15K additional US foundations AND ~17K non-990 funders (European foundations, US community foundations, DAFs, corporate giving programs). (3) 360Giving UK GrantNav rows, (4) CRA T3010 Canadian rows, and (5) ACRI Italian banking-foundation erogazioni are structured registry sources with original-currency amounts preserved.

Use this for ANY funder when the user asks about grants given, including European funders without an EIN (pass funder_id instead of ein). Each row in the response carries a source field ("990" for IRS data, "discovered_web" for crawled, plus "360giving", "t3010", and "acri" for structured registries). When web-extracted rows for a funder lack captured amounts (common for European funders that publish PDFs rather than open data), the response includes an amount_coverage_note in data_quality — surface that caveat in your reply.

Note: recipient_country reflects the recipient organization's HQ country (where the grantee is registered), not necessarily where the program work is implemented.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
einNoFoundation EIN (9 digits, hyphens OK). Required for US 990 path. Optional if ``funder_id`` is supplied for a non-990 funder.
yearNoOptional year to filter by (filing_year for 990, grant_year for discovered). If not provided, returns all available years.
limitNoMaximum number of grants to return (1-50)
funder_idNoOptional non-990 funder id. Accepts a bare UUID or prefixed id like ``n9f:<uuid>`` / ``non990:<uuid>``. Use this for European funders, US community foundations, DAFs, and other funders that don't file IRS 990-PF. You can get it from search_funders or get_funder_profile.
ntee_codeNoOptional NTEE code to filter recipient organizations. Example: "B41" (Higher Education), "E" (Health). Use get_ntee_codes to browse available codes.
purpose_keywordNoOptional case-insensitive substring to match against the grant_purpose field. Useful for narrowing to a topic when recipient NTEE code is too coarse — e.g., purpose_keyword="vaccine" surfaces Gates grants whose purpose text mentions vaccines, even when the recipient is classified outside health (universities, think tanks, etc.).
recipient_stateNoOptional 2-letter US state code to filter by recipient state (e.g., "CA", "NY").
recipient_countryNoOptional recipient country filter. Use ISO 3166-1 alpha-2 codes (e.g., "CH" Switzerland, "ZA" South Africa, "NG" Nigeria, "IN" India). A code that is valid ISO is always read as ISO ("NG" is Nigeria, never Niger; "SN" is Senegal, never Singapore); legacy FIPS 10-4 codes match only when they are not ISO codes at all ("UK", "SF"). Output codes are emitted in ISO 3166.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior5/5

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

Even with readOnlyHint=true and destructiveHint=false already covering safety, the description adds significant behavioral context: it merges five distinct stores, each row includes a source field with concrete values, web-extracted records may carry an amount_coverage_note that must be surfaced, original-currency amounts are preserved, and recipient_country reflects the grantee's HQ country rather than implementation location. No annotation contradiction.

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 the tool is genuinely complex and nearly every paragraph earns its place: source enumeration, the data-quality caveat, and the country semantics note are all decision-relevant. It is front-loaded with purpose and scoping, though the detailed store-by-store statistics could be tightened without losing much.

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?

For an 8-parameter tool with five merged data sources, the description covers what the tool returns, how to select the right funder identity, what source field values to expect, and an important data-quality caveat to surface. With annotations covering safety and an output schema present, nothing critical is missing.

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?

The schema has 100% description coverage, so the baseline is 3 and the description does not need to repeat parameter mechanics. It adds value by explicitly instructing the agent to pass funder_id instead of ein for non-990 funders and by clarifying the semantic of recipient_country beyond the schema's ISO-code guidance. This is enough to raise it slightly above baseline.

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 first sentence clearly states the action ('View grants made by a funder') and the resource scope ('IRS, web-extracted, and registry records'). It goes beyond the title by specifying exactly which kinds of funders and sources are covered, and the 'ANY funder' phrasing helps distinguish it from opportunity-oriented tools like search_open_grants.

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?

The description gives an explicit directive: use this for ANY funder when the user asks about grants given, including non-EIN European funders, and it tells the agent to pass funder_id instead of ein. It does not explicitly name a sibling alternative or state when not to use the tool, though the 'grants made by a funder' framing implies the boundary.

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

All foundation-discovery toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool serves a distinct purpose: find_funders_for_peers uses peer-based collaborative filtering, search_funders does name/topic lookup, search_open_grants finds active RFPs, search_nonprofits searches recipients, get_funder_* tools provide different aspects of funder data, and utilities like health_check and list_tools are separate. No overlap.

Naming Consistency3/5

Naming conventions are mixed: 'find_', 'get_', 'search_', 'health_check', 'list_tools', 'get_ntee_codes'. While verbs are descriptive, there is no single consistent pattern (e.g., all search_ or all get_). This could cause slight confusion.

Tool Count5/5

12 tools is well-scoped for a foundation discovery server. Each tool addresses a clear need (prospecting, detail, financials, jobs, utilities) without being excessive or insufficient.

Completeness5/5

The tool set covers the full lifecycle of foundation research: finding funders (by peers, name, open grants), getting detailed profiles, grants, stats, financials, NTEE codes, and even funder jobs. The inclusion of recipient-side search (search_nonprofits) complements the funder side, leaving no obvious gaps.

Resources