Search 380+ New Zealand community grant funders, deadlines and application questions. No login.
Scored across 8 tools
Every tool has a clearly distinct purpose: search_funders vs list_filters (search vs enumerate valid filter values), get_funder vs search_funders (full profile vs compact results), and the two rounds_* tools differ by direction (opening vs closing). The feedback tools (flag_funder_detail, report_outcome, suggest_funder) also target distinct actions.
Six tools follow a clean verb_noun snake_case pattern (get_funder, list_filters, search_funders, suggest_funder, flag_funder_detail, report_outcome). The two rounds_* tools deviate by using a noun-based ordering, but the convention is still readable and predictable.
8 tools is well-scoped for a funder-discovery domain, with each tool earning its place across discovery, detail, filtering, deadlines, and feedback workflows.
The surface covers the full discovery lifecycle: filter values, search, detail lookup, deadline reminders, and bidirectional feedback (report outcomes, flag errors, suggest new funders). Minor gaps exist (no keyword/purpose-only browse tool separate from search), but core workflows have no dead ends.
Report that a field on a funder profile is wrong or out of date, with the correction. Reviewed by All Too Human before any change is applied.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| correction | Yes | What the correct value is, and where you saw it if possible | |
| funder_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false but don't explain the workflow. The description adds real value by clarifying that this files a report which a human ('All Too Human') reviews before any change is applied, so the agent knows nothing is mutated immediately and review latency is expected.
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?
A single tight sentence front-loading the action and resource, followed by the review caveat. No filler, though the human-review clause could be integrated more economically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter report submission with no output schema, the description covers the core action and review behavior, but it leaves the two undocumented parameters (funder_slug, field) and the expected result of a submission unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'correction' is documented in the schema; 'field' and 'funder_slug' are not), so the description is expected to compensate. It merely says 'a field' and 'with the correction' and never explains the field enum values, slug sourcing, or correction format, adding almost nothing 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?
States a specific verb and resource: report that a field on a funder profile is wrong or out of date, supplying the correction. It's clear what the tool does, but it never names or contrasts with a sibling such as suggest_funder or report_outcome, so differentiation is left to inference.
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?
Implies its use case (a field is wrong or stale and you have a correction) and notes the human review step, but gives no explicit when-to-use versus alternatives like suggest_funder, and no prerequisites such as needing a valid funder_slug from search_funders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full profile for one funder by slug: what they prioritise, language tips, common mistakes, success factors, required documents, application sections, the extracted application form questions, and upcoming funding rounds. Use this before preparing or drafting an application.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Funder slug from search_funders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuinely useful context by disclosing the breadth of the returned profile (priorities, language tips, mistakes, required documents, form questions, rounds), which is valuable since there is no output schema. It does not clarify error behavior for an unknown slug.
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?
One tight sentence with the resource scoped up front and the field enumeration after the colon; the trailing usage hint earns its place. The list is dense but every item is informative given the absent output schema.
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 no output schema, the description carries the return-value burden and does so well by naming the profile sections. It stops short of stating error cases (invalid/missing slug) or whether the profile is cached, which would be the remaining gap for a single-param lookup 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% and the single slug parameter is documented in the schema as coming from search_funders. The description only restates 'by slug' and adds no format, length, or validity nuance beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Full profile for one funder by slug') and enumerates the payload contents, which clearly distinguishes it from siblings like search_funders or list_filters. An agent can tell this is the detail-fetch complement to the search tool without opening a schema.
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 states the trigger: 'Use this before preparing or drafting an application.' It does not name sibling alternatives or when-not-to-use, but the search-then-fetch relationship is strongly implied by the slug parameter referencing search_funders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the exact region slugs, organisation type values and difficulty levels accepted by search_funders. Call this first if you are unsure which value to use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds useful context that the tool exists to surface valid enum-like values for a sibling tool, which is behavior beyond what annotations convey.
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 tight sentences with no waste; the payload (what is returned) is front-loaded ahead of the usage instruction.
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?
No output schema exists, but the description names the categories of values returned and the sequencing recommendation, which is sufficient for a zero-parameter enumeration tool with full annotation coverage.
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?
Zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify about inputs, and it correctly avoids inventing any.
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?
States a specific verb (Returns) and resource (region slugs, organisation type values, difficulty levels), and ties it directly to the sibling search_funders by naming what values it accepts. An agent can distinguish this enumeration helper from search_funders without reading either schema.
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 'Call this first if you are unsure which value to use,' which gives a clear precondition for invoking it. It does not spell out when not to call it, but the routing intent relative to search_funders is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell us how an application to a funder went. Outcomes are stored for All Too Human to analyse which funders say yes and are never published as-is.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Anything useful: what they asked for, timing, feedback received | |
| outcome | Yes | approved = funded in full, partial = funded less than asked, declined, waiting = no decision yet | |
| funder_slug | Yes | ||
| amount_received | No | Whole NZ dollars received, if funded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only tell the agent this is a write that is not read-only, not idempotent and closed-world. The description adds genuinely useful disclosure beyond that: outcomes are retained for internal analysis and never published as-is. It still omits what happens on a duplicate report despite idempotentHint=false.
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, zero padding. The action is stated first and the privacy/retention caveat follows immediately, so the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation with no output schema, the description covers intent and data handling but leaves real gaps: whether re-reporting overwrites an earlier outcome, whether funder_slug must match an existing funder, and any auth requirements. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% and the outcome enum values are already fully explained in the schema, so the schema does most of the work. The description adds no parameter-level meaning, leaving the undocumented funder_slug unclarified; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reporting how a funder application went, with a named consumer ('All Too Human'). It is clearly distinguishable from the funder-search siblings, though it does not explicitly point to any as an alternative.
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 never says when to call this versus the other tools, nor any precondition (e.g. that the funder must already exist or that this follows a prior application). It relies entirely on the title to imply context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding rounds whose closing date falls within the next N days (default 30, max 180), soonest first. Optional region filter (slug from list_filters). Dates are New Zealand dates. Always confirm the date on the funder's own site before relying on it.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuinely non-obvious behavioral context: dates are New Zealand dates, and the data may be stale enough that the funder's own site must be confirmed. That caveat materially changes how an agent should present results.
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?
Three tight sentences, front-loaded with the core filter and ordering, then constraints, then the caveat. No filler and nothing buried.
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?
No output schema exists, yet the description supplies ordering, defaults, time-zone grounding and a data-reliability caveat, which is enough for an agent to call and report correctly. The one gap is the undocumented 'limit' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameters. It explains 'days' and clarifies that 'region' is a slug sourced from list_filters (real added meaning), but the bounds it repeats are already in the schema and the 'limit' parameter is never mentioned anywhere.
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?
States a specific resource (funding rounds), a precise filter (closing date within next N days), and an ordering guarantee (soonest first). The 'closing' framing cleanly separates it from rounds_opening_soon without needing to name it.
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?
Gives concrete operating context: default 30 / max 180 days, soonest-first ordering, and routes the agent to list_filters for valid region slugs. It does not state when to prefer this over rounds_opening_soon or search_funders, so no explicit exclusion is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Funding rounds whose opening date falls within the next N days (default 60, max 180), soonest first. Optional region filter (slug from list_filters). Useful for planning applications ahead of time. Dates are New Zealand dates. Always confirm the date on the funder's own site before relying on it.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| region | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and closed-world semantics, so the bar is lower. The description adds genuine behavioral context beyond them: the sort order, the New Zealand date basis, and a caution that dates should be verified on the funder's own site before relying on them — a real data-reliability caveat.
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?
Four tight sentences with the scope, defaults, filter source, and caveat ordered sensibly and front-loaded. No filler, though the date-range bounds duplicate schema data at some cost to density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description supplies the sort order, region-filter provenance, and freshness caveat an agent needs. Only the unmentioned limit parameter and the absence of any sibling routing leave a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load. It explains region as a slug sourced from list_filters — genuinely non-obvious and valuable — but the 60/180 values it repeats for days are already in the schema (no credit), and the limit parameter is never mentioned at all.
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?
States a specific resource and scope: funding rounds whose opening date falls within the next N days, returned soonest first. The 'opening' framing inherently distinguishes it from the sibling rounds_closing_soon without needing to name it.
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?
'Useful for planning applications ahead of time' implies the use case but gives no explicit when-to-use vs when-not, and never names rounds_closing_soon as the alternative for the opposite time window. The agent must infer the routing decision from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search New Zealand community grant funders. Returns up to 25 compact rows per call with a total count; use offset to page. Combine filters: region (slug from list_filters), org_type, purpose keywords, max_amount in NZD, difficulty. Use get_funder for the full profile of a result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Free text matched against funder name and description | |
| offset | No | ||
| region | No | Region slug, e.g. tasman. Funders tagged national always match. | |
| purpose | No | Keyword matched against eligible purposes and priorities, e.g. youth, environment, marae | |
| org_type | No | Applicant organisation type, e.g. charitable_trust | |
| difficulty | No | ||
| max_amount | No | Only funders whose minimum grant is at or below this NZD amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely useful behavior the annotations cannot convey: the 25-row page cap, that a total count is returned, and that offset drives pagination. Missing rate-limit or auth notes, but the result-shape disclosure is valuable given there is no output schema.
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?
Three tight sentences, no filler, front-loaded with purpose then return shape then filter guidance and the handoff to get_funder. Every sentence earns its place.
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 8 optional parameters, no output schema, and read-only annotations, the description supplies the missing pieces: what a call returns, how to page, how to combine filters, and which sibling to use for detail. An agent has everything needed to invoke it 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 descriptions cover 63% of parameters, and the description adds meaning beyond that: region is a slug sourced from list_filters, max_amount is NZD, and difficulty is a first-class filter. It reinforces key semantics rather than merely restating schema text.
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?
States a specific verb (Search) and resource (New Zealand community grant funders), plus the scope of results (up to 25 compact rows with total count). It also names the sibling get_funder as the follow-up for full profiles, so an agent can separate it from the other funder 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?
Gives concrete usage context: combine region/org_type/purpose/max_amount/difficulty filters, use offset to page, and switch to get_funder for a full profile. It doesn't explicitly say when to prefer suggest_funder or flag_funder_detail over search, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest a New Zealand grant funder that is not in the database. All Too Human researches and reviews suggestions before adding them. Check search_funders first to avoid duplicates. Documentation: https://www.alltoohuman.nz/grants/connect
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The funder's website or funding page | |
| name | Yes | ||
| notes | No | What they fund, who is eligible, deadlines, anything you know | |
| region | No | Region slug if the funder is regional |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-read-only, non-idempotent, open-world=false write, and the description usefully adds that suggestions are 'researched and reviewed before adding them' – disclosing that submission has no immediate effect. It does not explain dedup failure behavior or what the call returns, but combined with the annotations the picture is clear enough.
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?
Four short sentences, each earning its place: purpose, review process, dedup precheck, and docs link. The key routing instruction is front-loaded after the purpose statement with no 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?
For a submission tool with no output schema and only 75% schema coverage, the description covers purpose, the human review step, and the dedup requirement, which is sufficient to invoke it correctly. It could say more about what happens on a duplicate or invalid region slug, but nothing essential is missing.
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 75% and the description adds almost no per-parameter meaning, only implying the New Zealand regional scope. The schema already documents url, notes, and region, so the baseline 3 applies rather than a penalty or credit.
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?
States a specific verb ('suggest'), resource ('New Zealand grant funder'), and a scope constraint ('not in the database'), which cleanly separates it from the read-oriented siblings like search_funders and get_funder. An agent can tell what creates data versus what reads it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to 'Check search_funders first to avoid duplicates,' naming a concrete sibling and the condition that selects it. It lacks an explicit when-not-to-use or a statement of what happens after submission, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
flag_funder_detailget_funderlist_filtersreport_outcomerounds_closing_soonrounds_opening_soonsearch_funderssuggest_funderSearch 1,300+ live Canadian funding opportunities — grants, tax credits, accelerators, and loans.
Foundation discovery and grant intelligence for nonprofits. 174K+ US funders, IRS 990 data.
Search 31,000+ open US grants, federal contracts, and foundations. Checked daily, free tier.
Find US federal grants your organization is actually eligible to apply for. Free, no API key.
Add one secure layer between your agents and this server.
