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.8/5 across 3 of 3 tools scored.
Each tool serves a distinct purpose: search for organizations, get organization profile, and get filings. No overlap or ambiguity.
All tools follow a consistent 'nonprofit_<verb>' pattern with snake_case, making it easy to predict the function.
Three tools is somewhat minimal but covers the core workflow (search, get org, get filings) without being insufficient for the domain.
The set covers the primary operations for nonprofit data exploration. Minor gaps like batch retrieval or advanced filtering exist but don't impede basic workflows.
nonprofit_get_filingsGet Nonprofit FilingsAAll 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds context on data lag, program expense ratio computation, and distinction for filings_pdf_only. 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?
Concise and well-structured: starts with main purpose, then lists data, usage, computation details, and source. Every sentence provides necessary information 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's complexity, description covers data year lag, computation caveats for program expense ratio, availability of PDF links, and data source. Output schema likely handles return structure, so no gaps.
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 fully covers EIN parameter with both integer and string formats. Description adds value by explaining how to resolve an org name to EIN using nonprofit_search, enhancing usability.
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 retrieves Form 990 filings by EIN, listing specific financial data fields. It distinguishes from siblings by mentioning organization info and EIN resolution tools.
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 recommends use for trend analysis, due diligence, and accessing primary documents. Notes data lag and calculation details, though does not explicitly state 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.
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). 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 | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safety. The description adds valuable context: data lags 1-2 years, the tax year is shown, and the source (ProPublica Nonprofit Explorer from IRS Form 990). 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?
Two sentences are concise and front-loaded with key purpose. Every clause adds value: purpose, required parameter, data fields, usage guidance, data lag, and source. 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 an output schema (not shown but referenced), the description covers return values by listing included fields. Also explains data source and lag, providing complete context for a single-parameter, read-only 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 is 3. The description adds guidance: 'Obtain from nonprofit_search results' and clarifies EIN format (with or without hyphen). 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 retrieves a full profile for a single tax-exempt organization by EIN, listing specific data fields (legal name, address, NTEE, etc.) and explicitly distinguishes from sibling tool nonprofit_search by noting that this tool requires an EIN, while search can be used if only a name is available.
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 versus nonprofit_search: 'Use nonprofit_search first if you only have an org name — this tool requires an EIN.' Also mentions data lag and that the tax year is shown prominently, setting expectations.
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. 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all relevant behavioral traits: it is a read-only search (consistent with readOnlyHint annotation), returns EINs, supports complex query syntax, paginates with a cap, and sources data from ProPublica Nonprofit Explorer. It adds significant context beyond the annotation 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 a single, dense paragraph that front-loads the core purpose and then progressively adds details. Every sentence provides essential information without redundancy. It is concise and well-structured.
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, 1 required, 2 enums, output schema present), the description covers all necessary aspects: purpose, data source, return type, pagination, result limits, query syntax, filtering options, and relationship to sibling tools. 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?
With 100% schema description coverage, the description still adds substantial meaning beyond the schema. It clarifies query syntax (quoted phrases, required/excluded terms), explains the 'ZZ' state code for foreign entities, lists NTEE categories with names, and describes common subsection codes. This extra context helps the agent use parameters correctly.
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: searching 1.8M+ IRS-recognized tax-exempt organizations by name, keyword, city, or phrase. It specifies the return value (EINs) and explicitly differentiates from sibling tools by stating that EINs 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?
Provides comprehensive guidance: it explains when to use the tool (to search for nonprofits), how to paginate (page parameter and num_pages), mentions the 10,000 result cap, and gives examples of query syntax. It also names alternative tools for further details, fulfilling the 'when-not/alternatives' criterion.
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.