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.5/5 across 12 of 12 tools scored. Lowest: 3.9/5.
Each tool serves a distinct purpose: find_funders_for_peers uses peer-based collaborative filtering, search_funders does name/topic lookup, search_open_grants finds active RFPs, search_nonprofits searches recipients, get_funder_* tools provide different aspects of funder data, and utilities like health_check and list_tools are separate. No overlap.
Naming conventions are mixed: 'find_', 'get_', 'search_', 'health_check', 'list_tools', 'get_ntee_codes'. While verbs are descriptive, there is no single consistent pattern (e.g., all search_ or all get_). This could cause slight confusion.
12 tools is well-scoped for a foundation discovery server. Each tool addresses a clear need (prospecting, detail, financials, jobs, utilities) without being excessive or insufficient.
The tool set covers the full lifecycle of foundation research: finding funders (by peers, name, open grants), getting detailed profiles, grants, stats, financials, NTEE codes, and even funder jobs. The inclusion of recipient-side search (search_nonprofits) complements the funder side, leaving no obvious gaps.
Available Tools
13 toolsfind_funders_for_peersFind Funders for Peer OrgsARead-onlyInspect
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 plain-language description of the nonprofit (mission, cause, who it serves). Fallback that resolves well-funded peers by keyword over the IRS BMF; prefer peer_orgs when you can name a few peers.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | Plain-language description of the nonprofit (fallback). Example: "youth mental health services for teens". |
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 fully discloses the underlying data source (IRS 990-PF grant graph) and algorithm (collaborative filtering, merging funders across peers). It also states that results include real grant evidence. This goes well beyond the readOnlyHint annotation.
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, starting with a clear purpose, then how it works, inputs, and recommended workflow. Every section is concise and informative, with 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 complexity of peer-based prospecting, the description covers all necessary aspects: data source, methodology, input options, and output interpretation. The presence of an output schema reduces burden, but the description still adds value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining preferred usage of peer_orgs, the fallback role of org_description, and the effect of limit and min_amount. It also provides examples.
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 defines the tool's purpose: finding grantmakers that funded similar organizations using a grant graph. It distinguishes from sibling tools like search_funders and search_open_grants, making the unique value explicit.
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 this tool versus alternatives, recommends a workflow (establish mission, name peers), and explains the trade-offs between peer_orgs and org_description inputs.
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 NonprofitARead-onlyInspect
Find the foundations 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).
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) grants only. Government grants, corporate giving, and most donor-advised funding do NOT appear, so an empty result means "no tracked foundation reported a grant to this org", not "this org has no funders" — say exactly that.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of funders to return (1-50) | |
| min_amount | No | Minimum single-grant size in USD (default 1000) | |
| recipient_ein | No | EIN of the RECIPIENT nonprofit whose funders you want. | |
| recipient_name | No | Name of the recipient nonprofit (resolved via the IRS BMF registry when recipient_ein is not given). |
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 only declare readOnlyHint=true. The description adds critical behavioral details: it covers only US private-foundation grants from IRS 990-PF (2022-2026), explains that government and corporate giving are excluded, and clarifies what an empty result means. It also describes the name resolution process.
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 clear front-loading of the core purpose. Every sentence adds value, but the description is somewhat verbose for a tool with a clear schema and annotations. Slightly above average conciseness.
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 (4 parameters, output schema exists), the description covers all necessary aspects: purpose, usage guidance, parameter details, coverage limitations, and behavioral notes. The existence of an output schema reduces the need to explain return values, and the description is complete for effective agent use.
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%, baseline 3. The description adds extra context beyond the schema: it explains the precedence of recipient_ein over recipient_name, the coverage limitation for min_amount (default 1000), and the maximum limit. This additional guidance justifies a score of 4.
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 finds foundations that have granted to one specific nonprofit. It distinguishes from sibling tools like 'find_funders_for_peers' and 'get_foundation_grants' by emphasizing the reverse relationship and single-org scope.
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?
Provides explicit guidance on when to use this tool (for a single org) and when to use the alternative (find_funders_for_peers for multiple orgs). Includes example queries and clarifies the use of recipient_ein vs recipient_name.
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 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. | |
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds substantial context including data source (weekly scrape of ~50K pages), GPT classification, category taxonomy, and what is excluded. No rate limits or pagination details but already sufficient.
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 lengthy but well-structured with a clear front-loaded purpose, categories list, and exclusions. Every sentence adds value, though could be slightly more 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 the complexity of 13 parameters, the description covers categories, exclusions, filtering nuances (e.g., country vs state, recommended composite pattern with funder_eins), and what's excluded. Output schema exists, so return values need no explanation.
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?
With 100% schema coverage, baseline is 3. The description goes beyond by listing and explaining the 8 categories, providing examples for query, and clarifying filtering logic (e.g., state prefilter/post-filter, sort_by meanings).
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 'Search' and the resource 'OPEN PHILANTHROPY JOBS at grantmaking foundations'. It distinguishes from sibling tools like search_funders by focusing on job listings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on what is included (8 categories) and excluded by design (clinical, academic, etc.), but does not explicitly mention when to use this tool versus siblings like search_funders or search_nonprofits.
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) | |
| 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. Unrecognized names return an error that lists the known metros. 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. | |
| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent. The description adds behavioral details: ranking by relevance for multi-word searches and by total assets for simple browse/name fallback, data source (IRS data, 174K+ organizations), and default exclusion of operating entity types. This provides valuable context beyond 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, front-loading the core purpose and usage, and then adding important context. Every sentence is informative, though slightly verbose in the parameter-related part. Minor redundancy but overall 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 14 parameters with 100% schema coverage, an output schema, and a detailed description covering usage, behavior, and parameter relationships, the tool is fully self-contained. The description explains nuanced behaviors like operating entity exclusion and metro vs city semantics, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds extra meaning beyond schema descriptions, e.g., explaining when to prefer metro over city, and noting that topic searches work best with 2+ words. It doesn't repeat schema details but adds contextual guidance, warranting a 4.
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: 'Look up grantmaking organizations by name, topic, or location.' It distinguishes from sibling tools by explicitly mentioning that search_open_grants is for active grant programs, making the purpose and differentiation clear.
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 this tool: when the user knows the funder's name, wants aligned funders for a cause area, or wants to browse by location/size/NTEE code. It also advises when to use the alternative: 'Use search_open_grants when the user needs active grant programs or RFPs.' This covers both when to use and when not to use.
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)ARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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") → resolved to its MSA codes. Prefer over city for metro-area intent. | |
| query | No | Case-insensitive substring match on the organization name. | |
| state | No | 2-letter US state code (e.g. "IL"). | |
| sort_by | No | received (default) | revenue | funders | name. | received |
| 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. | |
| min_funder_count | No | Minimum distinct funders. |
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 details what results contain (990 financials, funding signals) beyond the minimal readOnlyHint annotation. It doesn't mention rate limits or destructive behavior, but the tool is read-only and the behavioral context is well covered.
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 clear sections, no wasted sentences, and is appropriately sized given the tool's complexity. It front-loads the essential purpose and use cases.
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 is complete for the tool's complexity: it explains the domain, data fields, and how to use it with siblings. The output schema exists so return values aren't needed. Minor omission like pagination details are present in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 87%, so baseline is 3. The description adds context for a key parameter (min_received as 'the key grantee-benchmarking filter'), but overall the schema already explains parameters well.
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 the universe of US nonprofits (recipient/grantee side) and distinguishes it from search_funders (grantmaker side). It uses specific verbs and resources, making the purpose unambiguous.
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 includes a dedicated 'CHOOSING THE RIGHT TOOL' section that explicitly contrasts this tool with search_funders and provides a use-case workflow (benchmarking, then looking up funders).
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" | |
| 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 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?
Describes behavioral traits beyond annotations: full-text search with natural language understanding, stemming, support for quoted phrases and exclusion, and the fields searched. Annotations declare readOnlyHint=true, aligning with the search behavior. 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?
Slightly long but well-structured with bullet points and clear sections. Every sentence adds value. Could be slightly more concise, but organization helps readability.
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, rich input schema, and existence of output schema, the description is very complete. It covers all aspects: query syntax, parameter interactions, defaults, and behavioral characteristics. No gaps noted.
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%, providing strong baseline. The description adds significant meaning beyond the schema: explains the topic parameter alias from MCP client behavior, preference for omitting source, country vs state differentiation, and examples for each parameter.
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 it searches open grant opportunities from Kindora's foundation programs and federal government grants. The verb 'search' and resource 'grant opportunities' are specific. It distinguishes from sibling tools like search_funders and search_nonprofits 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?
Provides extensive usage guidance: full-text search syntax, when to use state/country/source parameters, examples, and explicit preferences (e.g., omit source filter). Clearly tells when not to use certain options (e.g., government-only returns few results).
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!