foundation-discovery

Server Details

Foundation discovery and grant intelligence for nonprofits. 174K+ US funders, IRS 990 data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 57 days
Last Tested: 2026-10-13 23:06
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-06 07:30 across 13 tools

Disambiguation4/5

The prospecting/lookup tools are well-separated and the descriptions actively contrast them (find_funders_for_peers vs find_funders_of_nonprofit, search_funders vs search_open_grants vs search_nonprofits). The weaker spot is the four funder-detail tools (get_990_summary, get_funder_profile, get_funder_stats, get_foundation_grants), which all describe overlapping financial/granting data for the same entity and could cause misselection.

Naming Consistency5/5

Nearly all tools follow a clean verb_noun snake_case pattern: find_*, get_*, search_*, list_*. The verb choice (find vs get vs search) even maps to semantic intent (prospect vs detail vs lookup), and the only near-outlier, health_check, is a widely recognized convention.

Tool Count4/5

13 tools is within the healthy 3-15 band and each core tool earns its place across search, funder-detail, prospecting, and jobs. Two slots are meta/utility (health_check, list_tools), which is slightly padding but not bloating.

Completeness4/5

The surface broadly covers the domain: funder search, recipient search, open-grant search, funder profile/stats/990/grants, peer-based prospecting, NTEE reference, and jobs. Minor gaps remain (e.g. no direct detail-by-id for a grant opportunity and no watchlist/save workflow), but core discovery and prospecting workflows are covered.

Available Tools

13 tools

find_funders_for_peersFind Funders for Peer OrgsA

Read-only

Inspect

Find grantmakers that have ACTUALLY funded organizations LIKE the caller's, using the real 7.5M-edge who-funds-whom grant graph (IRS 990-PF, 2022-2026). This is the strongest free-tier prospecting move: collaborative-filtering peer prospecting, distinct from search_funders (name/topic lookup) and search_open_grants (active RFPs).

HOW IT WORKS: for each peer organization, it looks up every foundation that granted to that peer, then merges funders across peers. A funder that gave to several of your peers ranks highest. Every result carries real grant evidence — which peers the funder funded and for how much.

INPUTS (provide one):

peer_orgs (PREFERRED): names or 9-digit EINs of organizations LIKE the one you're raising for — peers, aspirational orgs, or orgs with a similar mission. The graph is keyed by recipient EIN, so naming real peers yields the sharpest evidence. Up to 12 are used.
org_description: a SHORT CAUSE PHRASE, not a paragraph — "food bank", "mental health", "affordable housing". Fallback for when you cannot name peers: it matches the phrase against IRS BMF organization NAMES and, if that finds nothing, against the NTEE cause taxonomy, then uses the best-funded organizations in that cause (biased to location). It does NOT search mission text, so a LONGER description matches FEWER orgs, not more — keep it to the cause, and prefer peer_orgs. The response reports which pass produced the peers in peer_discovery.

RECOMMENDED WORKFLOW: establish the org's mission/cause, then name 2-5 peer organizations and call this tool. Deepen any candidate with get_funder_profile / get_foundation_grants (pass the returned ein).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of funders to return (1-50)
`location`	No	Optional 2-letter state or "City, ST". Only biases peer discovery under org_description; never filters funders.
`peer_orgs`	No	Names or EINs of peer / aspirational organizations. Example: ["Greater Chicago Food Depository", "Feeding America"].
`min_amount`	No	Minimum single-grant size in USD (default 5000)
`org_description`	No	Short cause phrase for the nonprofit (fallback). Example: "youth mental health". Adding words narrows the match.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: the 7.5M-edge graph, 2022-2026 IRS data, how funders are merged across peers, that results carry grant evidence, that location only biases peer discovery and never filters funders, and that longer org descriptions match fewer orgs. This is unusually transparent.

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 longer than average but earnestly structured with bold section labels and front-loaded purpose. Each section adds operational value; only minor marketing-style phrasing like 'strongest free-tier prospecting move' is non-essential. Overall it is dense but well-organized.

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 a tool with 5 optional parameters, a fallback matching algorithm, and sibling alternatives, the description is complete: it covers inputs, behavior, edge cases, recommended workflow, and downstream follow-up tools. Since an output schema exists, not spelling out return fields is acceptable, and the description even names a returned field (peer_discovery).

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?

Schema coverage is already 100%, and the description still adds meaningful guidance: peer_orgs is preferred, up to 12 are used, org_description should be a short cause phrase rather than a paragraph, and the matching fallback path is explained. This goes well beyond the schema's field descriptions, especially for the two mutually-conditioned input modes.

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 specific verb and resource: 'Find grantmakers that have ACTUALLY funded organizations LIKE the caller's' using a named grant graph. It also explicitly distinguishes this tool from search_funders and search_open_grants, so an agent can immediately tell it apart from siblings.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance: name 2-5 peers for sharpest results, use org_description only as a fallback, and pair with get_funder_profile/get_foundation_grants for deeper research. It also names the alternatives it is not (search_funders, search_open_grants), making selection unambiguous.

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

find_funders_of_nonprofitFind Funders of a NonprofitA

Read-only

Inspect

Find the funders that have ACTUALLY granted to ONE specific nonprofit — the reverse of get_foundation_grants, over the real 7.5M-edge who-funds-whom grant graph (IRS 990-PF, 2022-2026) plus identity-verified announced/web grant records (how new and non-990 funders appear; per-entry 'source' says which store each funder came from, and announced amounts are often not published — they are counted, never summed).

Use this when the question is about a SINGLE org: "who funds Greater Chicago Food Depository?", "which foundations support this nonprofit?", or to prospect from one well-funded peer. To aggregate the same signal across SEVERAL peer orgs, use find_funders_for_peers instead.

Pass recipient_ein when known (most precise). Otherwise pass recipient_name and it is resolved to the best IRS-registered match — the response echoes which nonprofit it resolved to under 'recipient'; confirm it's the org the caller meant.

COVERAGE: US private-foundation (990-PF) grant history PLUS identity-verified announced/web grant records — the latter is how new funders, corporate programs, and non-990 foundations appear here. Government grants and most donor-advised funding still do NOT appear, so an empty result means "no tracked funder reported or announced a grant to this org", not "this org has no funders" — say exactly that.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of funders to return (1-50)
`min_amount`	No	USD threshold (default 1000): minimum single-grant size for 990 entries; for announced entries, applied to the funder's aggregate published USD total (unpublished/non-USD amounts are never excluded by it)
`nonprofit_ein`	No	Alias for recipient_ein. The tool name says 'nonprofit', so MCP clients send nonprofit_ein= — accept both; recipient_ein wins when both are set.
`recipient_ein`	No	EIN of the RECIPIENT nonprofit whose funders you want.
`nonprofit_name`	No	Alias for recipient_name. The tool name says 'nonprofit', so MCP clients send nonprofit_name= (256 rejected calls by 2026-09-30, ticket #1890) — accept both; recipient_name wins when both are set.
`recipient_name`	No	Name of the recipient nonprofit (resolved via the IRS BMF registry when recipient_ein is not given).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations: discloses data provenance (IRS 990-PF 2022-2026 plus identity-verified announced records, per-entry 'source'), the semantic that announced amounts are counted but never summed, and the crucial empty-result interpretation ('no tracked funder reported or announced', not 'no funders'). It also warns the response echoes the resolved recipient for confirmation.

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?

Purpose and the single-org scope are front-loaded, and the CAPS section headers aid scanning. It is on the long side and the announced/web-records point is restated in both the opening paragraph and COVERAGE, which is mild redundancy rather than wasted space.

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?

With an output schema present the description needn't explain return shape, and it still covers the things that matter: coverage boundaries (no government or most DAF funding), empty-result semantics, source attribution, and recipient resolution/echo. Nothing an agent needs to call this correctly 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?

Schema coverage is 100% so the baseline is 3, but the description adds genuine value the schema does not: recipient_ein is 'most precise', recipient_name resolves via the IRS BMF registry, and the response echoes the resolved org. It does not, however, add anything about limit or min_amount beyond the schema.

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 precise verb+resource (find funders that granted to ONE nonprofit) and explicitly positions itself as 'the reverse of get_foundation_grants' over a named grant graph. It also names the sibling it is not (find_funders_for_peers) for the multi-org case, so an agent can discriminate without opening schemas.

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

Usage Guidelines5/5

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

Gives concrete when-to-use triggers ('who funds X?', 'which foundations support this nonprofit?', prospecting from a peer) and an explicit exclusion routing the aggregate case to find_funders_for_peers. It further specifies parameter preference order (recipient_ein when known, else recipient_name) with the resolution caveat.

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

get_990_summaryGet IRS 990 SummaryA

Read-only

Inspect

Get IRS 990 filing summary and financial trends for a foundation.

This tool retrieves IRS 990 filing data (Form 990 or 990-PF) for a foundation, showing financial information over time. It calculates year-over-year trends for assets, grants, and revenue.

US 990 filers only. Pass ein (or a funder_id that resolves to an EIN — a bare EIN or usf:<ein>). search_funders returns funder_id on every hit, so the caller can hand it back here the way it does for the other funder tools. Non-990 funders have no 990 filings — those return a clean redirect to get_funder_stats(funder_id=...) rather than an error.

ParametersJSON Schema

Name	Required	Description
`ein`	No	Foundation EIN (9 digits). Can include hyphens (e.g., "94-3136777") or be provided as digits only (e.g., "943136777"). Optional if ``funder_id`` is supplied.
`years`	No	Number of years of filing data to return (1-10)
`funder_id`	No	Optional polymorphic funder id. A bare EIN or ``usf:<ein>`` routes to the 990 path; a non-990 id (bare UUID / ``n9f:<uuid>`` / ``non990:<uuid>``) has no 990 filings and returns a redirect to get_funder_stats.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/destructive/openWorld. The description adds genuinely non-structured behavior: US-990-only scope, trend computation, and the fact that non-990 inputs produce a clean redirect rather than an error. Does not discuss pagination or result size limits, so not a full 5.

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 purpose and scope, then parameter routing and fallback behavior. Slightly verbose in restating the 990-vs-non-990 routing twice, but every sentence carries information.

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?

With an output schema present and annotations covering the safety profile, the description supplies everything else an agent needs: data scope, identity inputs, and the non-990 fallback path.

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 ein/funder_id/years are already well documented. The description reiterates the ein vs funder_id relationship and the usf:<ein> form, which is largely redundant with the schema, though the search_funders handoff adds a small workflow hint.

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 specific verb (get) and resource (IRS 990 filing summary / financial trends) and clearly distinguishes itself from get_funder_stats and get_funder_profile by declaring it is 990-only with a redirect for non-990 funders.

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

Usage Guidelines5/5

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

Explicit when-to-use (US 990 filers), how to supply identity (ein, or funder_id resolving to an EIN), and the alternative for non-990 funders (get_funder_stats). It even ties the workflow to search_funders returning funder_id.

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

get_foundation_grantsGet Foundation GrantsA

Read-only

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`ein`	No	Foundation EIN (9 digits, hyphens OK). Required for US 990 path. Optional if ``funder_id`` is supplied for a non-990 funder.
`year`	No	Optional year to filter by (filing_year for 990, grant_year for discovered). If not provided, returns all available years.
`limit`	No	Maximum number of grants to return (1-50)
`funder_id`	No	Optional 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_code`	No	Optional NTEE code to filter recipient organizations. Example: "B41" (Higher Education), "E" (Health). Use get_ntee_codes to browse available codes.
`purpose_keyword`	No	Optional 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_state`	No	Optional 2-letter US state code to filter by recipient state (e.g., "CA", "NY").
`recipient_country`	No	Optional 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

ParametersJSON Schema

Name	Required	Description
No output parameters

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.

get_funder_profileGet Funder ProfileA

Read-only

Inspect

Get detailed profile information for a specific funder.

Polymorphic identifier — pass ein for US 990 foundations OR funder_id (bare UUID / n9f:<uuid>) for non-990 funders such as European, UK 360Giving, and Canadian CRA T3010 funders. search_funders returns both fields on every hit, so the caller can hand either one back here. At least one identifier must be supplied.

Use this after searching for funders to get detailed information about a specific one.

ParametersJSON Schema

Name	Required	Description	Default
`ein`	No	Foundation EIN (9 digits) for US 990 funders. Can include hyphens (e.g., "94-3136777") or be provided as digits only (e.g., "943136777"). Optional if ``funder_id`` is supplied for a non-990 funder.
`funder_id`	No	Optional non-990 funder id. Accepts a bare UUID or ``n9f:<uuid>`` / ``non990:<uuid>``. The ``usf:<ein>`` prefix is also accepted and routes back to the EIN path.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnly/destructive hints, so the description need not repeat them. It adds valuable behavioral context by explaining polymorphic identifier handling (ein vs funder_id with n9f prefix) and the constraint that at least one identifier must be supplied. 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 three short, front-loaded paragraphs with no filler. Each sentence earns its place: purpose, identifier polymorphism, and when to use it.

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?

With only two optional parameters, a rich output schema, and strong annotations, the description covers the core workflow and identifier choice completely. It answers the key questions an agent would have about what to pass and when.

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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds semantics by grouping the identifiers by funder type (US 990 vs non-990) and reinforcing that search_funders returns both fields, aiding identifier selection.

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 opens with 'Get detailed profile information for a specific funder,' which uses a specific verb and resource and immediately distinguishes this from sibling search/stats tools. It also clarifies the scope (specific funder) rather than a list or aggregate.

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 explicitly states 'Use this after searching for funders to get detailed information about a specific one,' giving clear situational context. It does not name alternative tools or state when not to use it, so it falls short of a 5.

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

get_funder_statsGet Funder StatisticsA

Read-only

Inspect

Get comprehensive giving statistics for a funder.

This tool calculates aggregate statistics about a funder's grantmaking from IRS 990-PF data, web-extracted grant records, 360Giving rows, CRA T3010 rows, and ACRI rows. It provides lifetime totals, focus areas, geographic distribution, and year-over-year trends. Pass ein for US 990 foundations, or funder_id (bare UUID / n9f:<uuid>) for non-990 funders.

ParametersJSON Schema

Name	Required	Description	Default
`ein`	No	Foundation EIN (9 digits). Can include hyphens (e.g., "94-3136777") or be provided as digits only (e.g., "943136777"). Optional when funder_id is supplied.
`funder_id`	No	Optional non-990 funder id (bare UUID / ``n9f:<uuid>``).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by enumerating the data sources (IRS 990-PF, web-extracted, 360Giving, CRA T3010, ACRI) and the types of aggregate outputs. It does not disclose potential limitations such as data completeness, but the additions are valuable beyond the 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 front-loaded with the main purpose, followed by a concise explanation of data sources and outputs, then the parameter selection. Each sentence contributes new information, with no fluff or redundancy. It is appropriately sized for the tool's complexity.

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, the description does not need to detail return values. It explains the tool's scope, data sources, and parameter usage. It lacks explicit notes on edge cases (e.g., funders with no data), but overall it is complete enough for an agent to invoke the tool correctly.

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?

Schema covers 100% of parameters. The description adds a decision rule for choosing between ein and funder_id based on funder type, which is not fully articulated in the schema. It also reinforces the formatting details (hyphens allowed). This extra guidance meaningfully assists the agent.

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 opens with 'Get comprehensive giving statistics for a funder,' clearly stating the verb and resource. It further specifies what the statistics include (lifetime totals, focus areas, geographic distribution, trends) and the data sources used, effectively distinguishing it from siblings like get_funder_profile or get_foundation_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 explicit guidance on when to use each parameter: 'Pass ein for US 990 foundations, or funder_id for non-990 funders.' This provides clear context for tool invocation, though it does not explicitly contrast with alternative tools or state exclusions.

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

get_ntee_codesBrowse NTEE CodesA

Read-only

Inspect

Browse NTEE (National Taxonomy of Exempt Entities) classification codes.

NTEE codes are used to classify nonprofit organizations by their primary purpose. This tool helps you find the right NTEE code for searching or understanding a foundation's focus area.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Search term to find codes by description (case-insensitive). Example: "education", "youth", "environment"
`category`	No	Single letter (A-Z) to browse codes in a major category. Example: "A" for Arts, Culture & Humanities "B" for Education "E" for Health Care "P" for Human Services

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about what the tool does (browse codes) and its purpose, but does not disclose any additional behavioral traits such as pagination, result limits, or how outputs are structured. This is acceptable for a simple read-only lookup tool with an output schema.

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 two well-structured sentences. The first sentence explains what the tool b rowses, and the second adds purpose. There is no fluff, and the key information is front-loaded.

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?

This is a simple tool with two optional parameters, a rich schema, and an output schema, so the description doesn't need to over-explain. It covers the overall purpose and usage context. However, it could slightly improve by explicitly noting that either parameter option can be used independently or together, though the schema already implies this.

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 each parameter has a clear description. The tool description itself does not add extra meaning beyond the schema, but the baseline of 3 is appropriate because the schema already explains the parameters thoroughly.

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 identifies the tool as a browser for NTEE classification codes, with a specific purpose: helping find the right code for searching or understanding a foundation's focus area. It uses the verb 'browse' plus the resource 'NTEE codes,' and the context about nonprofit classification distinguishes it from sibling tools about funders and grants, though it doesn't explicitly compare to a sibling.

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 states when to use the tool ('find the right NTEE code for searching or understanding a foundation's focus area') but provides no exclusions or alternatives. Since there are no direct sibling tools for NTEE codes, the guidance is adequate but not explicit about when not to use it.

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

health_checkHealth CheckA

Read-only

Inspect

Check server health and connectivity.

Returns: Dictionary with health status including: - status: "healthy" or "unhealthy" - version: Server version - environment: Current environment (dev/staging/prod)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return structure (status, version, environment) and the connectivity check behavior, which goes beyond the annotation-only information.

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 extremely concise, front-loaded with the purpose, and follows with a clear bulleted list of return fields. No filler or redundant content.

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 a zero-parameter health check tool, the description fully covers its purpose and return data. The output structure is described, and no additional context is needed given the tool's simplicity and the supporting annotations.

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 input schema has zero parameters, so schema coverage is 100%. There is nothing for the description to add about parameters. Baseline for zero-param tools is 4, and no explanation is needed.

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 clearly states 'Check server health and connectivity' with a specific verb and resource. This uniquely distinguishes it from sibling tools, which all focus on funder/nonprofit data operations.

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 purpose is unambiguous and provides clear context for when to use this tool: when you need to verify server health or connectivity. It does not explicitly list alternatives or exclusions, but the domain differentiation from siblings makes the usage context evident.

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

list_toolsList Available ToolsA

Read-only

Inspect

List available MCP tools and get detailed help.

Use this tool to discover what tools are available and how to use them. Call without parameters to see all tools, or provide a tool name to get detailed help including parameters, examples, and related tools.

ParametersJSON Schema

Name	Required	Description	Default
`tool_name`	No	Optional name of a specific tool to get detailed help for. Example: "search_funders", "get_funder_profile"

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description only needs to add extra behavioral context. It does so by explaining the tool's dual behavior (list all vs. details for a specific tool) and mentioning what the help includes (parameters, examples, related tools). No contradictions 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 three concise sentences with the main purpose front-loaded. Every sentence adds useful information without fluff or redundancy.

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 simple schema, rich annotations, and the presence of an output schema, the description fully covers the tool's behavior. It explains both usage modes and what to expect in return, leaving no significant gaps.

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?

Schema coverage is 100% for the one parameter, so the baseline is 3. The description adds value beyond the schema by explicitly stating that calling without parameters shows all tools, and providing a tool name gets detailed help—this clarifies the optional parameter's behavioral effect.

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 clearly states the tool lists available MCP tools and provides detailed help. It uses a specific verb and resource, and it distinguishes itself well from sibling tools which all focus on domain-specific queries like funder or grant searches.

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 explicitly states when to use the tool ('to discover what tools are available and how to use them') and explains the two call modes (no parameters vs. with a tool name). It does not explicitly mention when not to use it or contrast with alternatives, but the context is clear given the nature of the tool.

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

search_funder_jobsSearch Funder JobsA

Read-only

Inspect

Search OPEN PHILANTHROPY JOBS at grantmaking foundations.

Surfaces roles involved in giving away money, running philanthropic programs, or executive leadership of philanthropic work. Backed by a weekly scrape of ~50K funder careers pages + GPT-5.4-mini classification against an 8-category taxonomy.

Categories (use the category param to filter):

grantmaking: Program officers, grants managers, RFP reviewers
program_leadership: VP Programs, Chief Program Officer, Program Director (cause-area)
executive_leadership: CEO, President, Executive Director at a foundation or community foundation
philanthropy_operations: Foundation finance/HR/IT/COO
program_support: Program associates, M&E officers, learning officers, program coordinators
development_for_grantmaking: Major gifts officers and development roles at community foundations and other regranting entities (NOT university or hospital development for the parent's operations)
philanthropy_communications: Foundation comms staff
philanthropy_strategy: Chief Strategy Officer, impact officer, equity & inclusion at a foundation

What's excluded by design: clinical/medical, retail, academic teaching, university advancement for the university itself, hospital fundraising for hospital ops, construction/facilities.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (1-50)
`query`	No	Keyword search on job title (case-insensitive substring). Examples: "program officer", "grants manager", "CEO", "communications director".
`state`	No	2-letter US state code (e.g., "CA", "NY"). Uses a broad SQL prefilter plus an exact token-aware post-filter against the location field.
`remote`	No	remote \| hybrid \| on-site.
`country`	No	Funder HQ country — ISO 3166-1 alpha-2 ("US", "GB", "DE") or a recognized name ("United Kingdom", "Germany"). Filters by where the FOUNDATION is headquartered; the corpus spans European funders, not just US. Independent of `state` (US foundations are the only ones with state-level location data).
`sort_by`	No	Result ordering. 'funder_giving' (default) ranks by the foundation's annual average giving so the biggest funders surface first. 'recent' sorts by posted_at desc.	funder_giving
`category`	No	One of the 8 philanthropy categories above.
`funder_id`	No	Restrict to one funder by the polymorphic id search_funders returns and the other funder tools accept: usf:<ein>, n9f:<uuid>, non990:<uuid>, a bare EIN or a bare UUID. Ignored when funder_ein/funder_eins is given.
`seniority`	No	Experience level: internship_fellowship \| entry_level \| mid \| senior \| executive. Comma-separate for multi-select — 'entry_level,internship_fellowship' is the early-career shelf (new grads, students). Rows not yet leveled by the classifier are excluded when set.
`funder_ein`	No	Restrict to one funder by EIN (9 digits, optional prefixes/dashes accepted).
`funder_eins`	No	Restrict to a LIST of funder EINs (up to 100). The recommended compositional pattern is search_funders → search_funder_jobs(funder_eins=[...]) for cause-area searches (climate, racial equity, youth, etc.) where the cause isn't captured by the 8 role-family categories.
`employment_type`	No	full-time \| part-time \| contract \| internship \| fellowship \| temporary.
`exclude_categories`	No	Categories to hide. Default is no category exclusions; the public jobs board includes operations roles. Pass specific category names to suppress them.
`posted_within_days`	No	Recency window in days (0-730). Set 0 to disable.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only and non-destructive behavior. The description adds data provenance (weekly scrape of ~50K funder careers pages, GPT classification) and spells out inclusion/exclusion rules, which is useful behavioral context beyond annotations. It does not cover auth needs or rate limits, so a 4 is appropriate.

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-loads the purpose and data source, then uses clear headings for categories and exclusions. The length is justified by the 14 parameters and eight categories, though the specific classifier model name adds minor noise.

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?

With an output schema present, the description need not explain return values. It covers purpose, data provenance, taxonomy, and exclusions, giving complete context for correct invocation given the tool's complexity.

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?

Schema coverage is 100%, so the baseline is 3. The description goes further by supplying the actual eight category names and definitions that the schema's `category` field refers to as 'above', adding necessary semantic meaning beyond the schema text.

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 specific verb ('Search') and resource ('OPEN PHILANTHROPY JOBS at grantmaking foundations'), and scopes it to philanthropy roles. The resource is clearly distinct from sibling tools like search_funders and search_open_grants, so an agent can differentiate without opening schemas.

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?

Provides explicit category definitions and a dedicated 'What's excluded by design' section, giving clear context for appropriate queries. However, it does not name alternative tools (e.g., search_funders) or state when to prefer this tool over them, keeping it from a 5.

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

search_fundersSearch GrantmakersA

Read-only

Inspect

Look up grantmaking organizations by name, topic, or location.

This tool searches 174K+ grantmaking organizations from IRS data using organization names plus grant-purpose/topic signals. Use it when you know the funder's name, want aligned funders for a cause area, or want to browse by location/size/NTEE code. Multi-word searches are ranked by relevance; simple browse/name fallback results are ordered by total assets.

IMPORTANT: Use search_open_grants when the user needs active grant programs or RFPs. search_funders is for finding aligned grantmakers, including ones that may fund by relationship, LOI, or annual cycle rather than a live call.

ParametersJSON Schema

Name	Required	Description
`city`	No	City name to filter by (case-insensitive). Example: "San Francisco", "New York"
`limit`	No	Maximum number of results to return (1-50)
`metro`	No	Colloquial metro / region name for sub-state geography a single city can't capture — "Bay Area", "NYC", "the DMV", "Greater Boston", "Los Angeles", "Chicago", "Seattle". Resolved to its MSA/CBSA code set and applied as an HQ pre-filter. PREFER this over `city` whenever the user names a metro/region rather than one municipality (e.g. "Bay Area funders that fund drug rehab" → query="drug rehab addiction", metro="Bay Area"). Accepts a single name or a list. City names resolve too ('Cleveland', 'Knoxville', 'Portland, OR'). An unrecognized name does NOT error: the search runs without that metro filter and the result carries `geo_notice` saying so (with a did-you-mean when one is close). Example: "Bay Area", ["NYC", "Greater Boston"]
`query`	No	Search term for a funder name or cause-area phrase. Example: "Ford Foundation", "global health", "community foundation" Topic searches work best with 2+ words.
`state`	No	Two-letter US state code to filter by funder HQ location. Example: "CA", "NY", "TX"
`country`	No	Optional HQ country name (or list of names) to restrict to funders headquartered in those countries (e.g., "Germany", ["United States", "Canada"]). Distinct from `grantee_country_codes` (where the funder's grants land) and from `state` (US state of HQ). Use when the user asks for funders based in a specific country — e.g. "European-headquartered foundations" → country=["Germany","Spain","United Kingdom", "Switzerland","Netherlands","France"]. US foundations are included only when "United States" (or "USA") is in the list, or when the param is omitted.
`has_pris`	No	Filter to foundations with known program-related investment activity. Set true when looking for PRI-active capital providers.
`msa_codes`	No	Explicit MSA/CBSA codes when you already know them (e.g. ["41860", "41940"]); unioned with whatever `metro` resolves to. Most callers should use `metro`.
`ntee_code`	No	NTEE classification code to filter by. Example: "A20" (Arts Organizations), "B" (Education), "E" (Health)
`max_assets`	No	Maximum total assets filter in dollars. Example: 100000000 (foundations with up to $100M assets)
`min_assets`	No	Minimum total assets filter in dollars. Example: 10000000 (foundations with $10M+ assets)
`funder_type`	No	Optional canonical funder_type to include. Examples: "community_foundation", "family_foundation", "corporate_foundation", "private_operating", "operating_nonprofit", "independent_foundation". Use this to narrow to a specific kind of grantmaker. NOTE: operating entities (private_operating, operating_nonprofit) are EXCLUDED BY DEFAULT — name one here to include it (e.g. to look up a specific hospital or patient-assistance foundation).
`has_er_grants`	No	Filter to foundations that make expenditure responsibility grants (grants to non-501(c)(3) entities like PBCs, for-profits, and foreign orgs). Set to True to find only ER-active funders.
`exclude_funder_types`	No	Optional list of canonical funder_type codes to exclude from results. NOTE: this search ALREADY excludes the operating-entity types by default — private_operating (pharma patient-assistance foundations) and operating_nonprofit (hospital / university group returns) post large "annual_grants" but aren't grantmakers you can apply to. Use this for ADDITIONAL categories; to opt an operating type back in, name it in funder_type instead.
`grantee_country_codes`	No	Optional list of FIPS 10-4 country codes (e.g., "UK" for United Kingdom, "IN" for India, "KE" for Kenya, "SF" for South Africa) to restrict to funders whose grantees are located in those countries. Use this when the user is asking for funders that move money into a specific non-US geography. Country here is the grantee's HQ country, derived from foundation_grants. When set, the search is forced through the hybrid path; the ILIKE-only name-match path cannot filter by country. Distinct from `state`, which filters by the funder's own US HQ.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: data source (IRS data), ranking behavior (multi-word searches ranked by relevance vs. simple browse/name fallback ordered by total assets), and the distinction that search_funders surfaces funders that may operate on LOI/relationship/annual cycles rather than live calls. 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 compact and well-organized: a one-line summary, a usage paragraph, and a clearly flagged IMPORTANT routing note. Every sentence earns its place, and the most decision-relevant distinction (when to use search_open_grants instead) is prominently separated.

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 a read-only search tool with 15 optional parameters fully documented in the schema and an output schema present, the description covers the key usage scenarios, ranking behavior, and sibling-tool routing. Nothing an agent needs to correctly select and invoke this tool is missing.

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 each of the 15 parameters has rich, example-laden documentation. The description itself only names the high-level search dimensions (name, topic, location), so it does not add meaning beyond the schema. Baseline 3 is appropriate when the schema carries the full parameter-load.

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 opens with a specific verb and resource ('Look up grantmaking organizations by name, topic, or location') and further specifies the 174K+ IRS-based dataset and the name/topic-signal search mechanism. It clearly distinguishes this tool from search_open_grants and other funder-focused siblings.

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

Usage Guidelines5/5

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

Explicitly states when to use the tool ('when you know the funder's name, want aligned funders for a cause area, or want to browse by location/size/NTEE code') and gives an explicit exclusion: use search_open_grants for active grant programs or RFPs. This is model guidance with a named alternative.

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

search_nonprofitsSearch Nonprofits (Grantee Benchmarking)

Read-only

Inspect

Search the ~2M-org universe of US nonprofits (IRS Business Master File) — the RECIPIENT / grantee side, distinct from search_funders (the grantmaker side). Use this to benchmark peer organizations, research a cause's landscape, or find well-funded peers and then look up WHO funds them.

Each result carries 990 financials (revenue, program-expense ratio, employees, governance score) and recipient-side funding signals: total_grants_received (tracked foundation $ received), funder_count (distinct funders), avg_grant_size_received, and funder_concentration_hhi.

CHOOSING THE RIGHT TOOL:

Want FUNDERS to apply to → use search_funders.
Want to research/benchmark RECIPIENT nonprofits (peers, "who received $X", landscape of a cause) → use search_nonprofits.
Found a well-funded peer and want their funders → note its funder_count, then use get_foundation_grants / search_funders to find who funds that work.

THESIS MODE (funder-side sourcing): pass thesis, a plain-language description of the organizations wanted ("early-stage nonprofits using AI to expand economic mobility in the US"). The corpus is ranked by meaning instead of by name, and each row carries similarity, technology_role / ai_usage (evidence-backed enums, 'unknown' when not yet assessed), evidence (verbatim quotes + source URLs), and the organization's own Form 990 Part III text as mission_990 + programs (filing year, source link), and funded_or_vetted_by: third-party facts with attribution and a link (grants a named funder committed: count, years, total when every grant states one; challenge applications with status, where 'applicant' = applied only). unavailable_fields names any of these that could not be read for the page. Combine with ruling_date_from (yyyymm; 201800 = ruled 2018+), ntee_codes, state, metro, revenue / received bounds. Default sort in thesis mode is 'relevance'; 'legibility_counterweight' adds a bounded bonus for small or lightly funded orgs. Only organizations with a semantic profile are reachable in thesis mode; query (name match) still reaches every organization.

ParametersJSON Schema

Name	Required	Description
`city`	No	Case-insensitive exact city name.
`limit`	No	Maximum number of results (1-50)
`metro`	No	Colloquial metro/region ("Bay Area", "NYC", "Chicago", "Greater Boston") or a city name ("Cleveland", "Portland, OR") → resolved to its MSA codes. Prefer over city for metro-area intent. An unrecognized name does not error: the search runs without the metro filter and the result carries `geo_notice`.
`query`	No	Case-insensitive substring match on the organization name.
`state`	No	2-letter US state code (e.g. "IL").
`thesis`	No	Plain-language description for thesis mode (see above).
`sort_by`	No	Omit for the default. Lexical: received (default) \| revenue \| funders \| name. Thesis mode: relevance (default) \| legibility_counterweight \| received.
`ai_usage`	No	Thesis mode filter, same enum for AI specifically. Evidence-backed.
`msa_codes`	No	Explicit CBSA codes if you already know them.
`ntee_codes`	No	NTEE classification PREFIXES (e.g. ["K31"] food banks, ["E"] health, ["B20"] schools). Prefix match, so "K" = all food/agriculture, "K31" = food banks specifically.
`active_only`	No	Only IRS-active orgs (default True).
`max_revenue`	No
`min_revenue`	No
`max_received`	No	Maximum total received.
`min_received`	No	Minimum total grant dollars RECEIVED (the key grantee-benchmarking filter — "received over $1M").
`min_employees`	No	Minimum employee count.
`technology_role`	No	Thesis mode filter, subset of core \| assisted \| none \| unknown (is technology the organization's PRODUCT?). Evidence-backed.
`min_funder_count`	No	Minimum distinct funders.
`ruling_date_from`	No	Thesis mode: earliest IRS ruling date as yyyymm.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

search_open_grantsSearch Open GrantsA

Read-only

Inspect

Search open grant opportunities from Kindora's active foundation-program corpus plus federal and state government grants.

FOR-PROFIT APPLICANTS: pass for_profit_applicant=true to search capital a for-profit can take (PRIs, loans, revenue-based financing, patient equity) from CDFIs, impact investors, and PRI-active foundations. The default pool is 501(c)(3)-shaped and will NOT contain those programs.

Searches both private foundation grant programs (from IRS data and funder websites) and government grant opportunities — federal (Grants.gov) plus state and district grant portals. Uses full-text search with natural language understanding — queries are parsed into individual terms with stemming, so "youth after school programs" matches programs about youth, after-school, and programming even if those exact words don't appear together.

Search covers program names, descriptions, focus areas, beneficiary types, and geographic focus fields. Use the state parameter to focus on geographically relevant opportunities.

Query syntax:

Natural language: "affordable housing for seniors" (matches any of these terms)
Quoted phrases: '"after school"' (matches exact phrase)
Exclusion: "education -higher" (matches education, excludes higher education)
Combine: '"mental health" youth -adult' (phrase + term + exclusion)
No query: returns broadly open programs sorted by upcoming deadlines (browsing mode)

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (1-50)
`query`	No	Natural language search query. Searches across program names, descriptions, focus areas, beneficiary types, and geographic focus. Supports quoted phrases for exact matching and -term for exclusion. Example: "youth outdoor education", "affordable housing", "STEM education for girls", "food bank hunger", "climate change environment", "domestic violence women"
`state`	No	Two-letter US state code to filter by geographic relevance. Returns programs focused on that state plus nationally available programs. Example: "CA", "NY", "TX"
`topic`	No	Alias for query. The tool description says 'by TOPIC', so many MCP clients send topic= (32 rejected calls by 2026-07-11) — accept both; query wins when both are set.
`agency`	No	Filter government grants by agency name (case-insensitive). Example: "Department of Education", "NSF", "NIH"
`source`	No	Filter by grant source type. Options: "foundation" (private foundation programs only), "government" (federal + state government grants only), or omit for both sources combined. PREFER omitting this — the foundation corpus is much larger, and filtering to government-only often returns few or zero results.
`country`	No	Where the applicant works — a country name or a region. Returns funders scoped to that place PLUS regional and global funders, with place-specific ones ranked first (a Kenyan applicant also sees "Sub-Saharan Africa" and worldwide funders). Native names work ("Deutschland", "Espana"). OMIT when the user has not named a place: "Global"/"International" is accepted but simply means no geographic restriction, so it is never needed. An unrecognised value broadens the search rather than emptying it. Use this instead of state for international queries — passing "India" via state would error because state requires a US code. Mixing state with a non-US country is rejected. Example: "India", "Kenya", "Southeast Asia", "Deutschland"
`max_award`	No	Maximum grant size filter in dollars. Example: 500000 (grants up to $500K)
`min_award`	No	Minimum grant size filter in dollars. Example: 50000 (grants of $50K+)
`focus_area`	No	Filter foundation programs by focus area (matches values in focus_areas array). Example: "Education", "Health", "Environment"
`deadline_days`	No	Deadline lookahead window in days (1-365)
`nonprofit_only`	No	GOVERNMENT-grants applicant filter only. Omit for the entity-aware default: true for nonprofits and false for for-profit applicants. Does not open the foundation pool — use for_profit_applicant.
`for_profit_applicant`	No	Set TRUE when the applicant is a FOR-PROFIT entity (social enterprise, public benefit corporation, B Corp, L3C, CDFI). Routes foundation-program search to the for-profit capital pool: loans, program-related investments, revenue-based financing, patient equity, guarantees — capital a company can actually take. Default False = the 501(c)(3) grant pool, which deliberately excludes those instruments.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, destructiveHint=false, but the description goes well beyond: it discloses the search engine behavior (natural language understanding, stemming, query syntax with examples), explains the geographic ranking logic (place-specific funders ranked first), what happens with unrecognized country values (broadens rather than empties), and the internal workaround for 'topic' alias. No contradictions.

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 well-structured with sections (for-profit applicants, supported sources, search semantics) and front-loaded with the core purpose. It could be slightly tighter (e.g., the historical 'by TOPIC' note is edge-case), but every sentence adds value—no filler, good readability.

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?

Despite 13 parameters, no output schema (yet has one), and no required params, the description covers all major behavioral aspects: query syntax, filtering options, entity-type-aware defaults, geographic nuances, and browsing mode. No glaring gaps remain for an agent to misuse the tool.

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?

Schema description coverage is 100%, yet the description adds critical meaning: for_profit_applicant bridges to an alternative capital pool, the 'country' parameter explains multi-tier geographic ranking, and the 'topic' alias documents a real user-facing issue. This transforms flat schema descriptions into actionable guidance.

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 uses a specific verb ('Search') and resource ('open grant opportunities'), clearly identifying the domain (Kindora's foundation corpus plus federal and state government grants). It distinguishes from siblings like 'search_funders' or 'get_funder_profile' by focusing on grant opportunities rather than funder profiles.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use the for_profit_applicant parameter, contrasts the default nonprofit pool, and explains when to use the 'country' parameter over 'state' for international queries. It also advises against filtering by 'source' to government-only due to sparse results, offering clear alternatives and context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 8, 2026

Changedsearch_nonprofits8 fields changed

addedInput schema / properties / ai_usage

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Thesis mode filter, same enum for AI specifically. Evidence-backed."
+}

addedInput schema / properties / ruling_date_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Thesis mode: earliest IRS ruling date as yyyymm."
+}

addedInput schema / properties / sort_by / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / sort_by / default
```
Previous value: -"received"New value: +null
```

changedInput schema / properties / sort_by / description

Previous value: -"received (default) | revenue | funders | name."New value: +"Omit for the default. Lexical: received (default) | revenue | funders |\nname. Thesis mode: relevance (default) | legibility_counterweight | received."

removedInput schema / properties / sort_by / type
```
Removed value: -"string"
```

addedInput schema / properties / technology_role

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Thesis mode filter, subset of core | assisted | none | unknown\n(is technology the organization's PRODUCT?). Evidence-backed."
+}

addedInput schema / properties / thesis

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Plain-language description for thesis mode (see above)."
+}

1 tool updateOct 6, 2026

Changedfind_funders_of_nonprofit1 field changed

changedInput schema / properties / min_amount / description

Previous value: -"Minimum single-grant size in USD (default 1000)"New value: +"USD threshold (default 1000): minimum single-grant size for 990 entries; for announced entries, applied to the funder's aggregate published USD total (unpublished/non-USD amounts are never excluded by it)"

1 tool updateOct 5, 2026

Changedget_990_summary4 fields changed

addedInput schema / properties / ein / default
```
Added value: +""
```

changedInput schema / properties / ein / description

Previous value: -"Foundation EIN (9 digits). Can include hyphens (e.g., \"94-3136777\")\n or be provided as digits only (e.g., \"943136777\")."New value: +"Foundation EIN (9 digits). Can include hyphens (e.g., \"94-3136777\")\n or be provided as digits only (e.g., \"943136777\"). Optional if\n ``funder_id`` is supplied."

addedInput schema / properties / funder_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional polymorphic funder id. A bare EIN or ``usf:<ein>``\n routes to the 990 path; a non-990 id (bare UUID / ``n9f:<uuid>`` /\n ``non990:<uuid>``) has no 990 filings and returns a redirect to\n get_funder_stats."
+}

removedInput schema / required
```
Removed value: -[
-  "ein"
-]
```

1 tool updateOct 1, 2026

Changedfind_funders_of_nonprofit2 fields changed

addedInput schema / properties / nonprofit_ein

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alias for recipient_ein. The tool name says 'nonprofit', so MCP clients send nonprofit_ein= — accept both; recipient_ein wins when both are set."
+}

addedInput schema / properties / nonprofit_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alias for recipient_name. The tool name says 'nonprofit', so MCP clients send nonprofit_name= (256 rejected calls by 2026-09-30, ticket #1890) — accept both; recipient_name wins when both are set."
+}

1 tool updateSep 28, 2026

Changedsearch_funder_jobs1 field changed

addedInput schema / properties / funder_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Restrict to one funder by the polymorphic id search_funders returns and the other funder tools accept: usf:<ein>, n9f:<uuid>, non990:<uuid>, a bare EIN or a bare UUID. Ignored when funder_ein/funder_eins is given."
+}

4 tool updatesSep 24, 2026
- Removedcheck_funder_fit_for_my_organization
- Removedlist_my_pipeline
- Removedsave_funder_to_pipeline
- Removedwhoami
4 tool updatesSep 24, 2026
- Addedcheck_funder_fit_for_my_organization
- Addedlist_my_pipeline
- Addedsave_funder_to_pipeline
- Addedwhoami

1 tool updateAug 29, 2026

Changedget_foundation_grants1 field changed

changedInput schema / properties / recipient_country / description

Previous value: -"Optional recipient country filter. Use ISO\n  3166-1 alpha-2 codes (e.g., \"CH\" Switzerland, \"ZA\" South\n  Africa, \"NG\" Nigeria, \"IN\" India). Legacy FIPS 10-4 codes\n  (\"SZ\", \"SF\", \"NI\") are also accepted for back-compat;\n  output codes are emitted in ISO 3166."New value: +"Optional recipient country filter. Use ISO\n  3166-1 alpha-2 codes (e.g., \"CH\" Switzerland, \"ZA\" South\n  Africa, \"NG\" Nigeria, \"IN\" India). A code that is valid ISO\n  is always read as ISO (\"NG\" is Nigeria, never Niger; \"SN\" is\n  Senegal, never Singapore); legacy FIPS 10-4 codes match only\n  when they are not ISO codes at all (\"UK\", \"SF\"). Output\n  codes are emitted in ISO 3166."

2 tool updatesAug 29, 2026

Changedsearch_funders1 field changed

changedInput schema / properties / metro / description

Previous value: -"Colloquial metro / region name for sub-state geography a single\n   city can't capture — \"Bay Area\", \"NYC\", \"the DMV\", \"Greater\n   Boston\", \"Los Angeles\", \"Chicago\", \"Seattle\". Resolved to its\n   MSA/CBSA code set and applied as an HQ pre-filter. PREFER this\n   over `city` whenever the user names a metro/region rather than\n   one municipality (e.g. \"Bay Area funders that fund drug rehab\"\n   → query=\"drug rehab addiction\", metro=\"Bay Area\"). Accepts a\n   single name or a list. Unrecognized names return an error that\n   lists the known metros.\n   Example: \"Bay Area\", [\"NYC\", \"Greater Boston\"]"New value: +"Colloquial metro / region name for sub-state geography a single\n   city can't capture — \"Bay Area\", \"NYC\", \"the DMV\", \"Greater\n   Boston\", \"Los Angeles\", \"Chicago\", \"Seattle\". Resolved to its\n   MSA/CBSA code set and applied as an HQ pre-filter. PREFER this\n   over `city` whenever the user names a metro/region rather than\n   one municipality (e.g. \"Bay Area funders that fund drug rehab\"\n   → query=\"drug rehab addiction\", metro=\"Bay Area\"). Accepts a\n   single name or a list. City names resolve too ('Cleveland',\n   'Knoxville', 'Portland, OR'). An unrecognized name does NOT error:\n   the search runs without that metro filter and the result carries\n   `geo_notice` saying so (with a did-you-mean when one is close).\n   Example: \"Bay Area\", [\"NYC\", \"Greater Boston\"]"

Changedsearch_nonprofits1 field changed

changedInput schema / properties / metro / description

Previous value: -"Colloquial metro/region (\"Bay Area\", \"NYC\", \"Chicago\",\n\"Greater Boston\") → resolved to its MSA codes. Prefer over city\nfor metro-area intent."New value: +"Colloquial metro/region (\"Bay Area\", \"NYC\", \"Chicago\",\n\"Greater Boston\") or a city name (\"Cleveland\", \"Portland, OR\")\n→ resolved to its MSA codes. Prefer over city for metro-area\nintent. An unrecognized name does not error: the search runs\nwithout the metro filter and the result carries `geo_notice`."

1 tool updateAug 28, 2026

Changedfind_funders_for_peers1 field changed

changedInput schema / properties / org_description / description

Previous value: -"Plain-language description of the nonprofit (fallback).\nExample: \"youth mental health services for teens\"."New value: +"Short cause phrase for the nonprofit (fallback).\nExample: \"youth mental health\". Adding words narrows the match."

1 tool updateAug 17, 2026

Changedsearch_open_grants1 field changed

changedInput schema / properties / source / description

Previous value: -"Filter by grant source type.\n   Options: \"foundation\" (private foundation programs only),\n            \"government\" (federal grants only),\n            or omit for both sources combined.\n   PREFER omitting this — the foundation corpus is much larger, and\n   filtering to government-only often returns few or zero results."New value: +"Filter by grant source type.\n   Options: \"foundation\" (private foundation programs only),\n            \"government\" (federal + state government grants only),\n            or omit for both sources combined.\n   PREFER omitting this — the foundation corpus is much larger, and\n   filtering to government-only often returns few or zero results."

1 tool updateAug 14, 2026

Changedsearch_open_grants1 field changed

changedInput schema / properties / country / description

Previous value: -"Country name for non-US geographic filtering. Returns programs\n   whose geographic_focus is tagged for that country plus any tagged\n   Global / International / Worldwide. Use this instead of state for\n   international queries — passing \"India\" via state would error\n   because state requires a US code. Mixing state with a non-US\n   country is rejected.\n   Example: \"India\", \"Kenya\", \"Mexico\", \"Global\""New value: +"Where the applicant works — a country name or a region.\n   Returns funders scoped to that place PLUS regional and global\n   funders, with place-specific ones ranked first (a Kenyan\n   applicant also sees \"Sub-Saharan Africa\" and worldwide funders).\n   Native names work (\"Deutschland\", \"Espana\"). OMIT when the user\n   has not named a place: \"Global\"/\"International\" is accepted but\n   simply means no geographic restriction, so it is never needed.\n   An unrecognised value broadens the search rather than emptying\n   it. Use this instead of state for international queries —\n   passing \"India\" via state would error because state requires a\n   US code. Mixing state with a non-US country is rejected.\n   Example: \"India\", \"Kenya\", \"Southeast Asia\", \"Deutschland\""

2 tool updatesJul 27, 2026

Changedsearch_funders1 field changed

addedInput schema / properties / has_pris

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter to foundations with known program-related investment\n   activity. Set true when looking for PRI-active capital providers."
+}

Changedsearch_open_grants4 fields changed

addedInput schema / properties / nonprofit_only / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / nonprofit_only / default
```
Previous value: -trueNew value: +null
```

changedInput schema / properties / nonprofit_only / description

Previous value: -"GOVERNMENT-grants applicant filter only (default True). Does NOT open the for-profit foundation pool — use for_profit_applicant."New value: +"GOVERNMENT-grants applicant filter only. Omit for the entity-aware default: true for nonprofits and false for for-profit applicants. Does not open the foundation pool — use for_profit_applicant."

removedInput schema / properties / nonprofit_only / type
```
Removed value: -"boolean"
```

1 tool updateJul 26, 2026

Changedsearch_open_grants2 fields changed

addedInput schema / properties / for_profit_applicant

Added value: +{
+  "default": false,
+  "description": "Set TRUE when the applicant is a FOR-PROFIT entity (social enterprise, public benefit corporation, B Corp, L3C, CDFI). Routes foundation-program search to the for-profit capital pool: loans, program-related investments, revenue-based financing, patient equity, guarantees — capital a company can actually take. Default False = the 501(c)(3) grant pool, which deliberately excludes those instruments.",
+  "type": "boolean"
+}

changedInput schema / properties / nonprofit_only / description

Previous value: -"Only show nonprofit-eligible government grants.\n   Default: True"New value: +"GOVERNMENT-grants applicant filter only (default True). Does NOT open the for-profit foundation pool — use for_profit_applicant."

Related MCP Connectors

FundingLandscape A
io.github.tettertotter
Search 31,000+ open US grants, federal contracts, and foundations. Checked daily, free tier.
Government Data Open Data
282
Federal Grants — find funding you are actually eligible for A
io.github.wyattpalm2-eng
Find US federal grants your organization is actually eligible to apply for. Free, no API key.
Government Data Open Data Research & Data
311
IRS 990 Nonprofit Data A
com.olyport
Nonprofit lookup and IRS 990 filing data: revenue, assets, and compensation via ProPublica
Government Data Finance
32
CauseComp
org.causecomp
Nonprofit executive and workforce pay benchmarks built from IRS Form 990 filings and BLS data.
Government Data Open Data Research & Data
1

Related MCP Servers

nonprofit-explorer-mcp-server
Government Data Open Data Research & Data
cyanheads
A
license
Not graded
quality
A
maintenance
Search and explore 1.8M+ US nonprofits, fetch Form 990 financials, and access IRS filing history via MCP.
Updated 5 days ago (2026-10-09 04:30 UTC)
252 npm
2
Apache 2.0
DataDawn MCP Serverofficial
Government Data Open Data Databases
DataDawn-org
A
license
Not graded
quality
B
maintenance
Enables AI agents to query the IRS 990 nonprofit database and OpenRegs federal regulations database via SQL, providing access to nonprofit filings, grants, lobbying, and congressional data.
Updated 7 days ago (2026-10-06 18:15 UTC)
Creative Commons Zero v1.0 Universal
propublica-npo-mcp
Government Data Open Data Research & Data
2b3pro
A
license
A
quality
D
maintenance
Provides tools to search and retrieve nonprofit organization data and IRS filing summaries from ProPublica's Nonprofit Explorer, including side-by-side comparisons.
Updated 6 months ago (2026-04-27 01:42 UTC)
4
MIT
Opportunity Radar
Government Data Open Data Search
kevin9327
A
license
Not graded
quality
B
maintenance
Enables asking questions in natural language about live grants.gov funding opportunities, with tools to find, filter, check eligibility, track deadlines, and rank matches—while refusing to guess when data is unavailable.
Updated a month ago (2026-09-02 14:37 UTC)
MIT