The FundzWatch MCP Server provides real-time business event intelligence and AI-scored sales leads for AI agents and sales teams. It integrates with MCP-compatible clients like Claude Desktop, Cursor, and Windsurf.
Get AI-Scored Sales Leads (get_scored_leads): Retrieve companies matched to your ICP with buyer intent scores (0–100), buying stage analysis (Active Evaluation, Decision, Research, Awareness), and outreach recommendations, filterable by industry, score threshold, and buying stage.
Get Real-Time Business Events (get_events): Fetch funding rounds, acquisitions, executive hires, government contracts, and product launches, filtered by type, industry, location, and time range (up to 90 days).
Get Market Pulse (get_market_pulse): View a market activity overview including funding totals, acquisition counts, executive moves, contracts, and product launches for the past 7 and 30 days.
Get Market Brief (get_market_brief): Receive an AI-generated daily strategic intelligence brief with narrative analysis of key market movements, patterns, and opportunities.
Manage Watchlist (manage_watchlist): Add, remove, or list companies by domain (e.g., stripe.com) to monitor them for new business events.
Get Watchlist Events (get_watchlist_events): Retrieve recent events specifically for companies on your watchlist, with filtering by event type and look-back period.
Check API Usage (get_usage): Monitor API calls made, limits, and your current subscription tier.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FundzWatch MCP Server Find companies that just raised Series B in healthtech"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The key-less AI-agent gateway to FundzWatch answer sections — real-time business-event intelligence via the Model Context Protocol.
Give Claude, Cursor, Windsurf, Cline, or any MCP client live access to verified funding rounds, executive moves, UCC refinancing windows, Form 5500 benefit-plan signals, and AI-scored leads matched to your ICP.
7 of the 14 tools work with no API key, no signup, and no account — point your agent at the server and it returns live, daily-rescored "answer section" data on the first run, each row carrying the Fundz page that supports it. The other 7 (AI-scored leads, watchlists, full event feeds) need a Fundz Pro or Strategic seat.
This package is stdio: your client spawns it as a local subprocess, which hosted assistants cannot do. For those, point the client at the remote endpoint instead — no key, no signup, no account:
https://mcp.fundz.netAdd it as a custom connector / MCP server URL. It speaks Streamable HTTP (protocol 2025-06-18,
negotiating back to 2024-11-05) and serves the same seven key-less tools.
Related MCP server: Sales Signals MCP Server
npx (Claude Desktop, Cursor, Windsurf, Cline)No install needed. Add this to your client's MCP config:
{
"mcpServers": {
"fundzwatch": {
"command": "npx",
"args": ["-y", "@fundzwatch/mcp-server"],
"env": {
"FUNDZWATCH_API_KEY": "fundz_test_your_key_here"
}
}
}
}Config file locations for Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
The
envblock is optional. Omit it entirely and the 7 key-less tools still return live data. The keyed tools (AI-scored leads, watchlists, full event feeds) require a Fundz Pro or Strategic seat — see fundz.net/pricing.
For Cursor / Windsurf / Cline, use the same block under their MCP settings (the inner "fundzwatch": { ... } object).
FundzWatch is live on Smithery: smithery.ai/servers/fundzwatch/fundzwatch-mcp
npx -y @smithery/cli install @fundzwatch/mcp-server --client claude"Which companies raised in the last year and are hiring right now?" (no key)
"Show me UCC liens lapsing in the next 12 months in California." (no key)
"Find recently funded companies with a Form 5500 plan and a named carrier." (no key)
"Get my AI-scored leads with buyer-intent above 70." (key)
"Track stripe.com and github.com and alert me on new events." (key)
Live teasers off the Fundz answer sections (top results + cohort size, re-scored daily). California + Colorado UCC coverage.
Tool | What it answers |
| Companies funded in the last 12 months and actively hiring — the strongest buying window, scored daily. |
| Companies whose UCC-1 liens lapse within 12 months (Renewal Radar) — dated refinancing windows. |
| Companies with active secured debt from 2+ distinct lenders — second-position / consolidation targets. |
| Recently funded companies with a DOL Form 5500 plan: renewal timing, headcount-vs-plan gap, incumbent carrier. |
| Companies with a recent exec move and recent funding — the wealth-advisor "money in motion" moment. |
| Directory of 8,600+ UCC secured parties ranked by filing volume, with lapsing-soon exposure. |
| Directory of 65,000+ benefits brokers (Form 5500 Schedule A), ranked by filings carried, with commission volume. |
FUNDZWATCH_API_KEYTool | What it answers |
| AI-scored sales leads matched to your ICP, with buyer intent, buying stage, and recommended outreach. |
| Real-time business events: funding, acquisitions, exec hires, government contracts, product launches. |
| Market activity overview: funding totals, acquisitions, exec moves, contracts, launches (7d / 30d). |
| Today's AI-generated strategic intelligence brief on the most important market movements. |
| Add, remove, or list tracked companies; tracked companies generate new-event alerts. |
| Recent events for the companies on your watchlist. |
| Check your API usage, limits, and current tier. |
FundzWatch.ai is the AI-agent front door to Fundz's verified business-event intelligence — funding rounds, acquisitions, executive moves, government contracts, hiring signals, UCC liens, and DOL Form 5500 benefit-plan filings, fused into cross-dataset "answer sections" that no single-source lookup reproduces. Everything is re-scored daily.
Key-less answer sections — point an agent at the server and get live data on day one, no signup.
AI-scored leads — companies scored against your ICP with buyer-intent and outreach guidance (Pro or Strategic seat).
Cross-dataset cohorts — funded-and-hiring, money-in-motion, refinancing windows, benefit-plans-in-play.
Who-finances-whom — lender (8,600+) and broker (65,000+) directories from UCC and Form 5500.
The 7 key-less tools need nothing at all. Keyed tools require a Pro or Strategic seat: fundz.net/pricing.
The full scored feeds, ICP filters, contact data, and daily alerts live in the Fundz app — app.fundz.net, Strategic plan ($149/mo).
Built by Fundz — millions of business events analyzed since 2017.
MIT
Get real-time business events: funding rounds, acquisitions, executive hires, government contracts, and product launches. Filter by type, industry, and location.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Comma-separated: funding, acquisition, hiring, contract, product_launch. Default: all | |
| days | No | Look back days (1-90). Default: 7 | |
| limit | No | Max events (1-200). Default: 50 | |
| industries | No | Comma-separated industries | |
| locations | No | Comma-separated locations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It mentions 'real-time' but does not disclose data freshness, authentication needs, rate limits, pagination, or whether it is a read operation. The description lacks sufficient behavioral traits beyond the 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?
The description is two sentences, front-loads the core purpose, and contains no unnecessary words. It is efficient and easy to parse.
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 5 parameters and no output schema, the description should provide more context about the return structure, pagination, or behavior when filters are combined. It falls short of fully informing an agent about expected results or limitations.
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 100%, so each parameter is already documented. The description only restates filtering capabilities ('Filter by type, industry, and location') without adding new semantics like combination rules or defaults. Baseline 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'real-time business events', listing specific event types (funding rounds, acquisitions, etc.) and filtering options. It distinguishes from sibling tools like get_market_brief or get_watchlist_events, which focus on different data types.
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 implies the tool is for retrieving business events, but it does not explicitly state when to use it over alternatives or provide exclusions. For example, no guidance on when to use get_market_pulse instead. The context is clear but lacks explicit directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's AI-generated strategic intelligence brief with narrative analysis of the most important market movements, patterns, and opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation ('Get') but does not explicitly state safety, rate limits, or any side effects. Given no parameters, the lack is moderate.
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, front-loaded sentence that is concise and informative with no unnecessary words.
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?
Despite no output schema, the description adequately conveys the output is a 'strategic intelligence brief with narrative analysis.' For a simple retrieval tool with no parameters, this is mostly complete, though it could hint at content structure.
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?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds no parameter information, which is acceptable as none exist.
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?
The description clearly states the tool retrieves 'today's AI-generated strategic intelligence brief' with 'narrative analysis' of market movements, distinctly setting it apart from siblings like get_market_pulse or get_events.
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?
No guidance is provided on when to use this tool over siblings (e.g., get_market_pulse, get_scored_leads) or when not to use it. The description only explains what it does without contextualizing its selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time market activity overview: funding totals, acquisition counts, executive moves, contracts, and product launches for the past 7 and 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'real-time' but does not specify caching, rate limits, authentication requirements, or response structure. For a tool with zero annotations, more behavioral context is needed.
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 sentence effectively front-loads the action and enumerates specific data categories and time frames. Every phrase earns its place with no extraneous information.
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 simple tool with no parameters and no output schema, the description covers the data scope and time frames adequately. However, it omits response format details and does not differentiate from sibling tools like 'get_market_brief', which would help the agent decide when to use it.
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?
The tool has no parameters, and schema description coverage is 100% trivially. Baseline is 4 for zero-parameter tools. The description adds value by explaining the output categories and time frames, which goes beyond the empty 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?
The description clearly states the tool's purpose: 'Get real-time market activity overview' and specifies the categories (funding totals, acquisition counts, etc.) and time frames (past 7 and 30 days). This distinguishes it from siblings like 'get_events' or 'get_market_brief' which likely focus on different aspects.
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 implies usage for a broad market overview, but does not explicitly state when to use this tool versus alternatives like 'get_market_brief' or 'get_events'. No exclusions or prerequisites are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-scored sales leads based on your ICP (Ideal Customer Profile). Returns companies with recent business events scored by AI for buyer intent, buying stage, and recommended outreach strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| min_score | No | Minimum buyer intent score (0-100). Default: 0 | |
| max_results | No | Max leads to return (1-50). Default: 25 | |
| buying_stages | No | Filter by buying stage: 'Active Evaluation', 'Decision', 'Research', 'Awareness' | |
| industries | No | Filter by industry (e.g., ['SaaS', 'HealthTech', 'FinTech']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the read-only behavior: filtering by score, stage, industry. It discloses it returns pre-scored leads with recent business events, though it omits potential limitations like data freshness or rate limits.
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 concise sentences front-loaded with purpose, then capability details. No filler or redundant phrasing.
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, so the description partially addresses return values (companies with scored events), but lacks specifics on the result structure (e.g., fields per lead). Adequate for basic understanding but not fully self-contained.
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%, so parameters are already well-described. The description provides no additional semantic detail beyond the schema's domain context (e.g., that scores are AI-generated). Baseline 3 is appropriate.
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?
The description clearly states the tool retrieves 'AI-scored sales leads' based on ICP, listing specific outputs (buyer intent, buying stage, outreach strategy). This verb+resource combination distinguishes it from siblings like get_events or get_market_brief.
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 implies use when needing scored leads, but does not specify when alternatives (e.g., get_events, get_market_pulse) are more appropriate. No explicit when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your FundzWatch API usage: calls made, limits, current tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the tool returns calls made, limits, and tier, implying read-only behavior. It does not mention side effects or authentication, but for a simple check tool this is adequate.
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?
The description is a single sentence of 10 words, front-loaded with the action, and every word adds value. 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?
Given no parameters, no output schema, and no annotations, the description is fully complete. It explains what the tool returns (calls made, limits, current tier).
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% with no parameters. The description adds no parameter info, but none is needed. Baseline 4 is appropriate.
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?
The description clearly states the tool checks FundzWatch API usage (calls, limits, tier). It uses a specific verb (Check) and resource (API usage), distinguishing it from sibling tools which cover events, market data, etc.
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 implies the tool is used to check API usage, but does not explicitly state when to use it versus alternatives. However, siblings are unrelated, so no confusion arises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent events for companies on your watchlist: funding, acquisitions, executive hires, contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look back days (1-90). Default: 7 | |
| types | No | Comma-separated event types |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only lists event types; no mention of rate limits, data freshness, empty results behavior, or whether tool is read-only.
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?
Single sentence, front-loaded with core information. Concise but could be structured with bullet points for clarity.
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?
Adequate context for a simple tool with no output schema and low parameter count. Describes scope and examples, but missing return format.
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% with descriptions for both 'days' and 'types'. Description adds event type examples but no additional meaning beyond schema. 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?
Clear verb ('Get'), resource ('recent events for companies on your watchlist'), and specific examples (funding, acquisitions, executive hires, contracts). Distinguishes from sibling tools like 'get_events' by scoping to watchlist.
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 usage for watchlist events but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add, remove, or list companies on your watchlist. Tracked companies generate alerts when they have new events.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action: 'list' to view, 'add' to track, 'remove' to untrack | |
| domains | No | Company domains for add/remove (e.g., ['stripe.com', 'github.com']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that tracked companies generate alerts, but does not detail side effects (e.g., destructiveness of remove), permissions, or rate limits.
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 concise sentences: first states purpose, second adds a key behavioral consequence. No wasted words.
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 simple CRUD tool with no output schema, the description covers core functionality and alerts, but lacks details on error handling, limits, or output format of the list action.
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% with descriptions for both parameters. The description adds context that adding triggers alerts, but adds no new parameter-level detail 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?
The description clearly states the verb 'Add, remove, or list' and the resource 'companies on your watchlist,' distinguishing it from siblings like get_watchlist_events.
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 implies usage for managing watchlist entries and mentions alerts, but does not explicitly guide when to use this vs. alternatives like get_watchlist_events or get_scored_leads.
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. Dates show when Glama detected each change.
v1.0.0get_eventsget_market_briefget_market_pulseget_scored_leadsget_usageget_watchlist_eventsmanage_watchlistScored across 7 tools
Each tool targets a distinct function: general events, AI brief, market pulse, scored leads, usage, watchlist events, and watchlist management. Overlap is minimal and clearly differentiated by context.
Six of seven tools follow 'get_X' pattern; 'manage_watchlist' breaks the pattern but is still clear. Convention is mostly consistent with a minor deviation.
Seven tools is well-scoped for a market intelligence server—enough to cover core use cases without being overwhelming. Each tool serves a clear purpose.
Covers key functionalities: events, summaries, leads, watchlist, and usage. Minor gaps like company search or automated alert settings are absent but not critical for the core workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
Private company data & real-time news signals for AI agents.
Real-time B2B buying signals on your target accounts: funding, hiring, leadership, tech stack.
AI-native B2B sales research, ranking, and CRM enrichment.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Fund-z/fundzwatch-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
