Skip to main content
Glama

NetGrant — Canadian funding

subscribe_to_digest

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").

Input Schema

TableJSON 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

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
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.