Skip to main content
Glama
mambalabsdev

company-change-event-feed

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get Company Changes

get_company_changes

Monitor a company domain for changes in hiring, tech stack, funding, firmographics, and social. Returns only deltas as typed change events for scheduled account tracking.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
domainNoCompany domain to monitor, without https or www, e.g. stripe.com. Required unless domains is set.
domainsNoBatch 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.
sourcesNoWhich 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_nameNoOptional company name hint, used when the domain does not match the brand name, e.g. Deel for deel.com.
min_severityNoReport 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_usdNoOptional. 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_snapshotNoSnapshot 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_secsNoPer-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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.4.1
    • changedInput schema / properties / domain / description
      Previous 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."
    • addedInput schema / properties / domains
      Added 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"
+}
    • addedInput schema / properties / max_charge_usd
      Added 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"
+}
    • addedInput schema / properties / min_severity
      Added 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"
+}
    • addedInput schema / properties / previous_snapshot
      Added 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"
+}
    • addedInput schema / properties / sources
      Added 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"
+}
    • addedInput schema / properties / sub_actor_timeout_secs
      Added 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"
+}
    • removedInput schema / required
      Removed value: -[
-  "domain"
-]
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools