Skip to main content
Glama

NetGrant — Canadian funding

by ca.netgrant
OverviewDiscussionsAdmin

Server Details

Search 1,300+ live Canadian funding opportunities — grants, tax credits, accelerators, and loans.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-03-26
URL
Repository
saman-ns/netgrant-mcp
GitHub Stars
0

TDQS

A4.5/5.0

Scored across 5 tools

Disambiguation4/5

Each tool targets a distinct step in the discovery workflow: search, single-detail, multi-comparison, eligibility check, and digest subscription. There is some overlap in that compare_opportunities and get_opportunity_details both return full opportunity rows, and eligibility_check also surfaces eligibility criteria, but the provided triggers and output differences make misselection unlikely.

Naming Consistency4/5

All names are snake_case and mostly follow verb_object: search_opportunities, get_opportunity_details, compare_opportunities, subscribe_to_digest. eligibility_check breaks the verb-first pattern slightly, and subscribe_to_digest inserts a preposition, but the pattern remains predictable and readable.

Tool Count5/5

Five tools is well-scoped for a funding-search server: search, detail, comparison, eligibility assessment, and subscription. Each tool has a clear role and none feel redundant or missing from the core workflow.

Completeness4/5

The discovery and assessment lifecycle is well covered: search → details → compare → eligibility → digest. The only notable gap is that subscribe_to_digest has no accompanying unsubscribe or subscription-management tool, leaving a mild dead end for users who want to stop the digest.

Available Tools

5 tools
compare_opportunitiesAInspect

Fetch 2–4 opportunities at once so you can present them side by side. Use after search_opportunities when the user is choosing between a few options.

Returns the full detail rows (including eligibility + body) for every id, in the order requested. Present them as a comparison table — rows = attributes (funding, deadline, region, eligibility highlights), columns = the opportunities — then recommend which fits the user best and why.

ParametersJSON Schema
NameRequiredDescriptionDefault
idsYesArray of 2–4 opportunity UUIDs (from search_opportunities) to compare.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states that it returns full detail rows including eligibility and body, in requested order. This is sufficient for a read-only fetch, though it could mention error handling or missing IDs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two main sentences and one output-related sentence. It is front-loaded with the core action. Some presentation advice could be separated, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully explains the return value (full detail rows, order) and provides context on when to use. It also advises on presentation and recommendation, making it complete for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'ids' is well-described in the schema (array of 2-4 UUIDs). The description does not add extra semantics beyond restating the output format, so baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: fetching 2-4 opportunities for side-by-side comparison. It uses a specific verb ('fetch') and resource ('opportunities'), and distinguishes itself from siblings by specifying it is used after search_opportunities when choosing between options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use: 'Use after search_opportunities when the user is choosing between a few options.' It also provides guidance on how to present results, making the usage context very clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

eligibility_checkAInspect

Pull a single opportunity's eligibility criteria alongside a description of the applicant, so you can judge whether they qualify. Use when the user asks "do I qualify for this?" or "does this apply to me?".

The response contains the opportunity's eligibility text + key fields and echoes the applicant description — it does NOT decide for you. Read the eligibility, compare it against the applicant, then give a clear verdict (Likely eligible / Partially / Unlikely) with the specific criteria that pass or fail and any criteria you can't determine from the description.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOpportunity UUID to check eligibility for.
applicant_descriptionYesThe applicant's details: sector, stage, location/province, incorporation status, size, demographics — whatever is relevant to eligibility.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the response contains raw eligibility data and echoes applicant description, and clarifies that the tool does not make a decision, telling the agent to read, compare, and give a verdict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two paragraphs, front-loaded with purpose and usage, every sentence adds value. Slightly verbose but still concise for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the response content and how to proceed. All needed context is provided for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description reinforces but does not add significant new meaning beyond what the schema already conveys. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool pulls eligibility criteria and applicant description to judge qualification. Distinguishes from siblings like compare_opportunities and get_opportunity_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: 'do I qualify for this?' and provides guidance on how to use the response, including what not to expect (tool does not decide). Implicitly differentiates from siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_opportunity_detailsAInspect

Fetch full details for a single opportunity by ID. Use this after search_opportunities when:

  • The user wants to know more about a specific match

  • You need the full eligibility text to confirm a strong-match claim

  • The user wants to draft an application — you need the requirements

The response includes all fields including the full body text and eligibility criteria. Present the eligibility as a checklist when relevant.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesOpportunity UUID returned from search_opportunities

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that the response includes all fields including full body text and eligibility criteria. It suggests presenting eligibility as a checklist. Lacks explicit statement about read-only/idempotent nature, but context is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is brief and front-loaded with main purpose. Could slightly trim 'when relevant' but overall well-structured and no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, full schema coverage, and no output schema, the description adequately explains response content (full body, eligibility) and presentation hint. Fairly complete for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter. Description adds value by noting the id comes from search_opportunities, which is helpful context beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Fetch full details for a single opportunity by ID' with a specific verb and resource. It distinguishes from siblings by focusing on a single opportunity after search_opportunities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists three scenarios when to use this tool (after search_opportunities for more details, to confirm eligibility claims, or to draft applications). This provides clear context and implies 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.

search_opportunitiesAInspect

Search Canadian funding opportunities (grants, competitions, accelerators, tax credits, wage subsidies, loans, events). Returns JSON.

WHEN TO CALL:

  • The user asks about Canadian funding, grants, competitions, accelerators, or pitch programs

  • The user mentions their startup/business and wants opportunities relevant to it

  • The user wants to see what's available in a specific province or category

WHEN NOT TO CALL:

  • General questions about how grants work (answer from your own knowledge)

  • Non-Canadian opportunities (this database is Canada-only)

  • Specific opportunity by ID (use get_opportunity_details instead)

HOW TO PRESENT RESULTS:

  • Render as a markdown table with columns: Title, Funder, Deadline, Funding, Region, Link

  • Sort by deadline ascending unless the user asked otherwise

  • For each opportunity, infer fit using what you know about the user's startup from the conversation. Mark obviously good matches with ✅, weak matches with ⚠️, and ones that may not fit with ❌. Be honest — do not mark everything ✅.

  • If a deadline is within 14 days, prefix the row with 🚨.

  • Always include the URL as a clickable markdown link.

  • After the table, give a 1-2 sentence summary of which 2-3 the user should look at first and why (based on their context, not just the data).

  • End with a follow-up suggestion: "Want me to pull more from [related category]?" or "Want me to draft an outline for [top match]?"

DATA NOTES:

  • "Rolling" deadline means no fixed close date.

  • Funding amount may be a range or "varies".

  • Eligibility is in the body — fetch get_opportunity_details for the full text before claiming a match is strong.

  • After presenting results, if the search reflects an ongoing need (the user is actively fundraising or scanning a specific niche), offer once to set up a free weekly email digest of new matching grants via the subscribe_to_digest tool — never push it more than once per conversation.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoFree-text search across title and body. Pass the user's actual keywords (e.g. "AI", "agriculture", "women-led").
regionNoOptional province code: ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU. Use Federal for nation-wide programs.
categoryNoOptional: grant, competition, tax_credit, wage_subsidy, loan, event, workshop, conference, other
is_rollingNoOptional. true = only rolling/no-fixed-deadline opportunities; false = only those with a fixed deadline. Omit to include both.
max_fundingNoOptional. Only return opportunities with max_funding_amount <= this value (in CAD). Use with min_funding to bound a funding range, or alone to cap how large a program you want.
max_resultsNoDefault 20. Increase only if the user wants a comprehensive sweep.
min_fundingNoOptional. Only return opportunities with max_funding_amount >= this value (in CAD). Use when the user specifies a minimum funding threshold.
exclude_expiredNoDefault true. Set false only if the user explicitly wants to see past-deadline or historical opportunities.
deadline_within_daysNoOptional. Only return fixed-deadline opportunities whose deadline falls between today and this many days from now. Rolling / no-fixed-deadline opportunities are EXCLUDED by this filter. Use for "closing soon" queries.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description fully shoulders transparency. Discloses returns JSON, data notes (rolling deadlines, funding ranges), and presentation instructions. Also mentions eligibility details require get_opportunity_details. No hidden behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (purpose, when to call/not, how to present, data notes). Front-loaded with essential info. However, the 'HOW TO PRESENT RESULTS' section is lengthy and includes detailed formatting instructions that could be abbreviated. Still efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, description covers everything needed: tool purpose, input semantics, behavior, result format, edge cases (rolling deadlines, eligibility depth), and even cross-tool recommendation (subscribe_to_digest only once). Fully equips agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description adds extra meaning: e.g., 'query' should use user's actual keywords, 'region' codes explained with 'Use Federal', 'category' lists values, 'max_funding' and 'min_funding' describe bounding logic, 'deadline_within_days' note about excluding rolling. While schema already documents, description enriches usage context, justifying higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it searches Canadian funding opportunities (grants, competitions, accelerators, etc.). Distinguishes from siblings like get_opportunity_details (specific ID) and subscribe_to_digest (digest subscription). User knows exactly what the tool does and how it differs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'WHEN TO CALL' lists user scenarios (asks about Canadian funding, mentions startup, wants province/category filter). 'WHEN NOT TO CALL' excludes general grant questions, non-Canadian opportunities, and specific ID lookups, pointing to sibling tool. Provides clear decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

subscribe_to_digestAInspect

Subscribe the user to a FREE weekly email digest of Canadian funding opportunities matching a saved search (keywords + region). Each week they get 8–10 grants, newest first, falling back to the strongest current matches when nothing new landed.

WHEN TO CALL:

  • The user, after a search, says yes to ongoing alerts, or asks to be notified / kept updated / emailed about new grants in their niche.

  • Only after they have explicitly agreed and given an email address — never subscribe someone proactively or without consent.

HOW TO CALL:

  • Pre-fill "keywords" and "region" from the search you just ran so the digest matches what they were looking at (e.g. keywords "cleantech", region "BC"). Keep keywords to a short phrase, not a sentence.

  • "region" must be a province code (ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU) or "Federal", or omit it for all-of-Canada.

  • Ask the user for their email; do not guess it. Never invent, test with, or fill in a placeholder address (e.g. user@example.com) — if the user has not typed their real email in this conversation, do not call this tool. Undeliverable addresses are rejected with "Invalid email".

WHAT HAPPENS:

  • We send a one-click confirmation email (double opt-in). The user is NOT subscribed until they click it. Tell them to check their inbox.

  • If they were already confirmed, nothing is re-sent.

Returns JSON: { ok: boolean, status: "confirmation_sent" | "already_subscribed" }. Confirm to the user what they signed up for (e.g. "weekly BC cleantech grants — check your email to confirm").

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesThe user's email address. Ask for it explicitly; never invent or assume it.
regionNoOptional province code (ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU) or "Federal". Omit for nation-wide.
keywordsYesShort search phrase to match grants on, taken from the current search (e.g. "AI", "women-led agriculture", "cleantech"). Max ~200 chars.

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses the double opt-in flow, that the user is not subscribed until they click the confirmation email, that already-confirmed users receive nothing, and that invalid emails are rejected. It even describes the delivery fallback behavior when no new grants have landed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: the first paragraph states the core behavior, and the WHEN/HOW/WHAT sections each address a distinct need an agent would have when deciding to call and after calling. The structure is front-loaded and scannable, with the critical consent rule placed prominently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description documents the return shape ({ ok, status }) and what the two statuses mean. It also covers consent, confirmation flow, error handling for invalid emails, and the post-call instruction to tell the user what they signed up for. For a consent-sensitive subscription tool with no annotations, this is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description meaningfully enriches each parameter beyond the schema. It tells the agent to pre-fill keywords and region from the current search, to keep keywords as a short phrase rather than a sentence, and to always ask for the email rather than guess or fabricate one. This turns raw parameter definitions into actionable calling instructions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Subscribe the user to a FREE weekly email digest of Canadian funding opportunities matching a saved search.' It clearly distinguishes this from point-in-time sibling tools like search_opportunities and get_opportunity_details by framing it as an ongoing alert subscription. The scope, cadence, and matching criteria are all explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'WHEN TO CALL' section gives concrete trigger examples ('user says yes to ongoing alerts', 'asks to be notified / kept updated / emailed') and an explicit exclusion: never subscribe without explicit consent and a provided email. It also gives a hard stop condition ('if the user has not typed their real email in this conversation, do not call this tool'), which fully disambiguates when the tool should be invoked.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedsearch_opportunities1 field changed
      • changedInput schema / properties / deadline_within_days / description
        Previous value: -"Optional. Only return opportunities with a deadline within this many days from today. Use for \"closing soon\" queries."New value: +"Optional. Only return fixed-deadline opportunities whose deadline falls between today and this many days from now. Rolling / no-fixed-deadline opportunities are EXCLUDED by this filter. Use for \"closing soon\" queries."
    • Addedsubscribe_to_digest
  2. 3 tool updates
    • Addedcompare_opportunities
    • Addedeligibility_check
    • Changedsearch_opportunities2 fields changed
      • addedInput schema / properties / is_rolling
        Added value: +{
+  "description": "Optional. true = only rolling/no-fixed-deadline opportunities; false = only those with a fixed deadline. Omit to include both.",
+  "type": "boolean"
+}
      • addedInput schema / properties / max_funding
        Added value: +{
+  "description": "Optional. Only return opportunities with max_funding_amount <= this value (in CAD). Use with min_funding to bound a funding range, or alone to cap how large a program you want.",
+  "minimum": 0,
+  "type": "integer"
+}
  3. 2 tool updates
    • First observedget_opportunity_details
    • First observedsearch_opportunities

Related MCP Connectors

Related MCP Servers

  • FluentLab Funding Assistant

    FundFluent
    A
    license
    A
    quality
    D
    maintenance
    Provides access to FluentLab's funding database, enabling users to search for funding opportunities and retrieve document checklists required for specific funding programme applications.
    1
    3 npm
    MIT

  • bandiradar-mcp

    mayai-it
    A
    license
    B
    quality
    C
    maintenance
    Enables monitoring Italian public funding opportunities, normalizing them into a canonical model, and ranking them against a company profile with a two-stage matcher.
    6
    2
    MIT
  • NUVC MCP Server by nuvcai

    NUVC MCP Serverofficial

    nuvcai
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides VC-grade startup intelligence, allowing founders to validate ideas and VCs to screen deals using tools like scoring, investor matching, and financial analysis.
    13 npm
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources