nonprofit-explorer-mcp-server
Server Details
MCP server for nonprofit financials via ProPublica — IRS Form 990 data for 1.8M+ nonprofits.
- 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.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: searching for organizations, retrieving organization profiles, and retrieving filings. No ambiguity or overlap exists between them.
All tool names start with 'nonprofit_' followed by a clear verb_noun pattern: search, get_organization, get_filings. Consistent and predictable.
Three tools is minimal but appropriate for this niche domain. The set covers the primary operations without being too sparse, though additional tools like comparing organizations could be justified.
The tool surface covers search, organization details, and filings, which are the core needs. Missing features like bulk operations or advanced filtering are minor gaps but do not hinder basic use.
Available Tools
3 toolsnonprofit_get_filingsGet Nonprofit FilingsARead-onlyIdempotentInspect
All Form 990 filings for a tax-exempt org by EIN: year-by-year revenue, expenses, assets, program-expense ratio (with inputs shown), executive compensation, and source PDF/XML links. Use for trend analysis, due diligence, and accessing primary 990 documents. The filing year (tax_prd_yr) is the fiscal year of the return — data lags 1–2 years; always cite the year. Program expense ratio is computed as (total_expenses − officer comp − other wages − fundraising) / total_expenses for 990/990-EZ; not available for 990-PF. Also returns filings_pdf_only — older filings with a PDF but no extracted financial data. Data from ProPublica Nonprofit Explorer, sourced from IRS Form 990 filings.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Employer Identification Number. Use nonprofit_search to resolve an org name to its EIN. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ein | Yes | Employer Identification Number as integer. |
| name | Yes | Legal org name per IRS. |
| filings | Yes | Filings with extracted financial data, sorted newest first. |
| data_source | Yes | ProPublica + IRS attribution text. |
| propublica_url | Yes | ProPublica Nonprofit Explorer URL for this org. |
| filings_pdf_only | Yes | Older filings with a PDF but no extracted financial data. |
| total_filings_pdf_only | Yes | Count of PDF-only filings (no extracted data). |
| total_filings_with_data | Yes | Count of filings with extracted financial data. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint and idempotentHint to true. Description adds key behavioral details: data source (ProPublica/IRS), 1-2 year lag, computation of program expense ratio, and distinction of filings with PDF only. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but not overly verbose. It front-loads the main purpose and data types, then adds usage context and limitations. Could be slightly more concise by reducing redundancy in the first sentence.
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 output schema exists (not shown), description does not need to detail return values. It covers data specifics, computation logic, limitations, and source attribution comprehensively for a single-parameter 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?
Only one parameter (ein) with 100% schema coverage including format details and cross-reference to nonprofit_search. Description adds minimal extra meaning beyond the schema's description; the utility hint about resolving name to EIN is useful but not essential.
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 retrieves 'All Form 990 filings for a tax-exempt org by EIN' and lists specific financial data points. It differentiates from siblings by focusing on filings rather than organization details (nonprofit_get_organization) or search (nonprofit_search).
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 use cases: 'trend analysis, due diligence, and accessing primary 990 documents.' Mentions limitations like data lag and unavailability of program ratio for 990-PF, and directs to use nonprofit_search for resolving name to EIN. However, it does not explicitly say when not to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nonprofit_get_organizationGet Nonprofit OrganizationARead-onlyIdempotentInspect
Full profile for a single tax-exempt org by EIN: legal name, address, NTEE classification, 501(c) type, IRS ruling date, and a financial snapshot from the most recent Form 990 filing (revenue, expenses, assets, net assets, and the source PDF link). Use nonprofit_search first if you only have an org name — this tool requires an EIN. Data lags 1–2 years; the tax year is shown prominently. Data from ProPublica Nonprofit Explorer, sourced from IRS Form 990 filings.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | Yes | Employer Identification Number. Accepts integer (530196605) or string with optional hyphen ("53-0196605"). Obtain from nonprofit_search results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ein | Yes | Employer Identification Number as integer. |
| city | Yes | City. Null when not on record. |
| name | Yes | Legal org name per IRS. |
| state | Yes | Two-letter state abbreviation. Null when not on record. |
| strein | Yes | EIN in "XX-XXXXXXX" format. |
| address | Yes | Street address. Null when not on record. |
| zipcode | Yes | ZIP code. Null when not on record. |
| ntee_code | Yes | Full NTEE code (e.g., "E210" = hospital). Null when unclassified. |
| sort_name | Yes | Alternate or subtitle name from the org record. Null when absent. |
| data_source | Yes | ProPublica + IRS attribution text. |
| ruling_date | Yes | ISO date of IRS recognition (e.g., "1946-07"). Null when not on record. |
| asset_amount | Yes | Most recent IRS BMF total assets in USD. Null when not reported. |
| filing_count | Yes | Total filings with extracted data on record. |
| income_amount | Yes | Most recent IRS BMF total income in USD. Null when not reported. |
| latest_filing | Yes | Financial snapshot from the most recent Form 990. Null if no filings_with_data are available. |
| propublica_url | Yes | ProPublica Nonprofit Explorer URL for this org. |
| revenue_amount | Yes | Most recent IRS BMF total revenue in USD. Null when not reported. |
| subsection_code | Yes | 501(c) subsection number (e.g., 3 = public charity). Null when not classified. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable context about data lag (1-2 years), source (ProPublica, IRS Form 990), and that it returns a single org, complementing the 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?
Two sentences efficiently convey purpose, usage, and data characteristics. Information is front-loaded, 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?
With an output schema present, the description covers all necessary context: what the tool does, when to use it, data freshness, and source. No gaps remain.
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 description of the ein parameter (integer or string formats). The description reinforces that the EIN comes from nonprofit_search and that it's required, adding value 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 it returns a 'full profile for a single tax-exempt org by EIN' and enumerates specific fields (legal name, address, NTEE classification, etc.). It distinguishes from siblings by directing to nonprofit_search for name-only queries.
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 says to use nonprofit_search first if only have an org name, and that this tool requires an EIN. Also mentions data lag and source, providing clear when-to-use and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nonprofit_searchSearch NonprofitsARead-onlyInspect
Search 1.8M+ IRS-recognized tax-exempt organizations by name, keyword, city, or phrase. Optionally narrow by US state, NTEE major sector (1–10), or 501(c) subsection type. Returns EINs — pass them to nonprofit_get_organization or nonprofit_get_filings for details. Results are paginated at 25 per page; use the page parameter and num_pages to paginate. Total results cap at 10,000 in the API; if total_results === 10000 the actual count may be higher. Supports quoted phrases ("Red Cross"), required terms (+evanston), excluded terms (-dental). Data from ProPublica Nonprofit Explorer, sourced from IRS Form 990 filings.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-indexed page number. 25 results per page. Total pages is in num_pages. Increment to paginate large result sets. | |
| query | Yes | Keyword search string. Searched against org name, alternate name, and city in order of relevance. Supports: quoted phrases ("Red Cross"), required terms (+evanston), excluded terms (-dental). Empty string returns all orgs within the active filters. | |
| state | No | Two-letter US state abbreviation (e.g., "WA", "NY"). Use "ZZ" for foreign entities. Restricts results to orgs headquartered in that state. | |
| ntee_category | No | NTEE (National Taxonomy of Exempt Entities) major group integer (1–10). 1=Arts/Culture/Humanities, 2=Education, 3=Environment/Animals, 4=Health, 5=Human Services, 6=International/Foreign Affairs, 7=Public/Societal Benefit, 8=Religion Related, 9=Mutual/Membership Benefit, 10=Unknown/Unclassified. | |
| subsection_code | No | 501(c) subsection code. "3" = public charity (most common — donations tax-deductible), "4" = social welfare org, "6" = business league/trade association, "92" = 4947(a)(1) nonexempt charitable trust. Filters by tax status, not sector. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cur_page | Yes | Current page (zero-indexed). |
| num_pages | Yes | Total pages available (total_results / 25, ceiling). |
| data_source | Yes | ProPublica + IRS attribution text. |
| organizations | Yes | Matching organizations for the current page. |
| total_results | Yes | Total matching orgs (up to 10,000 — the API ceiling). If 10000, actual count may be higher. |
| active_filters | Yes | Active filters echoed back for verification. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds significant behavioral details: pagination (25 per page, cap at 10,000), search syntax (quoted phrases, required/excluded terms), data source (ProPublica, IRS Form 990), and the fact that results are EINs. This fully informs the agent of the tool's behavior.
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-structured paragraph that front-loads the core purpose and efficiently packs all necessary details without redundancy. Every sentence adds value, covering scope, parameters, pagination, limits, and integration.
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 (5 parameters, output schema exists), the description is thorough: it explains pagination mechanics, result caps, search syntax, and how to use results with siblings. It leverages the output schema implicitly by noting returned EINs, making it complete for agent 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?
Schema coverage is 100%, but the description adds substantial context: it explains the query searches name, alternate name, and city; state accepts 'ZZ' for foreign entities; ntee_category is mapped to sectors; subsection_code has examples like '3' for public charity. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches over 1.8M IRS-recognized tax-exempt organizations by name, keyword, city, or phrase. It explicitly mentions returning EINs and directs users to sibling tools for details, effectively distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to search nonprofits) and provides context on pagination, search syntax, and data limits. It also suggests how to proceed after searching (pass EINs to other tools). However, it does not explicitly state when not to use it or list alternative use cases.
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!