NetGrant — Canadian funding vs X402 List MCP
A side-by-side look at the NetGrant — Canadian funding and X402 List MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose NetGrant — Canadian funding for finance & fintech work over a hosted endpoint; choose X402 List MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose NetGrant — Canadian funding when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a remote HTTP/SSE transport.
- You want tools like
search_opportunities, get_opportunity_details, compare_opportunities.
Choose X402 List MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
X402_LIST_BASE_URL, X402_LIST_TIMEOUT_MS, MCP_HTTP_PORT, PORT, MCP_ALLOWED_ORIGINS, MCP_ALLOWED_HOSTS. - You want tools like
x402_search_services, x402_get_service, x402_find_best_service.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 53/100 · Good | 67/100 · Great |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Freemium |
| Required env vars | None listed | X402_LIST_BASE_URLX402_LIST_TIMEOUT_MSMCP_HTTP_PORTPORTMCP_ALLOWED_ORIGINSMCP_ALLOWED_HOSTS |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 26 |
| Directory activity | 0 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 5 | 7 |
| Full listing | View NetGrant — Canadian funding | View X402 List MCP |
Tools & capabilities
NetGrant — Canadian funding tools 5
search_opportunitiesSearch 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.get_opportunity_detailsFetch 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.compare_opportunitiesFetch 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.eligibility_checkPull 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.subscribe_to_digestSubscribe 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").
X402 List MCP tools 7
x402_search_servicesYour first call when you do not know which x402 service exists for a job: it narrows a directory of 500+ listed services to candidates. Filter by free-text query, category, network, live status, and whether the last observed 402 envelope is signable by a standard x402 client; sort by newest, uptime, cheapest, or endpoints. Returns up to 100 compact summaries a page: price in decimal USD, uptime, status, verification. Then x402_get_service for the full record.x402_get_serviceCall this once you hold a slug and are deciding whether to commit to that service: the full record behind a directory row. Live status, uptime over 24h/7d/30d/90d, average response time, networks and settlement asset, every priced endpoint, and the assessment block. include_series=true adds 90 daily points of on-chain volume and distinct buyers. Read the units map in the response: the per-endpoint price field is atomic token units, not dollars.x402_find_best_serviceCall this when you have a need in words and want one service to call rather than a list to read: it is the free ranking step between searching and paying. Pass the need as q, plus any category, network, price cap or verification requirement, and get up to 20 ranked recommendations with the basis each one placed on. Ranking is mostly per-service reliability (live status, verification, uptime, response time), x402 compliance, and price in USD, with a small (about 10%) weight on measured on-chain settlement traction that can never dominate those three. The response carries ranking_version (currently 3), need_blind_ranking (true when no q was given, so the order is global quality rather than your need), and a units map holding every scoring caveat in full: the compliance cap, the pro-quota rule for shared payout addresses, renormalization, the $10 volume floor, and the single-buyer discount. Read units before comparing scores across generations.x402_check_healthCall this before you send a payment, or right after a call unexpectedly failed: is this service up right now. With no slug, the directory snapshot: five status counts across 500+ services (include_services=true attaches every row). With a slug: that service's status, its 24h/7d/30d/90d uptime windows, response time, consecutive failures, daily snapshots. No money fields.x402_facilitator_volumesCall this when the question is about the rail rather than the service: which x402 facilitator actually settles money, and how much. Returns on-chain-verified settlement volume and transaction counts per facilitator for today (UTC), 7d, 30d and all-time, plus a verification flag ('on-chain' once volume has been observed on-chain, else 'listed'), across more than 30 facilitators. Optional daily timeseries (up to 90 days) and per-chain breakdown. Volume is decimal USD. Caveats: PER-FACILITATOR, never per-service; the *_24h fields cover today (UTC) so far, not a trailing 24 hours, and reset at 00:00 UTC, so prefer 7d.x402_assess_servicesCall this when the free signals have run out: you hold 2 to 8 finalists from x402_search_services or x402_find_best_service, their stored fields do not separate them for YOUR stated need, and choosing wrong costs more than a quarter. It buys one fresh AI assessment reasoned against your question, not a cached grade; reading an already-computed assessment stays free via x402_get_service. Price: a one-time $0.25 USDC on Base, over two calls. Call once WITHOUT payment_signature_b64 to receive the x402 payment challenge verbatim (accepts[], amount, payTo, and a base64 PAYMENT-REQUIRED header); sign accepts[0] client-side with your own wallet; call again with the SAME question and services plus payment_signature_b64 to receive the report and a base64 PAYMENT-RESPONSE settlement receipt. This server holds no keys, never signs and never settles: it only relays the challenge. Optionally add probe { slug, endpoint_path? } to have one listed service paid and called for real and its answer analyzed: the challenge is then priced at $0.25 plus that endpoint price X, and the report gains a probe_report block with a verdict and truncated extracts, never the verbatim third-party body. When live probing is not armed the probe is ignored. Caveats: read the amount to sign from accepts[0].amount, never from a fixed figure, since a probe changes it; probe fees are non-refundable whatever the verdict; if the fresh run cannot be produced the server answers before settling, so you are never charged for nothing; there is no refund. Prices are US dollars.x402_change_eventsCall this before you trust anything you cached about a service, and right after a payment failed for no obvious reason: the monitor's log of what moved under you. Returns payTo, price and 402-schema changes observed on listed services, most recent first, in exactly three event types (payto_changed, price_changed, schema_changed). Filter with service (the slug), type, and days (1 to 365, default 90). Caveats: prices here are atomic token amounts, never dollars, and every payTo is masked by design, so the feed reports THAT the payout address changed, never the address. Free and read-only.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
NetGrant — Canadian funding
{
"mcpServers": {
"netgrant-canadian-funding": {
"url": "https://mcp.netgrant.ca/mcp"
}
}
}
X402 List MCP
{
"mcpServers": {
"x402-list-mcp-2": {
"command": "npx",
"args": [
"-y",
"x402-list-mcp"
],
"env": {
"X402_LIST_BASE_URL": "YOUR_X402_LIST_BASE_URL_HERE",
"X402_LIST_TIMEOUT_MS": "YOUR_X402_LIST_TIMEOUT_MS_HERE",
"MCP_HTTP_PORT": "YOUR_MCP_HTTP_PORT_HERE",
"PORT": "YOUR_PORT_HERE",
"MCP_ALLOWED_ORIGINS": "YOUR_MCP_ALLOWED_ORIGINS_HERE",
"MCP_ALLOWED_HOSTS": "YOUR_MCP_ALLOWED_HOSTS_HERE"
}
}
}
}
Frequently asked questions
NetGrant — Canadian funding is categorized under Finance & Fintech and uses a remote HTTP/SSE transport. X402 List MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick NetGrant — Canadian funding for finance & fintech work and X402 List MCP for finance & fintech.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
NetGrant — Canadian funding has no declared pricing — check the project's own site. X402 List MCP is listed as freemium — a free tier with paid plans. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add netgrant-canadian-funding and x402-list-mcp-2 as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, NetGrant — Canadian funding has a quality signal of 53/100 (Good) with 0 views, 0 installs and 1 GitHub stars. X402 List MCP has 67/100 (Great) with 5 views, 0 installs and 26 GitHub stars.