Funding & Press Signal Scanner MCP Server
Scan company domains for recent public business signals via one MCP tool.
Find funding rounds, IPOs, acquisitions, executive moves, product launches, and partnerships from Google News and PR wires.
Return deduplicated, dated events as flat Clay-ready JSON, one row per company, with company summaries and structured event details.
Filter by event type with
signal_typesand control the search window withlookback_days(default 365).Batch scan multiple domains in one call using
domains, and provide acompany_namehint when the domain differs from the brand.Requires an Apify token and consumes Apify credits.
Scans Google News to retrieve recent business events (funding rounds, executive moves, product launches, acquisitions, partnerships, IPOs) for a given company domain.
Click on "Deploy 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., "@Funding & Press Signal Scanner MCP ServerScan stripe.com for recent funding and exec moves"
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.
Funding & Press Signal Scanner MCP Server
Give it a company domain, get back a clean list of that company's recent business events: funding rounds, executive moves, product launches, acquisitions, partnerships, and IPOs. The actor searches public news and press sources, classifies each story into a typed event, deduplicates the same event reported across multiple outlets, and returns one flat row per company. Built for Clay users, RevOps teams, and outbound agencies who want account signals without paying for a Crunchbase seat.
What's Inside
Related MCP server: FundzWatch MCP Server
What it does
This server gives an AI client one tool:
get_funding_press_signals: scan Google News and PR wires for a company's funding rounds, executive moves, product launches, acquisitions, partnerships, and IPOs. Returns deduplicated, dated events in flat, Clay-ready JSON, one row per company, with a per company summary (has_recent_funding,funding_total_estimated,latest_event_date,most_recent_event_type) and aneventsarray where each event carries its type, date, amount, funding stage, source URL, and a corroborating source count.
All of the work runs on Apify. This package is a thin client that routes the tool call to the actor and hands back the result.
Quick start
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"funding-press-signal-scanner": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-funding-press-signal-scanner"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The tool will be available.
Prerequisites
Node.js 18 or newer
An Apify account with an API token
Example prompts
"What funding, exec moves, and product launches has stripe.com had recently?"
"Has ramp.com raised any funding in the last year, and how much?"
"Scan deel.com (company name Deel) for acquisitions and partnerships."
"Show me the most recent press events for notion.so as flat JSON."
"Scan stripe.com, ramp.com, and deel.com for funding rounds in the last 90 days."
Tool and inputs
get_funding_press_signals:
domain(string, required): company domain to scan, without https or www, e.g. stripe.com.company_name(string, optional): company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com.signal_types(array, optional): report only these event types:funding_round,ipo,acquisition,exec_move,product_launch,partnership. Narrowing narrows the search as well as the answer. Omit for every type.lookback_days(integer, optional): how far back to search, in days. Default 365.domains(array, optional): a list of company domains scanned in one run, one row per company. When set and non-empty it overridesdomain(still required by the schema, so pass the first domain there too).max_charge_usd(optional): a cost cap in USD for this run. The actor stops before an item that could take its charges past this amount. Omit it to rely on the maximum cost per run set in Apify.
The output is one row per company: company_domain, company_name, total_events, latest_event_date, has_recent_funding, funding_total_estimated, funding_total_currency, most_recent_event_type, most_recent_headline, an events array of typed events, a sources_queried array, and run_date. Each event in the array has event_type (funding_round, exec_move, product_launch, acquisition, partnership, ipo), date, headline, source_url, source_name, amount, currency, funding_stage, names, description, and corroborating_source_count.
Pricing
Price per event on the Apify FREE plan, from the live pricing record; paid Apify plans pay less per event.
Event | Price (USD) |
Actor Start ( | 0.00005 |
result ( | 0.03 |
Full actor documentation
For the complete input and output reference, pricing, and run history, see the Funding & Press Signal Scanner actor on the Apify Store:
https://apify.com/mambalabs/funding-press-signal-scanner
Mamba Labs GTM Suite
This server is one of 58 Mamba Labs MCP servers, each a thin client for one Mamba Labs actor on Apify. Every actor returns flat, Clay-ready rows that join on the company domain.
Browse every server: https://mambabuilt.com/servers
Browse every actor on the Apify Store: https://apify.com/mambalabs
Built by Mamba Labs | npm | Apify Store
License
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Available Tools
1 toolget_funding_press_signalsGet Funding and Press SignalsARead-onlyIdempotent
Scan Google News and PR wires for funding rounds, executive moves, product launches, and acquisitions at any company domain. Returns deduplicated, dated events in flat Clay-ready JSON. Use it to find a trigger for outbound (a fresh raise, a new executive) or to qualify an account before a call. Pass signal_types to report one kind of event, lookback_days to set the window, and domains to scan a list in one call. Requires APIFY_TOKEN; consumes Apify credits.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain to scan, without https or www, e.g. stripe.com. | |
| domains | No | Optional list of company domains to scan in one run, one row per company. When set and non-empty it overrides domain; still pass the first domain as domain, which the schema requires. | |
| company_name | No | Optional company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com. | |
| signal_types | No | Report only these event types. Narrowing narrows the search as well as the answer, so a funding only scan issues one news query instead of four. Omit for every type. | |
| lookback_days | No | How far back to search, in days. Default 365. Shorten it for trigger based outbound, where a raise from eleven months ago is not a trigger. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts: output is deduplicated and dated, it requires APIFY_TOKEN, and it consumes Apify credits — auth and cost context the annotations do not carry. Rate limits or failure behavior are still unstated, keeping it short of a 5.
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?
Front-loaded with the core verb+resource, then use cases, then parameters. Five sentences, all carrying information. Slightly dense with parentheticals, but no filler sentences.
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 exists, and the description compensates by naming the return shape (deduplicated dated events, flat Clay-ready JSON). Auth requirement and cost are disclosed, and every parameter's purpose is touched. Missing only edge-case behavior (empty results, partial failures) for a 5.
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 baseline is 3; the description earns above that by explaining the non-obvious cost/behavior tradeoff of signal_types ('a funding only scan issues one news query instead of four') and the recency reasoning behind lookback_days. It does not add syntax beyond the schema, but it adds decision-relevant meaning.
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?
States a concrete verb and resource set — 'Scan Google News and PR wires for funding rounds, executive moves, product launches, and acquisitions' — and names the specific output ('deduplicated, dated events in flat Clay-ready JSON'). An agent can tell exactly what this does without opening the schema.
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?
Gives explicit use cases ('find a trigger for outbound (a fresh raise, a new executive)' and 'qualify an account before a call') and even explains the parameter intent ('Shorten it for trigger based outbound, where a raise from eleven months ago is not a trigger'). With no sibling tools, there are no alternatives to exclude, so nothing is left to inference.
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 tool update
v1.0.2- Changed
get_funding_press_signals4 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / domainsAdded value: +{ + "description": "Optional list of company domains to scan in one run, one row per company. When set and non-empty it overrides domain; still pass the first domain as domain, which the schema requires.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / lookback_daysAdded value: +{ + "description": "How far back to search, in days. Default 365. Shorten it for trigger based outbound, where a raise from eleven months ago is not a trigger.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - added
Input schema / properties / signal_typesAdded value: +{ + "description": "Report only these event types. Narrowing narrows the search as well as the answer, so a funding only scan issues one news query instead of four. Omit for every type.", + "items": { + "enum": [ + "funding_round", + "ipo", + "acquisition", + "exec_move", + "product_launch", + "partnership" + ], + "type": "string" + }, + "type": "array" +}
1 tool update
v1.0.0- First observed
get_funding_press_signals
TDQS
Scored across 1 tool
With only a single tool in the set, there is no possibility of overlap or misselection. The tool's purpose—scanning for funding and press signals—is unambiguous and self-contained.
The lone name get_funding_press_signals follows a clear verb_noun pattern and is descriptive of its function. There are no competing conventions to conflict with it.
A single tool is on the thin side for a server, even though this one is parameter-rich (signal_types, lookback_days, domains) and covers several event categories. It works, but the surface feels narrow for the stated scanning domain.
For a read-only signal scanner the core need—retrieving deduplicated, dated funding, exec, launch, and acquisition events—is covered with configurable filters. Minor gaps exist (no save/export, alerting, or targeting helpers), but the primary workflow is complete.
Maintenance
Related MCP Connectors
Structured company & industry news for AI agents: typed, dated, source-linked events.
Deduplicated, entity-resolved funding rounds, acquisitions, and exec moves as MCP tools.
Detect material changes in public companies since a specified date using primary sources.
Private company data, entity-resolved news, targeted lists, and alternative signals for AI agents.
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceEnables deep analysis of SEC EDGAR filings through universal company search, document content extraction, and advanced filing search capabilities. Provides AI-ready access to business descriptions, risk factors, financial statements, and full-text search across any public company's SEC documents.-
- AlicenseAqualityCmaintenanceProvides real-time business event intelligence and AI-scored sales leads to help users track funding rounds, acquisitions, and executive hires. It enables AI agents to generate strategic market briefs and manage company watchlists for predictive business insights.729 npm3MIT
- AlicenseAqualityAmaintenanceDetects hiring intent signals by scanning job boards for specific companies. Returns structured role data for outbound sales targeting.1250 npm1MIT
- AlicenseAqualityAmaintenanceRuns all GTM signal tools in a single call and returns a unified company intelligence report combining hiring, tech stack, LinkedIn, and job board data.1126 npmMIT