This server acts as a proxy to Kindora's grant discovery platform, enabling research on foundations, funders, open grants, and philanthropy jobs within ChatGPT using public IRS 990 and Grants.gov data.
Search for grantmakers (search_funders): Find grantmaking organizations by name, cause area, location, assets, funder type, NTEE code, or country — covering 174K+ US foundations and 32K+ European funders.
Search open grant opportunities (search_open_grants): Discover open grants and RFPs across 172K+ foundation programs and federal Grants.gov listings, with filters for topic, deadline, award size, state, agency, and source.
Search philanthropy jobs (search_funder_jobs): Find open jobs at grantmaking foundations by keyword, location, role category, remote status, or specific funder.
Get funder profiles (get_funder_profile): Retrieve detailed profiles for a specific foundation by EIN, including legal name, location, financials, leadership, and website.
Get IRS 990 financial summaries (get_990_summary): Access 990/990-PF financial summaries and year-over-year trends (revenue, assets, grants paid) for up to 10 years of filings.
List individual grants (get_foundation_grants): View grants a foundation has made from its 990-PF filings, filterable by year, recipient location, NTEE code, or grant purpose keyword.
Get aggregate giving statistics (get_funder_stats): Retrieve lifetime totals, average/median grant sizes, top focus areas, and geographic distribution of giving for a foundation.
Browse NTEE codes (get_ntee_codes): Look up or search NTEE nonprofit cause-area classification codes for use as filters in other tools.
Health check (health_check): Verify that the upstream Kindora service is reachable and operational.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kindora-for-ChatGPT MCP server Find foundations that fund environmental causes."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python FastMCP server that re-exposes Kindora's public funder and grant tools so you can add them to ChatGPT as a custom MCP connector (Developer mode / Apps). It is a thin proxy: every tool forwards to the live Kindora MCP endpoint and returns the result unchanged.
ChatGPT can't run a local repo; it connects to a hosted HTTPS URL. This server needs no API keys (Kindora's free tier is open), so hosting it is one click, no Terminal, no .env.
Click the button, sign in to Render with GitHub, and approve. Render reads render.yaml and builds the container. First deploy takes ~2 minutes.
Copy the service URL Render gives you and add /mcp to the end, e.g. https://kindora-chatgpt-mcp.onrender.com/mcp.
In ChatGPT: Settings -> Connectors (Apps) -> Advanced -> Developer mode, then Create connector, paste the URL, choose No authentication, and save. Enable it from the "+" menu in any chat.
That's the whole install. (Render's free tier sleeps when idle, so the first request after a quiet spell takes 30-60 seconds to wake. Fly.io, below, stays warmer.)
Related MCP server: Personal Assistant MCP Server
Kindora is a grant-discovery platform for nonprofits. Its MCP server is a read-only, free-tier service over public IRS 990 / 990-PF filings and Grants.gov opportunities, covering 174K+ US foundations, 32K+ European funders, and 43K+ open grants. The upstream server exposes ten tools across discovery, profile, financials, and reference categories. This wrapper mirrors the nine that matter for ChatGPT (it drops the upstream list_tools helper, which is redundant since MCP clients enumerate tools natively).
Tool | Purpose |
| Find grantmakers by name, cause area, or location |
| Find open opportunities / RFPs by topic (foundation + government) |
| Find open philanthropy jobs at foundations |
| Detailed profile for one foundation (by EIN) |
| IRS 990 financial summary and trends (by EIN) |
| Individual grants a foundation has made (by EIN) |
| Aggregate giving statistics (by EIN) |
| Browse/search NTEE cause-area codes |
| Upstream health probe |
All tools are annotated readOnlyHint: true, so ChatGPT runs them without write-confirmation prompts.
ChatGPT Developer mode can connect to any remote MCP server, so a wrapper is optional. It earns its place when you want one endpoint you control: curated tool descriptions, read-only annotations, a place to add auth / rate limiting / logging, header injection for a Kindora key, or to pin a specific upstream URL. If you want none of that, you can skip this and add https://kindora-mcp.azurewebsites.net/mcp/ to ChatGPT directly.
.
├── server.py # the MCP server (all nine tools)
├── requirements.txt # runtime dependency (fastmcp)
├── pyproject.toml # packaging + pytest config
├── test_server.py # offline tests (no network needed)
├── Dockerfile # container image for hosting
├── fly.toml # one-command deploy to Fly.io
├── render.yaml # one-click deploy to Render
├── .env.example # configuration reference
├── .github/workflows/ # CI (runs the tests)
├── LICENSE # MIT
└── README.mdPython 3.10+
A way to host a public HTTPS URL if you want to use it with ChatGPT (Docker + any host, or the included Fly/Render configs).
git clone https://github.com/wayanvota/kindora-chatgpt-mcp.git
cd kindora-chatgpt-mcp
pip install -r requirements.txtpython server.pyUse this for local testing or to add the server to a stdio MCP client (e.g. Claude Desktop).
pip install -e ".[dev]"
pytestThe suite is offline: it checks tool registration, the read-only annotations, and the upstream-response normalization with a stubbed client. It does not make a live call to Kindora.
ChatGPT connects to a publicly reachable HTTPS URL, so the server must run with the streamable-HTTP transport behind a public host.
TRANSPORT=http HOST=0.0.0.0 PORT=8000 python server.py
# serves MCP at http://<host>:8000/mcpOr with Docker:
docker build -t kindora-chatgpt-mcp .
docker run -p 8000:8000 kindora-chatgpt-mcpPut it behind TLS (a reverse proxy, or a platform like Fly.io / Render / Railway / Cloud Run) so the final URL is https://your-domain/mcp.
This repo ships configs for two free-tier hosts that give you a public HTTPS URL:
Fly.io (fly.toml):
fly launch --no-deploy --copy-config --name <your-app>
fly deploy
# URL: https://<your-app>.fly.dev/mcpRender (render.yaml): push the repo to GitHub, then in Render choose New + -> Blueprint and pick the repo. URL: https://<service>.onrender.com/mcp.
Enable Developer mode: Settings -> Connectors (Apps) -> Advanced -> Developer mode. (Available on Plus, Pro, Business, Enterprise, and Edu plans.)
Connectors -> Create / Add custom connector.
Enter your public URL, e.g. https://your-domain/mcp.
Authentication: No authentication (this proxy and Kindora's free tier are open). Add OAuth here only if you put your own auth in front.
Save, then enable the connector in a chat (the "+" / tools menu in the composer).
Developer mode does not require the search/fetch compatibility tools that ChatGPT's Deep Research connectors need; it accepts arbitrary named tools, which is why all nine Kindora tools are exposed directly.
All via environment variables (see .env.example):
Variable | Default | Notes |
|
|
|
|
| HTTP bind host |
|
| HTTP port |
|
| HTTP path |
|
| Upstream to proxy |
| (unset) | Forwarded as |
|
| Upstream call timeout (seconds) |
Confirm the upstream URL against your Kindora connector listing. If Kindora moves the endpoint, set
KINDORA_MCP_URLand nothing else changes.
Read-only / public data. Nothing here writes. Data is public IRS 990 and Grants.gov.
Rate limits. Kindora's free tier is roughly 100 requests/hour for anonymous users; the proxy inherits that.
Country fields in grant data reflect the recipient's HQ country, not where program work is implemented.
Verify before publishing facts. Treat tool output as leads, not citations: confirm a foundation's current giving and open RFPs against the funder's own filings or site.
Get an IRS 990 / 990-PF financial summary and year-over-year trends for a foundation.
Returns per-year revenue, end-of-year assets, grants paid, mission text, and computed trends for assets, grants, and revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Foundation EIN, 9 digits, with or without hyphen. | |
| years | No | Number of years of filings to return, 1-10 (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and open-world. Description adds that it computes trends and returns specific fields, but does not disclose potential missing data or edge cases. With annotations covering safety, the description adds moderate context.
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 concise sentences: first states purpose, second lists returned data. No redundant or unnecessary 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 two well-described params and no output schema, the description lists returned fields adequately. Missing details on error cases or data freshness, but overall sufficient for a simple 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?
Input schema has 100% parameter description coverage. The description adds meaning by listing returned fields, which informs how the 'years' parameter affects the output. Provides 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?
Description clearly states it retrieves IRS 990 financial summary and year-over-year trends, listing specific data fields (revenue, assets, grants, mission). This distinguishes it from sibling tools like get_foundation_grants or get_funder_profile.
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 guidance on when to use this tool versus alternatives. The purpose is implied by name and description, but no when-not-to or alternative directives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List individual grants a foundation has made, from its 990-PF filings.
Ordered largest-first with aggregate stats. Each grant reports recipient HQ country and US state when known. Note: recipient_country is where the grantee is registered, not necessarily where program work happens.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Foundation EIN, 9 digits, with or without hyphen. | |
| year | No | Optional filing year filter (e.g. 2023). | |
| ntee_code | No | Optional NTEE code to filter recipients (e.g. "B41", "E"). | |
| recipient_country | No | ISO 3166-1 alpha-2 recipient HQ country (e.g. "IN", "CH", "ZA"). | |
| recipient_state | No | Two-letter US state code for recipient HQ. | |
| purpose_keyword | No | Case-insensitive substring matched against grant purpose (e.g. "vaccine", "digital health"). | |
| limit | No | Max grants, 1-50 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description adds useful behavioral context: grants are ordered largest-first, include aggregate stats, and note the meaning of recipient_country. This goes beyond annotations without 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 highly concise: two sentences plus a note, front-loaded with the main purpose. Every sentence adds value, 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 tool has 7 parameters, no output schema, but good annotations, the description covers the main purpose, ordering, and data source. It lacks details on pagination or result limits, but the schema covers those, so it is largely 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 coverage is 100%, with each parameter already having a clear description. The tool description does not add any extra meaning or context about parameters beyond what the schema provides, earning baseline 3.
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 'List individual grants a foundation has made, from its 990-PF filings,' specifying the verb, resource, and data source. It also notes ordering and aggregate stats, distinguishing it from sibling tools like search_open_grants which search across foundations.
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 usage for listing grants from a specific foundation's filings but lacks explicit guidance on when to use this tool versus alternatives like search_open_grants. No exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a detailed profile for one foundation by EIN.
Returns legal name, location, financials (total assets, annual grants), leadership, classification (foundation type, NTEE), and website. Use search_funders first to find the EIN.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Foundation EIN, 9 digits, with or without hyphen ("94-3136777" or "943136777"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so description reasonably focuses on content (fields returned). It adds useful context about financials, leadership, classification, and website, which goes beyond what annotations provide.
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 efficient sentences: first states purpose, second gives usage guidance. No extraneous words, front-loaded with key action.
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 low complexity (1 param, no output schema), description covers all necessary aspects: purpose, prerequisite workflow, and returned fields. No gaps for an agent to use 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?
Schema already has 100% coverage with detailed description (9 digits, hyphen allowed). Description only mentions 'by EIN' without additional semantic value, warranting baseline score.
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 'Get a detailed profile for one foundation by EIN' with specific verb 'get' and resource 'foundation profile'. It lists returned fields, distinguishing it from siblings like search_funders (which finds EIN) and get_990_summary (which returns tax form data).
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 instructs to 'Use search_funders first to find the EIN', providing clear when-to-use guidance and implying an alternative workflow. This precludes misuse and clarifies prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate giving statistics for a foundation.
Lifetime totals, average/median/min/max grant size, top NTEE focus areas, US-state and recipient-HQ-country distribution (each with avg grant size), a non_us_recipient_pct headline, and a year-by-year breakdown. Useful for prospect targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Foundation EIN, 9 digits, with or without hyphen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint, openWorldHint) and adds behavioral context by detailing the types of aggregated statistics returned. It does not introduce contradictions or undisclosed side effects.
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 a single, well-organized paragraph: a concise summary followed by a list of metrics and a usage statement. Every sentence adds value without redundancy.
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 one parameter and no output schema, the description adequately explains the return value in detail (lifetime stats, distributions, etc.). It provides sufficient context for an agent to understand what to expect.
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 fully describes the single parameter (ein) with a clear explanation, so schema coverage is 100%. The description does not add extra parameter information, aligning with the baseline score of 3.
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 gets aggregate giving statistics for a foundation, listing specific metrics like lifetime totals, averages, NTEE areas, and year-by-year breakdowns. This distinguishes it from sibling tools that provide detailed grant lists or 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?
The description mentions it is 'useful for prospect targeting,' providing a usage hint. However, it does not explicitly state when to use this tool versus alternatives like get_foundation_grants or get_funder_profile, nor does it specify exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse or search NTEE classification codes for cause areas.
Call with no arguments to list all 26 major categories. Filter by category letter or search by description to find codes for use with search_funders / get_foundation_grants.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Single letter A-Z (e.g. "E" Health Care, "B" Education, "P" Human Services). | |
| query | No | Search term against code descriptions (e.g. "education", "youth development"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint; the description adds that the tool is for browsing/searching and can list all categories with no arguments. It does not contradict annotations and provides reasonable behavioral context, but could detail output format or pagination.
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 sentences, front-loading the purpose and providing concise usage instructions with 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?
For a simple lookup tool with no output schema, the description is complete: it explains both usage modes, links to sibling tools, and context signals show no missing elements.
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 adequate parameter descriptions. The description adds no new semantic detail beyond the schema, matching the baseline of 3 for full 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?
The description clearly states the tool browses or searches NTEE classification codes, and distinguishes its purpose by linking to sibling tools like search_funders and get_foundation_grants. It also explains two modes: listing all categories or searching by category/query.
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 tells when to use each mode ('Call with no arguments to list all 26 major categories' and 'Filter by category letter or search by description'), and mentions the codes are for use with other tools, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the upstream Kindora service is reachable and healthy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds the specifics of checking for reachability and health, but does not detail what happens if unhealthy or what the exact response includes. It adds some context beyond annotations but not extensive.
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 a single clear sentence with no extraneous information. It is front-loaded and directly states the 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?
For a simple health check tool with no parameters, the description provides sufficient context to understand its purpose and operation. However, it does not specify the return format or what constitutes a healthy response, which could be useful given the lack of an output 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?
The tool has zero parameters and the schema coverage is 100% (trivially). No parameter descriptions are needed, so the description does not need to add meaning beyond the schema. Baseline is 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 verb 'check' and the resource 'upstream Kindora service', specifying reachability and health. This distinguishes it from sibling tools that deal with data retrieval about funders 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?
The description implies that the tool is for verifying service health before other operations, but it does not explicitly state when to use it or when not to. No alternatives are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find OPEN philanthropy jobs at grantmaking foundations.
Roles involved in giving money away, running philanthropic programs, or executive leadership of philanthropic work. Backed by a weekly scrape of ~50K funder career pages plus LLM classification. Use this for jobs/careers/hiring questions, NOT for grant opportunities (use search_open_grants for those).
For a cause area not covered by the categories below, first call search_funders to get matching funder EINs, then pass them here via funder_eins.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword search on job title (e.g. "program officer", "grants manager", "CEO"). | |
| category | No | One of grantmaking, program_leadership, executive_leadership, philanthropy_operations, program_support, development_for_grantmaking, philanthropy_communications, philanthropy_strategy. | |
| state | No | Two-letter US state code. | |
| country | No | Funder HQ country as ISO alpha-2 ("US", "GB", "DE") or name ("Germany"). | |
| funder_ein | No | Restrict to a single funder by EIN. | |
| funder_eins | No | Restrict to a list of funder EINs (up to 100). | |
| employment_type | No | e.g. "full_time", "fellowship". | |
| exclude_categories | No | Categories to hide. Defaults to hiding philanthropy_operations; pass [] to include every category. | |
| remote | No | Remote filter, e.g. "remote", "hybrid", "onsite". | |
| posted_within_days | No | Recency window in days, 0-730 (0 disables; default 365). | |
| sort_by | No | "funder_giving" (biggest funders first, default) or "recent". | funder_giving |
| limit | No | Max results, 1-50 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the data is 'backed by a weekly scrape of ~50K funder career pages plus LLM classification,' indicating data freshness and methodology. This adds context beyond the annotations (readOnlyHint, openWorldHint) which already indicate the tool is read-only and data may change externally. 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 at 8 sentences, with a clear first sentence stating purpose. It front-loads key information, uses bullet-like structure, and avoids redundancy. Every sentence adds value.
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, 100% schema coverage, no output schema, and no required params, the description covers purpose, scope, data source, usage boundaries, and workflow integration with siblings. It does not detail return format or pagination, but the limit parameter is documented. Overall highly complete for a search 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 description coverage is 100%, so most parameters are well-documented. The description adds value by explaining the relationship between search_funders and the 'funder_eins' parameter, and notes limits (up to 100). This extra context justifies a score above the baseline of 3.
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: 'Find OPEN philanthropy jobs at grantmaking foundations.' It specifies the verb, resource, and scope, and distinguishes itself from the sibling tool 'search_open_grants' by explicitly specifying that this tool is for jobs, not 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 tells when to use ('for jobs/careers/hiring questions'), when not to use ('NOT for grant opportunities'), and provides an alternative ('use search_open_grants for those'). It also gives a multi-step workflow for uncovered cause areas, instructing to call search_funders first and then pass funder EINs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find grantmaking organizations by name, cause area, or location.
Searches 174K+ US foundations plus 32K+ European funders from IRS 990 data. Use this to find aligned funders (including ones that fund by relationship, LOI, or annual cycle rather than a live RFP), or when the user names a specific funder. For active/open opportunities use search_open_grants instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Funder name or cause-area phrase. Topic searches work best with 2+ words (e.g. "Ford Foundation", "global health", "community foundation"). | |
| state | No | Two-letter US state code for funder HQ (e.g. "CA", "NY"). | |
| city | No | City name for funder HQ (case-insensitive). | |
| ntee_code | No | NTEE classification code to filter by (e.g. "E" Health, "B" Education). | |
| min_assets | No | Minimum total assets in dollars (e.g. 10000000). | |
| max_assets | No | Maximum total assets in dollars. | |
| has_er_grants | No | If true, only funders that make expenditure-responsibility grants (to non-501(c)(3) entities like PBCs, for-profits, foreign orgs). | |
| funder_type | No | Narrow to one type, e.g. "community_foundation", "family_foundation", "corporate_foundation", "private_operating", "independent_foundation". | |
| exclude_funder_types | No | Types to hide, e.g. ["operating_nonprofit"] to drop orgs that surface with large annual_grants but are not really grantmakers. | |
| country | No | One or more funder HQ countries for non-US funders (e.g. ["Germany", "Spain", "Netherlands"]). | |
| grantee_country_codes | No | ISO 3166-1 alpha-2 codes for where the funder's grantees are based (e.g. ["IN"], ["KE", "SF"]). | |
| limit | No | Max results, 1-50 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it searches 174K+ US and 32K+ European funders from IRS 990 data, implying a broad but possibly stale dataset. It does not mention pagination or exact return format, but overall provides useful behavioral 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 concise with two short paragraphs. The first sentence is a clear verb+resource statement. Every sentence serves a purpose: stating what it does, providing data source, and giving usage guidance with sibling differentiation. 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 (12 parameters) and lack of output schema, the description covers the core purpose, data sources, and when to use. It could mention output format (list of funders with details) for completeness, but the absence is minor given the clarity otherwise.
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 descriptions for all 12 parameters. The description adds no additional parameter-specific meaning beyond the schema, so the baseline of 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 tool finds grantmaking organizations by name, cause area, or location. It also distinguishes from the sibling tool search_open_grants by specifying that search_funders is for funders that may not have a live RFP, while the sibling is for active opportunities.
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 provides when to use (to find aligned funders, or when user names a specific funder) and when not to use (for active/open opportunities, use search_open_grants instead). It also adds context that these funders may fund by relationship, LOI, or annual cycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find OPEN grant opportunities and RFPs by topic or cause area.
The primary tool for finding grants. Searches 172K+ foundation programs and federal Grants.gov opportunities across program names, descriptions, focus areas, and beneficiary types, with stemming and natural-language matching.
Query syntax: natural language ("affordable housing for seniors"), quoted phrases ('"after school"'), and exclusion ("education -higher"). Omit query to browse broadly open programs sorted by upcoming deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Natural-language search (e.g. "STEM education for girls", "food bank hunger"). | |
| focus_area | No | Filter foundation programs by focus area (e.g. "Education", "Health"). | |
| agency | No | Filter government grants by agency (e.g. "Department of Education", "NSF"). | |
| state | No | Two-letter US state code; returns state-focused plus nationally available programs. | |
| country | No | Country name for non-US targeting (e.g. "India", "Kenya", "Global"). | |
| deadline_days | No | Deadline lookahead window in days, 1-365 (default 90). | |
| min_award | No | Minimum award amount in dollars. | |
| max_award | No | Maximum award amount in dollars. | |
| nonprofit_only | No | Restrict to nonprofit-eligible opportunities (default true). | |
| source | No | Limit to one source: "foundation" or "government". | |
| limit | No | Max results, 1-50 (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (results may change). The description adds valuable behavioral context: it uses stemming, natural-language matching, and searches across program names, descriptions, focus areas, and beneficiary types. No contradictions with annotations. Some limitations (like rate limits) are not mentioned but not critical.
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, about 5-6 sentences, front-loaded with purpose and scope. Every sentence adds value: scope, primary designation, search capabilities, query syntax, and browsing behavior. No fluff or repetition.
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 11 well-documented parameters, no output schema, and appropriate annotations, the description covers purpose, usage, query variants, and browse option. It does not describe return format explicitly, but for a search tool this is acceptable. Overall sufficiently complete for an agent to use 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?
Schema coverage is 100% with thorough parameter descriptions, so baseline is 3. The description adds minimal extra meaning beyond the schema, except for query syntax notes and the ability to browse by omitting query. This is helpful but does not significantly enhance 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?
Description clearly states the tool finds open grant opportunities and RFPs by topic, and identifies itself as the primary tool for grants. It specifies the scope (172K+ foundation programs and federal Grants.gov), using a specific verb+resource combination that distinguishes it from sibling tools like get_foundation_grants or search_funders.
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 clear context on when to use this tool (primary tool for finding grants) and query syntax. It offers examples for natural language, quoted phrases, and exclusion. However, it does not explicitly state when to avoid this tool or alternative tools, though the 'primary' implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_990_summaryget_foundation_grantsget_funder_profileget_funder_statsget_ntee_codeshealth_checksearch_funder_jobssearch_funderssearch_open_grantsScored across 9 tools
Each tool serves a clear, distinct purpose: foundation financials, grants, profiles, stats, search for funders/grants/jobs, NTEE codes, and health check. Descriptions explicitly differentiate between similar tools like search_funders, search_open_grants, and search_funder_jobs.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_990_summary, search_funders, health_check). No mixing of conventions like camelCase or inconsistent verb forms.
9 tools is well-scoped for a philanthropy-focused server, covering all major user needs: exploring foundations, grants, jobs, and NTEE codes, with a health check. Not too many to overwhelm, and each tool earns its place.
The tool set covers the full lifecycle of philanthropy research: finding funders and NTEE codes, retrieving detailed profiles and financial trends, listing individual grants, searching open grants and jobs, and system health. No obvious gaps for the intended use.
FastMCP server for TheBrain API — AI access to a personal knowledge graph, Tollbooth-monetized
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
