foundation-discovery
Server Details
Foundation discovery and grant intelligence for nonprofits. 174K+ US funders, IRS 990 data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.9/5.
Most tools have distinct purposes, but get_990_summary and get_funder_stats both provide financial/statistical information about foundations, potentially causing confusion. However, detailed descriptions help differentiate them.
All tools follow a consistent snake_case pattern with a verb_noun structure (e.g., get_990_summary, search_funders). Even health_check and list_tools fit the pattern of being descriptive.
With 10 tools covering funder profiles, grants, jobs, NTEE codes, and searches, the count is well-scoped for a foundation discovery server. Each tool serves a clear purpose without redundancy.
The server covers core needs: funder search, profile, stats, grants, jobs, and classification codes. Minor gaps exist, such as lacking a tool to retrieve details on a specific grant or grantee, but these are not critical for the domain.
Available Tools
10 toolsget_990_summaryGet IRS 990 SummaryARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Foundation EIN (9 digits). Can include hyphens (e.g., "94-3136777") or be provided as digits only (e.g., "943136777"). | |
| years | No | Number of years of filing data to return (1-10) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, so the description carries less burden. It adds valuable context about calculating year-over-year trends for assets, grants, and revenue, which goes beyond the annotation. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with a clear first sentence. The second paragraph repeats some information but is not overly verbose. Could be slightly tighter, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an existing output schema, the description adequately explains the tool's purpose and key behavior. It covers the scope (IRS 990 data, trends over time) without needing to detail return values. Minor gap: no mention of the EIN format requirement (already in schema) but fine.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (ein, years). The description adds context ('financial information over time', 'year-over-year trends') but does not add new meaning beyond the schema's parameter descriptions. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'IRS 990 filing summary and financial trends', and the target 'a foundation'. This is specific and distinct from sibling tools like get_funder_profile or get_funder_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for financial trends but does not explicitly guide when to use this tool versus alternatives like get_funder_profile or search_open_grants. No exclusion conditions or context are provided.
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 GrantsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). Legacy FIPS 10-4 codes ("SZ", "SF", "NI") are also accepted for back-compat; output codes are emitted in ISO 3166. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it explains the five data sources, the source field, amount_coverage_note for missing amounts, and the nuance that recipient_country reflects HQ country, not program location. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy with multiple paragraphs explaining data sources. While well-structured, it could be more concise without losing essential information. The main purpose is front-loaded, but some details could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context for a complex tool with 8 parameters, multiple data sources, and an output schema. It explains how to handle different funder types, the source field, and caveats like amount_coverage_note and recipient_country interpretation. Very thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minor additional details like 'funder_id accepts bare UUID or prefixed id' and 'purpose_keyword useful for topic narrowing,' but overall it does not significantly enhance the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'View grants made by a funder across IRS, web-extracted, and registry records.' This is a specific action on a resource, and the mention of multiple data sources distinguishes it from siblings like get_funder_profile or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for ANY funder when the user asks about grants given' and explains when to use funder_id instead of ein (e.g., European funders). It does not explicitly state when not to use it, but the context is clear enough.
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 ProfileARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds important behavioral details: at least one identifier must be supplied, and the polymorphic behavior for different funder types. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses a few sentences to convey necessary details without redundancy. Could be slightly more structured but is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. It covers polymorphic identifiers, usage context, and required parameters, making it complete for a profile retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning by explaining the polymorphic id pattern, noting that search_funders returns both fields, and that at least one is required. This provides helpful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed profile information for a specific funder.' It also differentiates from siblings like search_funders (returns many results) and get_990_summary (specific subset) by explaining the polymorphic identifier pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this after searching for funders, providing clear context. It explains how to pass identifiers from search_funders results, but does not explicitly exclude alternative tools like get_990_summary for similar tasks.
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 StatisticsARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint: true, but the description adds significant behavioral context: it calculates aggregate statistics from multiple sources, provides lifetime totals, focus areas, geographic distribution, and year-over-year trends. This goes beyond what annotations provide and helps the agent understand the tool's scope and data integration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: first sentence captures purpose, second paragraph details data sources and output. It is fairly concise with no filler, but could be slightly tighter (e.g., 'Pass ein or funder_id' could be rephrased). Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple data sources, aggregate stats) and the presence of an output schema (not shown but exists), the description adequately covers what the tool does and what it returns (lifetime totals, focus areas, distribution, trends). No major gaps for an agent to misunderstand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions, but the description adds value by explaining the context for each: 'Pass ein for US 990 foundations' clarifies when to use ein vs funder_id. It also explains that either parameter is needed, though both are technically optional. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive giving statistics for a funder.' It specifies multiple data sources (IRS 990-PF, web-extracted grants, 360Giving, etc.) and distinguishes it from sibling tools like get_990_summary (focused on single source) and get_funder_profile (profile data). The verb 'get' and resource 'statistics' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each parameter: 'Pass ein for US 990 foundations, or funder_id for non-990 funders.' It implies when to use the tool (for comprehensive stats) but does not explicitly state when to avoid it or mention alternatives. Sibling tools exist for more focused data, but no direct comparison.
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 CodesARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description reinforces 'Browse' as read-only. However, it does not disclose additional behavioral traits like rate limits or response format, but with an output schema present, the burden is lower. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two clear sentences, front-loaded with the purpose, and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is nearly complete. It could include a brief note on return structure, but not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters well (100%), and the description adds minimal extra meaning beyond the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Browse NTEE classification codes' and explains they classify nonprofits. It distinguishes itself from sibling tools which focus on 990s, grants, and funder profiles, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'helps you find the right NTEE code for searching or understanding a foundation's focus area', implying when to use. It lacks explicit when-not or alternatives, but no sibling tool competes directly, so it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkHealth CheckARead-onlyInspect
Check server health and connectivity.
Returns: Dictionary with health status including: - status: "healthy" or "unhealthy" - version: Server version - environment: Current environment (dev/staging/prod)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint=true, and description details return fields (status, version, environment), fully transparent with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but includes useful return details; could be slightly more succinct but not overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a no-parameter health check tool; description, annotations, and output schema (inferred) provide full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds return value structure, which is clear and helpful beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks server health and connectivity, distinguishing it from sibling tools that focus on funder data and grants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives, but it's implicit as a health check, and sibling tools are unrelated, so minimal guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_toolsList Available ToolsARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'list' and 'get detailed help' aligns. It adds value by specifying the two modes of operation, but doesn't introduce behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three lines: a title sentence, a line about discoverability, and a line about usage. Every sentence is meaningful and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter and an output schema. Description covers both usage modes completely, with no missing context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a description for tool_name. Description enhances by explaining the effect of presence/absence of the parameter, which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available MCP tools' and distinguishes between listing all and getting detailed help for a specific tool. This separates it from sibling tools which are specific to data retrieval or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use without parameters (list all) and when to provide a tool name (get detailed help). No ambiguity about usage context.
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 JobsARead-onlyInspect
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.
| 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_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. Defaults to hiding `philanthropy_operations` (foundation finance/HR/IT/COO). Pass an empty list to disable the default and include every category. | |
| posted_within_days | No | Recency window in days (0-730). Set 0 to disable. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the readOnlyHint annotation: it is backed by a weekly scrape of ~50K pages, uses GPT-5.4-mini classification, and explicitly lists what is excluded by design. It also explains the data source and filtering logic, providing full transparency about the tool's operation and limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, bulleted category list, and a concluding exclusion section. While it is relatively long, the length is justified by the tool's complexity (12 parameters, 8 categories). It is front-loaded and each section serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers input semantics comprehensively, including data source, filtering options, and usage patterns. It could benefit from a brief example query, but it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers all 12 parameters (100% coverage), the description adds significant semantic value by explaining each category with examples, providing usage examples for the query parameter, clarifying the relationship between state and country, describing the sort behavior, and detailing the default exclude_categories behavior. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search OPEN PHILANTHROPY JOBS at grantmaking foundations.' It specifies the verb 'search' and the resource 'funder jobs', and distinguishes itself from sibling tools like search_funders (which finds foundations) and search_open_grants (which finds grants) by focusing specifically on job listings. The inclusion of an 8-category taxonomy and explicit exclusions further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful guidance on when to use this tool, including a compositional pattern (search_funders → search_funder_jobs with funder_eins for cause-area searches) and explicit exclusions. However, it does not explicitly mention alternative tools for non-philanthropy jobs, though the sibling context and exclusions help imply boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fundersSearch GrantmakersARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name to filter by (case-insensitive). Example: "San Francisco", "New York" | |
| limit | No | Maximum number of results to return (1-50) | |
| 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. | |
| 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. | |
| 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. Useful for hiding operating nonprofits that surface with large "annual_grants" but are not actually grantmakers — e.g., exclude_funder_types=["operating_nonprofit"] hides PATH and similar operating organizations. | |
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering behavior (multi-word ranked by relevance, simple browse by total assets) beyond the readOnlyHint annotation. No contradictory or omitted behavioral traits. Adds context without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured paragraphs: main purpose, usage contexts and ordering behavior, sibling differentiation. Front-loaded with key information. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters with 100% schema coverage, readOnlyHint annotation, and output schema present, the description covers purpose, usage, behavioral nuances, and sibling differentiation comprehensively. Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds high-level grouping (name, topic, location, size, NTEE) but no unique semantic enrichment beyond what schema provides. Adequate baseline given coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool searches grantmaking organizations by name, topic, or location. The verb 'look up' combined with specific resource 'grantmaking organizations' gives precise purpose. Distinguished from sibling search_open_grants explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: known funder name, cause area alignment, or browsing by location/size/NTEE. Provides clear alternative: 'Use search_open_grants when the user needs active grant programs or RFPs.' This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_open_grantsSearch Open GrantsARead-onlyInspect
Search open grant opportunities from Kindora's active foundation-program corpus and federal government grants.
Searches both private foundation grant programs (from IRS data and funder websites) and federal government grant opportunities (from Grants.gov). 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)
| Name | Required | Description | Default |
|---|---|---|---|
| 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" | |
| 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 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 | Country name for non-US geographic filtering. Returns programs whose geographic_focus is tagged for that country plus any tagged Global / International / Worldwide. 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", "Mexico", "Global" | |
| 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 | Only show nonprofit-eligible government grants. Default: True |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses extensive behavioral details beyond the readOnlyHint annotation: natural language understanding, stemming, query syntax (phrases, exclusion), browsing mode, parameter interactions (state vs country), and defaults. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. It is comprehensive yet concise, with every sentence adding value. Query syntax is clearly presented in a list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, full-text search, multiple sources), the description is remarkably complete. It covers all parameter behaviors, default values, search mechanics, and edge cases like mixing state and country. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema, such as explaining that query uses stemming, state returns nationally available programs as well, source parameter preference, and country fallback/restriction. Schema coverage is 100%, but the description enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches open grant opportunities from both private foundation and federal government sources. It provides the specific verb 'Search' and resource 'open grant opportunities', and distinguishes from sibling tools like search_funders by focusing on grants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool, including a preference to omit source parameter for broader results, and explains the query syntax. However, it does not explicitly state when not to use this tool or directly compare with alternatives like search_funders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!