company-change-event-feed
This server lets an AI client monitor company domains for changes over time and return only deltas as typed change events via the get_company_changes tool.
Run a first-time baseline for a company domain, then diff later runs against the stored snapshot to see only what changed.
Monitor changes across hiring, tech stack, firmographics, funding, and social presence, or select specific sources to reduce cost.
Filter results by minimum severity: low, medium, or high.
Pass a previous_snapshot to keep delta state outside Apify.
Batch multiple domains in one run with one output row per company.
Control run time and cost with sub_actor_timeout_secs and max_charge_usd.
Get structured outputs including change events with severity, confidence, old/new values, source actor ID, source_status, and a snapshot for the next comparison.
Use it on a schedule to watch target accounts; it is not intended for one-time company profiles.
Requires an APIFY_TOKEN and Apify credits; reads public data only and writes nothing.
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., "@company-change-event-feedCheck for changes at stripe.com"
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.
Company Change-Event Feed MCP Server
Company Change-Event Feed monitors a company domain for changes across hiring, tech stack, funding, firmographics, and social presence, then diffs the current state against your last run and returns only what changed as typed change events. Flat, Clay-ready JSON, one row per company, built for RevOps teams, outbound agencies, Clay users, and AI agents that need delta intelligence on target accounts.
What's Inside
Related MCP server: Government Contract Award Monitor MCP Server
What it does
This server gives an AI client one tool:
get_company_changes: monitor a company domain for changes across hiring, tech stack, funding, firmographics, and social since the last run. The first run for a domain records a clean baseline (no changes); every run after that returns only the deltas as typed change events, each with a severity, a confidence, an old and new value, and the immutable Actor ID of the source that produced it.
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": {
"company-change-event-feed": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-company-change-event-feed"],
"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 changed at stripe.com since the last check across hiring, tech stack, and firmographics?"
"Monitor hubspot.com and tell me only the high-severity changes."
"Run a baseline for deel.com (company name Deel), then check it next week for deltas."
"Did anything change in the GTM signals for notion.so?"
Tool and inputs
get_company_changes:
domain(string, required unlessdomainsis set): company domain to monitor, without https or www, e.g. stripe.com.domains(array, optional): batch mode, several company domains in one run with one output row each. When set and non-empty it overridesdomain.company_name(string, optional): company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com.sources(array, optional): which sources to monitor:hiring,tech_stack,firmographic,funding,social. Omit for all five. A source you do not select is not run and not charged, so this is the largest lever on cost.min_severity(string, optional):low(default, everything),medium(drops small noise),high(funding, acquisitions, exec moves, CRM changes and large hiring ramps only).previous_snapshot(object, optional): thesnapshotobject returned by a prior run. Supply it and it is used as the baseline instead of the stored snapshot, so you can hold delta state outside Apify. Ignored in batch mode.sub_actor_timeout_secs(integer, optional): per source run timeout in seconds, 5 to 300, default 300. The sources run in parallel, so total wall time is about the slowest source. Lower it to keep a quick test short.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.
sources and sub_actor_timeout_secs are the two controls on how long and how much a call costs: each selected source is one sub actor run.
The output is one row per company: company_domain, company_name, run_date, is_baseline, total_changes, has_high_severity, latest_change_date, a changes array of typed change events, a source_status object (ok / degraded / skipped / not_selected per source), and a snapshot object carrying the current state for the next run's comparison. Each change event has event_type, severity, confidence, old_value, new_value, and the source_actor immutable Actor ID.
The funding source runs the Funding and Press Signal Scanner, so funding, exec move, product launch, and acquisition events are reported like any other source.
The tool starts the actor run and polls it to a finished status, so a long run is not cut off at 300 seconds. The run is allowed 1,800 seconds. If it is still going two minutes after that, the call stops waiting and returns the run ID with a link to it in the Apify Console, where the results land when it finishes. A run that does not succeed comes back as an error with its run ID and status.
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.01 |
change source resolved ( | 0.01 |
Full actor documentation
For the complete input and output reference, pricing, and run history, see the Company Change-Event Feed actor on the Apify Store:
https://apify.com/mambalabs/company-change-event-feed
Mamba Labs GTM Suite
This server is part of the Mamba Labs GTM Suite, a fleet of 58 MCP servers for go-to-market data, each backed by a dedicated Apify actor. The table lists the actors the suite started with; every server is listed at https://mambabuilt.com.
Actor | Immutable Actor ID |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
Built by Mamba Labs | npm | Apify Store
License
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Available Tools
1 toolget_company_changesGet Company ChangesA
Monitor a company domain for changes across hiring, tech stack, funding, firmographics, and social since the last run. The first run for a domain records a baseline and reports no changes (is_baseline true); every later run diffs against the stored snapshot, or against previous_snapshot when you pass one, and returns only what changed as typed change events, each with severity, confidence, old and new value, and the source actor ID. One flat Clay-ready row per company, with source_status per source and a snapshot object for the next comparison. Use it on a schedule to watch target accounts for deltas. Do not use it for a one-time profile of a company (the Company Firmographic Enricher or a single source actor is cheaper), because each selected source is one sub actor run. Pass domains for a batch. Requires an APIFY_TOKEN and consumes Apify credits per source run. Reads public data only and writes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Company domain to monitor, without https or www, e.g. stripe.com. Required unless domains is set. | |
| domains | No | Batch mode: several company domains in one run, one output row each. When set and non-empty it overrides domain. previous_snapshot is ignored in batch mode. | |
| sources | No | Which sources to monitor. Omit for all five, the historical behavior. A source you do not select is not run and not charged, so this is the largest lever on the cost of a call: five sub actor runs become one. An unselected source is reported not_selected in source_status, which is deliberately different from degraded. | |
| company_name | No | Optional company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com. | |
| min_severity | No | Report only changes at or above this severity. low is everything and is the default. medium drops small noise such as follower count wobble. high keeps only funding, acquisitions, exec moves, CRM or sequencer changes and large hiring ramps, which is the setting for an alerting feed. | |
| max_charge_usd | No | Optional. The run stops before any charge that would take this run's total past this amount in USD, and every row already charged is kept. Leave it empty to rely only on the maximum cost per run set in Apify, which the actor also honors. | |
| previous_snapshot | No | Snapshot object returned by a prior run. Supply it and it is used as the baseline instead of the stored snapshot, so you can hold delta state outside Apify and keep a scheduled run cheap. | |
| sub_actor_timeout_secs | No | Per-child run timeout in seconds, 5 to 300. Children run in parallel, so total wall time is about the slowest child. Lower it to keep a quick test run short. Default: 300. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: first-run baseline vs. later diffing, snapshot persistence and previous_snapshot override, typed change events with severity/confidence/old-new values, per-source billing, and APIFY_TOKEN/auth requirement. The one wrinkle is 'writes nothing' sitting next to readOnlyHint=false, though the snapshot-storage discussion explains why the annotation is false while no target-system writes occur.
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-loads purpose, then baseline/diff behavior, then usage guidance and cost caveats; every sentence carries information and none is filler. It is a long single block, but dense rather than padded, so only a minor trim would help readability.
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 8-parameter tool with no output schema and nested objects, the description compensates well: it describes the returned row shape (source_status, snapshot object, change-event fields) and covers auth, cost model, batch mode, and baseline semantics. An agent has everything needed to call it correctly.
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 per-parameter meaning is already fully documented. The description reframes a few parameters in workflow terms (batch mode via domains, sources as the biggest cost lever, previous_snapshot for external state) but mostly restates what the schema already says, so the baseline of 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?
States a specific verb and resource: monitor a company domain for changes across five named categories (hiring, tech stack, funding, firmographics, social) since the last run. An agent knows exactly what the tool returns (typed change events, one flat row per company) and how it differs from a one-time profile tool, 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?
Explicitly names when to use it ('on a schedule to watch target accounts for deltas') and when not to ('Do not use it for a one-time profile of a company'), and routes to concrete alternatives (Company Firmographic Enricher, a single source actor) with the cost reason. This is the full when/when-not/alternative pattern.
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.4.1- Changed
get_company_changes8 fields changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Company domain to monitor, without https or www, e.g. stripe.com."New value: +"Company domain to monitor, without https or www, e.g. stripe.com. Required unless domains is set." - added
Input schema / properties / domainsAdded value: +{ + "description": "Batch mode: several company domains in one run, one output row each. When set and non-empty it overrides domain. previous_snapshot is ignored in batch mode.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / max_charge_usdAdded value: +{ + "description": "Optional. The run stops before any charge that would take this run's total past this amount in USD, and every row already charged is kept. Leave it empty to rely only on the maximum cost per run set in Apify, which the actor also honors.", + "minimum": 0, + "type": "number" +} - added
Input schema / properties / min_severityAdded value: +{ + "description": "Report only changes at or above this severity. low is everything and is the default. medium drops small noise such as follower count wobble. high keeps only funding, acquisitions, exec moves, CRM or sequencer changes and large hiring ramps, which is the setting for an alerting feed.", + "enum": [ + "low", + "medium", + "high" + ], + "type": "string" +} - added
Input schema / properties / previous_snapshotAdded value: +{ + "additionalProperties": {}, + "description": "Snapshot object returned by a prior run. Supply it and it is used as the baseline instead of the stored snapshot, so you can hold delta state outside Apify and keep a scheduled run cheap.", + "type": "object" +} - added
Input schema / properties / sourcesAdded value: +{ + "description": "Which sources to monitor. Omit for all five, the historical behavior. A source you do not select is not run and not charged, so this is the largest lever on the cost of a call: five sub actor runs become one. An unselected source is reported not_selected in source_status, which is deliberately different from degraded.", + "items": { + "enum": [ + "hiring", + "tech_stack", + "firmographic", + "funding", + "social" + ], + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / sub_actor_timeout_secsAdded value: +{ + "description": "Per-child run timeout in seconds, 5 to 300. Children run in parallel, so total wall time is about the slowest child. Lower it to keep a quick test run short. Default: 300.", + "maximum": 300, + "minimum": 5, + "type": "integer" +} - removed
Input schema / requiredRemoved value: -[ - "domain" -]
1 tool update
v1.0.0- First observed
get_company_changes
TDQS
Scored across 1 tool
With only one tool in the set, there is no possibility of selecting the wrong tool, and the description clearly scopes it to change detection over time rather than one-time enrichment. It even explicitly names the sibling tools to use for the excluded use case, removing boundary confusion.
The single tool uses a clean snake_case verb_noun pattern (get_company_changes) that would extend predictably to siblings. There are no competing conventions to conflict with.
For a change-feed domain, one operation-centric tool is defensible since baseline/diff behavior is folded into it, but a single tool is a thin surface for a server. It leans borderline rather than comfortably scoped.
The tool covers the core lifecycle: baseline capture, diffing against stored or explicit snapshots, typed change events, per-source status, and batching. Minor gaps remain, such as no way to list known domains, inspect or reset a stored snapshot, or query historical change events.
Maintenance
Related MCP Connectors
Give an AI agent eyes on the web: turn any feed, page, or stream into deduplicated change events.
Open jobs and hiring changes for any company, from its domain. Runs on Apify.
Enrich any domain into a full company profile with firmographics and buying signals.
Find companies hiring for a role and geo, qualify them, and watch them for changes.
Related MCP Servers
- AlicenseAqualityAmaintenanceScans public news and press for a company's funding rounds, executive moves, product launches, acquisitions, partnerships, and IPOs, returning deduplicated events in flat JSON.1237 npmMIT
- AlicenseAqualityAmaintenanceEnables monitoring public contract awards from US and UK registers, returning companies that won public work with award details and resolved domains.1215 npmMIT
- AlicenseAqualityCmaintenanceEnables enrichment of company domains with verified firmographic signals including tech stack, hiring activity, email infrastructure, and SOC 2 compliance, returning compact typed JSON for AI agents.31 npmMIT
- AlicenseAqualityCmaintenanceRevnuvo Company Intelligence tells AI agents what changed at a company, with evidence. It observes company websites, technologies, and DNS over time and returns timestamped, confidence-aware changes, signals, and monitoring.9MIT