MCP server for nonprofit financials via ProPublica — IRS Form 990 data for 1.8M+ nonprofits.
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.
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: search for organizations, retrieve an organization profile by EIN, and retrieve Form 990 filings by EIN. There is no overlap or ambiguity in what each tool does.
All tool names share the 'nonprofit_' prefix and use snake_case, but the pattern is not perfectly uniform: two use 'get_' (get_organization, get_filings) while one is just 'search' rather than 'search_organizations'. Still, the naming is predictable and readable.
Three tools is an appropriate, focused set for a nonprofit data explorer. Each tool addresses a core need: discovery, entity details, and financial filings, without unnecessary bloat.
The tool surface covers the full read-only workflow for exploring nonprofits: search to find EINs, fetch an organization profile, and retrieve all Form 990 filings. No obvious gaps exist for the stated purpose.
nonprofit_get_filingsGet Nonprofit FilingsAAll Form 990 filings for a tax-exempt org by EIN: year-by-year revenue, expenses, assets, liabilities, net assets, revenue breakdown, executive compensation, and source PDF 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. An organization that resolves but has filed no 990 returns an empty filings array with a notice, not an error. 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. |
| Name | Required | Description |
|---|---|---|
| ein | Yes | Employer Identification Number as integer. |
| name | Yes | Legal org name per IRS. |
| notice | No | Present when the organization resolved but Nonprofit Explorer holds no filing of any kind for it — names the org and why the filing history is empty. An empty filings array without this notice means the org has filings that carry a PDF but no extracted data; read filings_pdf_only. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints, but the description adds crucial behavioral context: data lags 1–2 years, empty filings array with notice for no filings, the existence of filings_pdf_only without extracted data, and data sourcing from ProPublica/IRS. This significantly exceeds annotation coverage.
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 front-loaded with the core function and data contents, then provides use cases and edge-case behavior in a logical flow. Every sentence earns its place, with no redundancy or filler.
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 a single well-documented parameter, an output schema is present, and the description still explains edge cases (no filings, PDF-only) and data lag, making the tool fully understandable for an agent to invoke 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% for the single ein parameter, extensively documenting integer/string formats and leading-zero handling. The description adds no new parameter-level meaning beyond saying 'by EIN,' so 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 opens with a specific verb+resource: 'All Form 990 filings for a tax-exempt org by EIN' and lists exact data contents (revenue, expenses, executive compensation, PDF links). It clearly distinguishes itself from sibling tools by focusing on filings, while explicitly referencing nonprofit_search for EIN resolution.
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?
States explicit use cases: 'Use for trend analysis, due diligence, and accessing primary 990 documents.' It also tells users to use nonprofit_search to resolve names to EINs, providing an alternative path. It lacks explicit 'when not to use' exclusions, 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.
nonprofit_get_organizationGet Nonprofit OrganizationAFull 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). Also returns the IRS Business Master File standing — whether contributions are deductible, exemption status, and public-charity vs. private-foundation classification. 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. |
| 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 | IRS Business Master File secondary name line (SORT_NAME) — an internal sort key such as a division or service-center label, not an alternate organization name. Null for most orgs. |
| deductible | Yes | Whether contributions to this org are tax-deductible, as "<IRS code> — <meaning>". Three states, not two: code 1 deductible, code 2 not deductible, code 4 deductible by treaty (foreign orgs). Null when the IRS Business Master File records no deductibility code. |
| 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 on record. |
| filing_count | Yes | Total filings with extracted data on record. |
| exempt_status | Yes | IRS exemption status as "<IRS code> — <meaning>"; code 1 is an unconditional exemption. This records what the IRS granted, not whether the exemption is still in force — the Business Master File is a lagging snapshot and automatic revocations are published separately. Null when the Business Master File records no status code. |
| income_amount | Yes | Most recent IRS BMF total income in USD. Null when not on record. |
| latest_filing | Yes | Financial snapshot from the most recent Form 990. Null if no filings_with_data are available. |
| bmf_tax_period | Yes | Tax period of the latest return recorded in the IRS Business Master File (e.g. "2025-06-01"). Often more recent than latest_filing.tax_prd_yr, which reflects the newest 990 ProPublica has extracted. Null when not on record. |
| propublica_url | Yes | ProPublica Nonprofit Explorer URL for this org. |
| revenue_amount | Yes | Most recent IRS BMF total revenue in USD. Null when not on record. |
| foundation_type | Yes | IRS foundation classification as "<IRS code> — <meaning>", separating public charities (codes 10–25) from private foundations (codes 2–4). Codes 0 (all organizations except 501(c)(3)) and 9 (suspense) fall outside both groups. Null when the IRS Business Master File records no foundation code. |
| subsection_code | Yes | 501(c) subsection number (e.g., 3 = charitable organization, covering both public charities and private foundations — see foundation_type to tell them apart). Null when not classified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds valuable behavioral context: data lag of 1–2 years, prominent display of tax year, and provenance (ProPublica Nonprofit Explorer from IRS Form 990 filings). This goes beyond the annotations without contradicting them, though it doesn't cover all edge cases (e.g., error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it opens with the core purpose, lists returns, then provides usage guidance and data caveats. Each sentence serves a distinct purpose—no filler or repetition. The length is appropriate for the complexity, and the organization makes it easy to scan.
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 single parameter, clear annotations, and existing output schema, the description is highly complete. It covers what data is returned, key limitations (data lag), usage prerequisites (EIN required), and data source. There are no significant gaps that would confuse an AI agent selecting or invoking the 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?
The input schema already provides 100% coverage of the 'ein' parameter, including detailed format examples and the instruction to obtain it from nonprofit_search. The description adds no new parameter-specific semantics beyond restating that an EIN is required. Baseline 3 is appropriate given the high schema 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's function: 'Full profile for a single tax-exempt org by EIN' and enumerates specific data fields (legal name, NTEE classification, financial snapshot, etc.). It also distinguishes itself from the sibling nonprofit_search by explicitly noting the EIN requirement, making the resource and scope 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 provides explicit usage guidance: 'Use nonprofit_search first if you only have an org name — this tool requires an EIN.' This directly states when to use an alternative and implies when to use this tool (when you have an EIN and need a full profile). This is clear, practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nonprofit_searchSearch NonprofitsASearch 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. A zero-match query and a page past the last one both return an empty organizations array with a notice rather than an error; only a page whose offset reaches that 10,000 cap is refused. 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, the secondary name line, 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, territory, or military postal code (e.g., "WA", "NY", "PR"). Case-insensitive — normalized to uppercase before filtering. A code outside that set is rejected rather than silently returning national results. Restricts results to orgs headquartered in that state. "ZZ" (foreign address) is accepted, but no organization in the index currently carries it. | |
| 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" = charitable/religious/educational organization (most common — includes both public charities and private foundations; nonprofit_get_organization returns foundation_type to tell them apart), "4" = social welfare org, "6" = business league/trade association, "92" = 4947(a)(1) nonexempt charitable trust. Filters by tax status, not sector. |
| Name | Required | Description |
|---|---|---|
| notice | No | Present when the response needs a caveat the domain fields cannot carry: a page that returned no organizations (distinguishing a zero-match query from a page past the end of the result set, and naming the next call), a total_results sitting on the API result ceiling rather than counting matches, or both at once in one string. Absent when the page is populated and the total is an exact count. |
| cur_page | Yes | Current page (zero-indexed). |
| per_page | Yes | Results per page applied by the API (25). |
| num_pages | Yes | Total pages available (total_results / 25, ceiling). The last valid page is num_pages - 1. |
| data_source | Yes | ProPublica + IRS attribution text. |
| page_offset | Yes | Zero-indexed offset of the first result on this page. Requests are refused once this reaches 10,000. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint: true. The description adds substantial behavioral detail: pagination at 25 per page, a 10,000 result cap with the total_results signal, specific behavior for empty results vs. cap refusal, query syntax (quoted phrases, +/-, -), and data provenance. This goes far beyond the annotation and gives the agent a precise mental model of side effects and failure modes.
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 dense but every sentence earns its place: purpose, filtering, pagination, edge cases, syntax, and data source. It is front-loaded with the primary action and scoped clearly. No filler 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 5 parameters, pagination, and multiple edge cases, the description covers all necessary operational details: query syntax, state validation, NTEE and subsection codes, pagination mechanics, cap behavior, empty results, and data source. The output schema exists and describes return fields, so no need to duplicate that.
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 value by explaining the overall search semantics (searching against name, secondary name, city) and how filters combine, plus the pagination contract and cap behavior. It also clarifies that subsection_code '3' includes both public charities and private foundations, which the schema hints at but does not fully explain. This lifts it above baseline.
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 opens with a specific verb ('Search') and resource ('1.8M+ IRS-recognized tax-exempt organizations'), and specifies search dimensions (name, keyword, city, phrase). It also explicitly distinguishes from siblings by noting that results should be passed to nonprofit_get_organization or nonprofit_get_filings for details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear 'when to use' context: narrow by state, NTEE sector, subsection code, and paginate with page/num_pages. It also references sibling tools for follow-up, providing an explicit alternative. Edge cases like zero-match queries and page-past-last are explained, guiding correct invocation.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.