A
licenseA
qualityD
maintenanceMatch your tech product or consulting service to thousands of live government tenders, RFPs, grants, and frameworks from 25+ official sources worldwide.
4
85
5
MIT
NetGrant — Canadian funding
by ca.netgrant
Server Details
Search 1,300+ live Canadian funding opportunities — grants, tax credits, accelerators, and loans.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- saman-ns/netgrant-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.6/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: searching, fetching details, comparing, checking eligibility, and subscribing. No overlap in functionality, and the descriptions guide the agent on when to use each.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., search_opportunities, get_opportunity_details), making them predictable and easy to understand.
Tool Count5/5
With 5 tools, the surface is well-scoped for the domain of Canadian funding. Each tool addresses a distinct user need without unnecessary overhead.
Completeness4/5
The tools cover the core workflow: search, view details, compare, check eligibility, and subscribe to alerts. Missing minor operations like editing a subscription, but overall the surface is complete for the stated purpose.
Available Tools
5 toolscompare_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
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of 2–4 opportunity UUIDs (from search_opportunities) to compare. |
Tool Definition Quality
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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Opportunity UUID to check eligibility for. | |
| applicant_description | Yes | The applicant's details: sector, stage, location/province, incorporation status, size, demographics — whatever is relevant to eligibility. |
Tool Definition Quality
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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Opportunity UUID returned from search_opportunities |
Tool Definition Quality
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
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search across title and body. Pass the user's actual keywords (e.g. "AI", "agriculture", "women-led"). | |
| region | No | Optional province code: ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU. Use Federal for nation-wide programs. | |
| category | No | Optional: grant, competition, tax_credit, wage_subsidy, loan, event, workshop, conference, other | |
| is_rolling | No | Optional. true = only rolling/no-fixed-deadline opportunities; false = only those with a fixed deadline. Omit to include both. | |
| max_funding | No | 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. | |
| max_results | No | Default 20. Increase only if the user wants a comprehensive sweep. | |
| min_funding | No | Optional. Only return opportunities with max_funding_amount >= this value (in CAD). Use when the user specifies a minimum funding threshold. | |
| exclude_expired | No | Default true. Set false only if the user explicitly wants to see past-deadline or historical opportunities. | |
| deadline_within_days | No | 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. |
Tool Definition Quality
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The user's email address. Ask for it explicitly; never invent or assume it. | ||
| region | No | Optional province code (ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU) or "Federal". Omit for nation-wide. | |
| keywords | Yes | Short search phrase to match grants on, taken from the current search (e.g. "AI", "women-led agriculture", "cleantech"). Max ~200 chars. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully covers behavioral traits: it explains the double opt-in process (confirmation email, user not subscribed until click), fallback matching logic, and that no re-sending occurs for already subscribed users. This provides complete transparency.
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 well-structured with clear sections (overview, WHEN TO CALL, HOW TO CALL, WHAT HAPPENS) and front-loads the purpose. While long, it is efficient for the amount of information conveyed. Minor trimming could be possible, but it earns a 4.
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 no output schema, the description explains the return JSON format and how to confirm to the user. It covers the entire workflow from call conditions to post-call behavior, making it complete for a 3-parameter tool with no nested objects.
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% (baseline 3). The description adds valuable context: pre-fill keywords and region from the current search, keep keywords short, specify region format (province code or 'Federal'), and explicitly ask for email. This goes beyond the schema's basic descriptions.
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 subscribes the user to a FREE weekly email digest of Canadian funding opportunities matching a saved search. It specifies the verb 'subscribe', the resource 'weekly email digest', and the context (Canadian funding opportunities). This purpose distinguishes it from sibling tools like search_opportunities or 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?
The description has an explicit 'WHEN TO CALL' section that advises calling only after the user explicitly agrees and provides an email address. It warns against proactive subscription without consent, providing clear guidance on appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides access to FluentLab's funding database, enabling users to search for funding opportunities and retrieve document checklists required for specific funding programme applications.113MIT
- AlicenseBqualityAmaintenanceEnables monitoring Italian public funding opportunities, normalizing them into a canonical model, and ranking them against a company profile with a two-stage matcher.62MIT
NUVC MCP Serverofficial
Alicense-qualityCmaintenanceProvides VC-grade startup intelligence, allowing founders to validate ideas and VCs to screen deals using tools like scoring, investor matching, and financial analysis.14MIT