GrantData

View saved version →

---
name: azimuth-research
description: Search Azimuth nonprofit intelligence for a research topic or source and give a concise evidence-backed answer. Use for open-ended corpus lookup; use the focused entity or peer-funding skills for those workflows.
---

# Azimuth Research

Read [shared evidence rules](references/evidence-rules.md). Use Azimuth `search` and `fetch` for name/EIN and paper-title discovery. Inspect the chosen result before making claims; clarify plausible identity matches. Use the discovered catalog for actual tool availability.

Explain the evidence at the same level the tool supports:

- A warehouse aggregate is an observed funding signal. The organization profile URL identifies the entity but does not validate the aggregate amount. A linked IRS filing is an example for that funder-recipient pair, not proof of the whole aggregate.
- Grant history does not show an open application, a warm introduction, or current strategic fit. Say when those items need separate verification.
- A paper result identifies a source; inspect the linked paper before claiming a specific finding.

Give the user a concise answer, name the selected entities and years, link source-bearing records, and state the one or two material coverage limits. Do not use private files or infer private relationships from public graph paths.

This MCP search covers organization names and paper titles. If a longer phrase returns no match, retry the core entity name. Use the MCP result to identify the entity, known relationships, source links, and exact coverage gap. It is a starting point for research, not the only source the host assistant may use.

When the user asks about mission, programs, current status, or another claim that `fetch` cannot establish, use the host assistant's own web search if it is available. Search with the resolved legal name and EIN, then inspect an official organization or funder page, filing, or other primary source that speaks to the claim. A graph path, third-party discovery result, or website link can guide the query, but its summary is not confirmation. Cite the page actually checked, distinguish its date from historical MCP observations, and note any conflict. If web search is unavailable or no suitable source is found, give the useful MCP findings and mark the claim unverified.

For cohort or program-role questions, do not classify an organization from its name, NTEE, website URL, or grant rows alone. Check a program-specific source with native web search when possible; otherwise say the program evidence is missing.

Choose the focused workflow for the next job: `entity-evidence` for identity; `peer-funding-comparison` for selected peers/benchmarks; `issue-to-funding-map` for an issue landscape; `program-evidence` for studies and analogs; `funder-review` for current fit/access; `research-packet` for an artifact; `fundraising-strategy-process` for decisions across the whole process. The same guides are retrievable through `list_research_workflows` / `get_research_workflow` when exposed.

For conflicts, new discoveries and whole-org research use [research review](references/research-review.md). For any retain request follow [connection boundaries](references/connection-boundaries.md). Never assume a save or graph refresh happened from instructions alone.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: entity-evidence
description: Resolve a named nonprofit or funder to the right EIN and summarize its available Azimuth profile and source-backed funding signals. Use when identity, aliases, or observed organization evidence matter.
---

# Entity Evidence

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). Use `funder-review` for current qualification and `program-evidence` for an intervention/program case; this workflow resolves identity and observed records.

Search the name or EIN, inspect the candidate cards, and fetch the selected `org:<EIN>` result. If two plausible entities remain, present their names and EINs and ask which one the user means. Do not silently choose by a similar name or location.

Lead with the resolved legal entity and EIN. Give only the profile fields and funding observations returned by `fetch`; keep an unknown field unknown. The entity profile is an identity link, not proof of every funding amount. A linked IRS filing is an example for a funder-recipient pair, not a citation for the full aggregate. State when the result has only a warehouse aggregate and when the latest observed year is missing.

Separate three questions when they arise: who the organization is, what funding was observed, and whether a funder is a current prospect. The present tools answer the first two within their coverage. An observed edge does not establish an open application, current fit, or an introduction. If the user asks about grants versus loans or investments, do not infer the instrument from a grant aggregate; request or inspect an instrument-specific source before classifying it.

The current profile does not supply mission or program evidence. Do not label an organization as primarily focused on a population, or claim it runs an embedded program, from its name, NTEE, website URL, or grant rows alone. When the host assistant's web search is available, use the resolved name, EIN, and website as search leads; inspect an official program or mission page before making that classification. Cite the inspected page and its date or currentness. If web search is unavailable or the source remains unclear, mark the classification unverified.

For current prospects, applications, investments, or staff, use native web search to inspect the funder's own current pages or primary transaction documents when available. Do not upgrade a historical grant edge or a search-summary lead into a current claim. Keep what Azimuth observed separate from what the web source confirms.

The organization evidence card is a compact way to inspect the result. Keep the written answer useful if the card is unavailable, with the EIN, relevant years, available source links, and one material coverage limit.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: funder-review
description: Verify a named funder or partner's current program fit, instrument, eligibility, amount basis and approach route. Use to qualify historical funding leads, refresh stale evidence or build a source-backed account plan.
---

# Funder review

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). Start with the applicant, concrete case and selected funder/partner rather than an undifferentiated web prospect list. Resolve identities using `search`/`fetch`; use selected-peer observations or purpose rows only when the relevant tools are available. An incoming funding card for a foundation does not list its outgoing grants.

Inspect current official guidelines, application/program pages, original award/filing records, reports and project announcements with native search. Keep warehouse age, source publication date and date checked distinct. Old warehouse visibility does not establish inactivity; an active website does not establish an open relevant cycle. Do not roll a past deadline into a new year.

Build an account row with program/instrument; applicant/geography/activity fit; amount and individual-award basis; current cycle and timezone if stated; invitation/application/sponsor route; official contact/channel; relationship provenance; materials/readiness; source/check date; and proposed pursue, validate, steward, hold or set-aside disposition. Leave uncertain amounts and contacts unknown. Do not turn a multi-year aggregate, cohort total or deal value into a typical grant check.

For public bridge, DAF/donor or housing-finance research read [public routes and capital](references/public-routes-and-capital.md). Those methods add source-backed leads, not warm relationships. Prioritize an application or outreach only when route and case fit are supported; otherwise prioritize the missing checks. Include the applicant's capacity and timing before proposing a solicitation plan.

For a roster, preserve unresolved entities and material blockers in a short queue. Follow [research review](../azimuth-research/references/research-review.md) for conflicts and explicitly requested enrichment. Native research supplies current checks; the MCP does not silently call another web-search provider.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: fundraising-strategy-process
description: Guide a nonprofit fundraising strategy conversation from its current question to a defensible next decision. Use for goals, peers, benchmarks, funding routes, prospect priorities, program cases, proposals, or strategy refresh; use the focused lookup skills for a simple entity or funding-history question.
---

# Fundraising Strategy Process

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). This is the portable research/decision method, not the Azimuth strategy application itself. Use the focused issue, program-evidence, funder-review and research-packet skills for their stage artifacts.

Use the Azimuth fundraising method as a guide, not a required wizard. People may enter through a full strategy, landscape or benchmark, prospect expansion, program or project case, live proposal, or execution and refresh. Begin with the user's question. Identify the decision, organization, scope, market, time horizon, and useful output; carry forward what the user already decided. Ask a focused question only when the answer would materially change the next move. Give a useful provisional answer while evidence is incomplete.

The method has eleven connected stages. Read the reference for the part of the process the user needs; for an end-to-end strategy, use all three as the work progresses:

- [Position, peers, and benchmark](references/position-and-benchmark.md): stages 1–4, from the ask to a fair financial diagnosis and planning goal.
- [Evidence, case, and opportunities](references/case-and-opportunities.md): stages 5–8, from program analogs and costs to funding routes and qualified prospects.
- [Portfolio, roadmap, and refresh](references/portfolio-and-roadmap.md): stages 9–11, from choices and channel goals to an owned plan, board memo, and subsequent revisions.

## Use the strategy prompt library

Read the [strategy prompt library](references/strategy-prompts/index.md) when drafting or improving a strategy. It carries the Azimuth Strategy Framework's stage profiles, reusable prompt modules, shared strategy context, fast-intake prompts, and six section helpers. Select the relevant stage and linked task module; for a first strategy use shared context plus fast intake, and for a chapter revision use the matching section helper. Use available evidence and accepted user decisions to fill context; leave unavailable inputs as explicit gaps. Never paste unresolved app placeholders into the deliverable.

Apply the Host/MCP adaptation at the top of each reference. These are research and drafting methods, not access to the strategy application, its database or its stored reviews. Put copy-ready organizational prose in the draft, and show provisional candidates, limitations and source checks separately in the conversation. Do not conceal uncertainty merely because the method keeps review metadata outside the document. Respect this connection's actual capabilities and existing goal-calibration rules.

For any numeric goal, portfolio or staffing recommendation, read [Goal calibration](references/goal-calibration.md). Keep peer ambition, solicitation volume, commitments and in-horizon cash separate; construct a conditional first-year scenario from access, workload and payment timing. When renewal cash, access and capacity are unknown, do not recommend a numeric first-year goal, even under the label provisional or planning case. Recommend the initial work and the decision date instead. A numeric scenario requires an explicit ask/conversion/payment construction; historical contributions are not confirmed next-year cash.

Start at the relevant stage and surface consequential upstream gaps. When new peers, sources, or decisions change an earlier premise, revisit the affected downstream conclusions. Produce the useful stage artifact, not merely a list of research that someone else should do.

## Work with the evidence available here

Use the bound Azimuth app and its actual catalog. Follow [connection boundaries](../azimuth-research/references/connection-boundaries.md) for availability and any explicitly requested saving. Do not switch connections or claim hosted persistence from another app's result.

- Resolve a named organization with `search` and `fetch` before relying on its profile. Use the focused `entity-evidence` workflow for ambiguous names or a deep profile question. Treat Azimuth facts and graph paths as dated evidence or research leads within their stated coverage.
- Separate peer roles: operating and financial peers support financial benchmarks; funding-market peers reveal possible doors; program analogs inform the case; capital-stack neighbors reveal instruments and partners. Explain why each suggested peer belongs. Use `compare_org_financials` when available for selected EINs and filing years; it returns filing metrics and coverage, not an approved cohort or fundraising target. If it is unavailable or incomplete, inspect primary filings with the host assistant's native tools. Do not create a target or peer band from grant-edge totals.
- Use `find_peer_funders` only for peers the user has named or selected. Its output is historical grant observation and a discovery lead. Follow `peer-funding-comparison` for that narrow step. Keep operating grants, public funding, bank support, project capital, intermediaries, and donor channels in separate lanes.
- For current eligibility, program fit, application route, dates, people, and recent deals, use the host assistant's native web search when available. Inspect official or other primary sources and cite the page actually checked. An old filing, graph edge, or generated search summary does not establish a current opening or warm introduction.
- A peer-only grantor is a lead to investigate, not a ranked prospect. Before ordering outreach or recommending an application, verify the funding instrument, current program and geography, application or relationship route, and fit with the organization's specific case on primary sources. If those checks are missing, rank the *research checks* instead. Do not label a warehouse grant edge as project capital or an operating grant without instrument evidence.

## Help the user make the next decision

At each turn, give the strongest supportable working position, the source or assumption behind it, the viable choices and tradeoffs, and one useful next decision or research check. Distinguish observed facts, user statements, inference, recommendations, and unresolved gaps. A peer benchmark informs a goal; the user chooses the goal and route mix. A prospect list is not the strategy until fit, access, effort, capacity, and timing have been considered.

Use Azimuth to augment the evidence, and use the host assistant's own research and document abilities for sources outside its coverage. Retrieve public information before asking the user to find it. Ask the user for private capacity, costs, relationships, or judgments that materially change the plan. When asked for recommendations, make a provisional choice with a reason and assumptions; do not end with an unchosen menu. Mark decisions as accepted only when the user accepts them.

Keep accepted peers, set-asides, chosen lanes, and reasons legible so follow-ups can revise them. Follow connection boundaries rather than assuming a workspace/inbox exists. Private strategic decisions stay in the requested artifact/conversation; label their provenance and keep them out of public graph claims.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 22 — file references are metadata, not package contents.

View saved version →

---
name: issue-to-funding-map
description: Map an issue and U.S. state to organizations doing the work, then inspect their observed funders. Use for questions like who funds Chicago veteran services; do not use for an open-grants-only search.
---

# Issue to funding map

Read the shared [evidence rules](../azimuth-research/references/evidence-rules.md) and [connection boundaries](../azimuth-research/references/connection-boundaries.md). Check the selected connection’s actual tool catalog first. If the three issue tools are absent, follow the same discovery and source-review method using native primary-source research and report the missing graph route; do not invent tool results.

Start with the work, then follow support. Azimuth's full landscape method is broader than this MCP currently supports: graph-route probes, multiple independent organization discovery methods, EIN deduplication, sampled precision and seed-recall review, whole-org versus named-program classification, funding-neighbor expansion, reclassification of neighbors, and graph writeback. This guide contains the portable method. Landscapes built earlier for specific organizations are not MCP data and must not be presented as a fresh or public result; do not describe the present MCP as reproducing that full process end to end.

1. Identify the issue and state. Call `search_interventions` and select the specific returned taxonomy ID. If the phrase is ambiguous, narrow it with the user rather than guessing. Call `map_issue_funding` with that ID and state, plus city when relevant. Its first call is **candidate discovery only**; no funders are returned.
2. Read the returned `basis` for every organization. Apply the [relevance check](../relevance-check/SKILL.md) before presenting a candidate as a verified organization, named program, peer, or prospect. `organization_route` is an active organization-level graph path; `named_program_route` means the issue is attached to a program inside a broader parent; `taxonomy_candidate` is a broad fallback. Use `route_basis_filter=organization` and `route_basis_filter=named_program` when the two kinds need separate review. Routes can be noisy. Inspect the organization's own program page or another primary source before stating that it serves the population or geography. Do not call a broad parent a veteran nonprofit because it has a veteran program. Use `candidate_offset` to inspect later bounded pages when the first page is full, then search beyond those pages with native research when needed; no page is a complete landscape. For a claimed landscape or shortlist, deduplicate identities and check a curated known-organization seed plus a sample of candidates; if those gates are absent, label the output a preliminary set of leads.
3. Call `map_issue_funding` again with the source-checked `selected_eins` and a small set of specific `purpose_terms` including relevant word forms such as `veteran`, `veterans`, and `military`. A selected organization with no issue route is labeled `selected_unrouted`; investigate the graph gap separately. Read its two funding lanes separately. `purpose_rows` are **individual filing rows whose purpose text mentions a requested term**; a mixed-purpose row's full amount is not issue-dedicated spending. `incoming_funding_signals` are historical funders of the selected organization regardless of purpose; they show who to investigate but do **not** establish support for the selected issue or named program. A linked filing there is only an example for the funder-recipient pair and does not verify the aggregate. Schedule I purpose rows currently lack a direct filing URL in this tool; foundation rows may have one. Inspect the original award or filing before claiming what it funded. A zero-row result in either lane means this warehouse path found nothing, not that the organization has no supporters.
4. When another recipient would help test a support pattern, call `expand_issue_funder` for a selected funder, state and the same purpose terms; pass the starting organization as `exclude_eins` when looking for other recipients. This returns other purpose-mention rows, not verified peers; recipient state is an address, not a service area. Check each organization's work before treating it as a peer.
5. For the most relevant supporters, inspect the funder's own current pages for role, geography, eligibility and approach rules. Separate incumbent supporters, relationship leads, open application routes, partners and unresolved names. A grant history alone never becomes an application recommendation. If the requested current check cannot be made, report a research lead with the missing check.
6. If the map is thin, say where the route broke: issue taxonomy, organization/program evidence, missing funding edge, grant-purpose evidence or current approach information. Use native primary-source research when available to repair the answer. A missing MCP edge does not prove no relationship. If the user explicitly asks to save a public-source-backed correction, use `save_enrichment_candidate` when available; otherwise keep it as a review note in the conversation.

Explain the path in plain language: “We found groups doing the work, checked who supported them, and then checked what that support actually covered.” Show the organization, named program when relevant, supporter, date/source, and remaining uncertainty. The current MCP provides candidate routes and purpose-text filing rows; it does not automatically reproduce the full classification and source-review process.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: peer-funding-comparison
description: Compare observed funders across explicitly selected nonprofit peers and a focal organization in Azimuth. Use for peer-funder overlap or gap questions, not for unverified peer discovery or prospect recommendations.
---

# Peer Funding Comparison

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). For cohort choice or earned-revenue comparables read [peer design](references/peer-design.md); propose source-checked candidates, then obtain a selected set before running this comparison.

Resolve the focal organization and each chosen peer with `search` and `fetch`. Use `find_peer_funders` only when the user named the peers or they were clearly selected earlier in the conversation. If the user has only a strategy or a vague “organizations like us,” ask for the peer set or explain that this version cannot yet verify a comparable cohort. Keep close operating peers distinct from broader reference models when the user supplied both; do not imply they are equivalent.

Classify each named entity's role before interpreting a result. A peer nonprofit is an organization doing comparable work; do not evaluate it as a prospective funder, ask for its application rules, or call its incoming supporters its own grants to others. Some peers also make grants, but that requires separate outgoing-grant evidence. If the focal organization has few or no observed inbound edges, compare two already selected peers with visible histories and state that the focal organization's coverage is thin. Absence of an FCC-style focal edge is a data-coverage limit, not a failed overlap test or evidence that the organization lacks supporters.

`find_peer_funders` takes nonprofit EINs and reports funders observed for the selected peers. It does not directly compare two foundations' grantee portfolios. For a request to compare two funders, resolve and classify those funders first; inspect each one's outgoing records through a supported read path if available, with its caps and source limits. Never pass two foundation EINs as focal and peer merely to force a result from this tool.

Read the comparison as historical grant observations. Report the selected peers, observed years, overlapping funders, and whether a focal edge was observed. “Not observed here” means only that the selected warehouse path did not return that edge. The recorded funder role can include an operating partner or intermediary. Linked filings are examples for a pair and do not validate the aggregate total.

Treat a missing `funder_type` as an unresolved role. Warehouse year and example filing year are separate; a mismatch cannot verify aggregate amount/recency. Use native primary sources to check pass-through or donation roles. For retain requests follow [connection boundaries](../azimuth-research/references/connection-boundaries.md); an unavailable save becomes a conversation review note, not a claimed graph update.

Do not turn a peer-connected funder into a prospect recommendation without separate current fit, instrument, eligibility, application route, and access evidence. Keep grants separate from debt, equity equivalents, recoverable capital, and partnership routes. The current peer tool covers grant aggregates, not those other instruments. If the user asks for a shortlist, offer a clearly labeled research queue with the missing checks instead of a ranked recommendation.

If the user wants to investigate one of those funders further, use the host assistant's web search when available to inspect the funder's current official pages for program scope, eligibility, and application route. The peer table supplies names and historical leads; it does not confirm a current opportunity. Cite the pages actually checked and keep unresolved checks in the research queue.

The peer table helps inspect rows and sources. In prose, include the strongest observed patterns and the coverage limit even when the widget renders.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

When the table component renders, keep the written answer complete on its own: selected peers, observed years, overlapping funders, focal status and one coverage limit. Lead with what the two peer organizations have in common; do not turn either peer into an applicant-facing funder evaluation. Put application-route checks only in a separate funder review when the user asks for one.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: program-evidence
description: Research an intervention or program idea through studies, implementation analogs, named delivery partners and payer evidence. Use for what works, who implements it, or what makes a pilot fundable.
---

# Program evidence

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). Normalize the question by population, setting, delivery model, geography, outcomes and decision. Use Azimuth `search`/`fetch` for paper pointers and entity identities, then inspect the original study or evaluation with native host research. Paper metadata alone cannot establish a finding. If title search misses a relevant intervention, use native discovery and clearly identify which source came from which path.

For each useful study report the model, study design/strength, population/setting, outcomes, costs when observed and transfer limits. Distinguish causal evaluation, descriptive implementation and toolkit guidance. Deduplicate identical source URLs. Do not extrapolate a result to a different program or population without explaining the inference.

Find direct and adjacent implementation analogs on official program pages, evaluations and partner announcements. Map named providers, intermediaries, government payers, lenders/investors, grantors and evaluators by their actual roles. Inspect program-specific payer/award evidence before saying who funded the intervention. A historical organization-level grant or a named study investor does not prove a program grant or current availability.

Use issue tools when present for candidate discovery, followed by source verification. Keep ambiguous EINs unresolved. If no paper/program graph traversal is exposed, say the named participants came from original-source reading, then resolve their identities separately.

Produce a concise evidence/analog table and a provisional pilot concept: learning question, actual model, partner requirements, implementation and staffing needs, budget basis, baseline/outcome measures, replication deliverable and gaps. Distinguish someone doing similar work from someone willing to pay for this applicant. For the broader case or proposal use `research-packet`; for current supporter qualification use `funder-review`.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: relevance-check
description: Check whether discovered organizations, programs, peers, or funders fit a specific nonprofit research question before presenting them as a shortlist. Use after graph or search discovery when names, taxonomy tags, shared funders, or broad geography may be misleading.
---

# Relevance check

Read the shared [evidence rules](../azimuth-research/references/evidence-rules.md). A search hit is a candidate, not a finding. First restate the decision the user is making and its fit tests: population or issue, activity, service geography, organization role, and, for funding, the proposed case and instrument. Mark which tests are required versus useful context. Recheck them when the question changes. Do not let a strong match on one test compensate for a failed required test.

For each candidate:

1. **Resolve identity and role.** Match the actual organization and EIN when available; keep a program, parent, affiliate, federation, and local chapter distinct. Classify the issue connection as `primary_organization`, `named_program_in_broad_org`, `adjacent`, `unresolved`, or `out_of_scope`. For peers, state whether the candidate is a close operating/financial comparison, a program or growth-model reference, or context only; name one material difference in scale, model, or entity scope. A plausible but unresolved name stays provisional; exclude only a duplicate, clearly wrong entity, or contradicted candidate.
2. **Verify the work and place.** Follow the graph route to the organization's own program page, report, filing program description, or another direct source. Say what it actually does and who it serves. A name, NTEE code, broad tag, purpose-word match, recipient address, or funder-neighbor link alone cannot establish service delivery in the requested place. Record whether geography is a service area, program site, headquarters, mailing address, or unknown.
3. **Check the exact relationship being claimed.** Verify funder → recipient direction before interpreting an edge. Separate an issue-matching grant-purpose row, general support to an organization with relevant work, a shared funder, a capital/deal participant, and a current grant opportunity. Preserve the individual source, date, amount basis, recipient and stated purpose where available. A warehouse pair aggregate or linked example filing does not verify every underlying payment. General support to a broad parent is not proof of support for its named program. Mixed-purpose grant dollars are not issue-dedicated dollars. A shared funder generates another candidate to review, not an endorsement or warm introduction.
4. **Assess funder fit separately.** Identify whether the named entity is a decision-making funder, incumbent supporter, donor-advised or payment conduit, fiscal sponsor, intermediary, lender/investor, service partner, or unknown; one organization may have several roles. For a prospect, check current official priorities, eligible applicant and place, grant versus investment instrument, typical award basis, invitation/application route, and timing. An old warehouse year is a data-currentness fact, not proof a funder has stopped giving. A historical supporter may be a stewardship lead while an unverified peer funder remains a research lead. A grant list cannot answer a loan, EQ2, PRI, or project-capital question on its own. Use the [funder review](../funder-review/SKILL.md) when the user needs a qualified approach plan.
5. **Make a disposition with the missing check.** Return `include`, `include_as_program`, `context_only`, `provisional`, or `set_aside`, plus a short reason, source and check date, confidence, and the most important unresolved fact. For funding work, also label the next action `steward`, `investigate`, `approach`, or `no_action`; reserve `approach` for a source-checked case, route, and eligibility, and never infer relationship access from a shared edge. Keep inclusion, relevance to this question, and evidence strength separate; a highly relevant organization may have sparse funding data. Missing graph edges or a zero-row search do not prove no funding or no work.

For a **landscape or published shortlist**, review a known-organization seed for omissions, inspect a sample across routes and ranks for false positives, and check whether federated chapters or broad parents dominate the result. Report the sample, misses, and limitations; a retrieval cap is not a complete universe. If the gate is weak, present a smaller reviewed set and a research queue. Reclassify recipients found through funder expansion with the same steps before adding them. The current MCP supplies bounded candidate routes and funding observations; source review and coverage testing still require the host's research capabilities and human judgment.

Show a compact review table when comparing candidates: candidate and resolved identity; role and geography basis; exact observed connection; disposition and next action; source/check date; missing check. Explain the decision in ordinary language: “This group directly serves the requested population here,” “this larger organization runs a relevant program,” or “we found a possible connection but have not confirmed it.” Never turn a candidate list into a claim that all listed organizations are equivalent prospects.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

View saved version →

---
name: research-packet
description: Turn reviewed nonprofit research into a proposal case, strategy brief, board memo or source packet with clear claims, partner roles and next decisions. Use when the user wants a reusable deliverable rather than another search answer.
---

# Research packet

Read [shared evidence rules](../azimuth-research/references/evidence-rules.md). Identify the audience, decision and requested artifact. Reuse the work and accepted choices already present. For a local issue/program case, assemble the need diagnosis, direct/adjacent analogs, claim-to-evidence table, delivery roles, applicant assets, cost basis and funder-specific requirements. Use `program-evidence` and `funder-review` for missing research; do not call a draft reviewed merely because it has every heading.

For a fundraising strategy, use `fundraising-strategy-process` and its relevant references. For a source brief or presentation, read [packet and citation cleanup](references/packet-and-citation-cleanup.md). Produce the requested usable artifact, with one recommendation/decision and material gaps visible. Capacity, relationship access, commitments and private budgets must come from user context or appropriate verified evidence.

Use native host document abilities to create files when available and requested. Otherwise deliver reusable text/tables in the conversation. Document generators, stored workspaces, hosted packets and monitoring from other Azimuth tools are not available on this connection. State the actual artifact location; drafting a message or application does not send or submit it.

## In ChatGPT

GrantData is used through the Apps connection; users mention @GrantData in a conversation. Treat the selected public connection as the scope of a GrantData answer. Every public tool is read-only. Do not use private mail, file, or consulting-source connectors to answer a GrantData-scoped request, even when the host account has access to them. If the user wants separate private-source research, distinguish that work and its source from GrantData's public evidence.

Use ChatGPT's native web search for currentness checks and original sources, and cite the page actually checked.

Routine lookups return text-first results. The peer-funder comparison can render a table component when the host supports app views; still summarize the strongest patterns and the coverage limit in prose.

The guides are available as plugin skills and through `list_research_workflows` and `get_research_workflow`.

Use ChatGPT's document abilities for a packet when the user asks, and state that nothing was saved to GrantData. The owner connection may expose a save tool, but it is outside the public plugin's capability. Never switch to it to satisfy a public connection save request or represent a needs-review candidate as graph publication or permanent strategy memory.

The public connection cannot email a funder or submit an application. If asked, state this limit and offer a draft after verifying the intended funder and opportunity. Historical grant observations alone do not establish a live application route.

Produce the requested document with ChatGPT's document abilities when available; otherwise deliver reusable text and tables in the conversation.

Referenced files: 2 — file references are metadata, not package contents.