Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Company Changes

get_company_changes

Monitor a company domain for new hiring, tech stack, funding, firmographic, and social changes since the last run, returning only typed change events for GTM outreach.

Instructions

Monitor a company domain for changes across hiring, tech stack, funding, firmographics, and social since the last run. Returns only what changed as typed change events in flat, Clay-ready JSON. Pass sources to watch fewer than all five sources and min_severity to drop minor changes; each source left out is one fewer sub actor run on the bill. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
domainYesCompany domain to monitor, without https or www, e.g. stripe.com.
sourcesNoWhich sources to monitor. Omit for all five. Each source left out is one fewer sub actor run per company, so a single source watch is billed for one source, not five.
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 reports every change and is the default. high keeps leadership moves, funding, acquisitions, and a CRM or sequencer appearing or disappearing.
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
previous_snapshotNoSnapshot object returned by a prior run. Supply it and it is the baseline instead of stored state, which is what makes a scheduled run cheap.
sub_actor_timeout_secsNoPer-child run timeout in seconds. Children run in parallel, so total wall time is about the slowest child. Default: 300.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / sub_actor_timeout_secs / description
      Previous value: -"Per-child run timeout in seconds. Children run in parallel, so total wall time is about the slowest child. Default: 90."New value: +"Per-child run timeout in seconds. Children run in parallel, so total wall time is about the slowest child. Default: 300."
  2. Changed4 schema fields changedv1.1.1
    • addedInput schema / properties / min_severity
      Added value: +{
+  "description": "Report only changes at or above this severity. low reports every change and is the default. high keeps leadership moves, funding, acquisitions, and a CRM or sequencer appearing or disappearing.",
+  "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 the baseline instead of stored state, which is what makes a scheduled run cheap.",
+  "type": "object"
+}
    • addedInput schema / properties / sources
      Added value: +{
+  "description": "Which sources to monitor. Omit for all five. Each source left out is one fewer sub actor run per company, so a single source watch is billed for one source, not five.",
+  "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. Children run in parallel, so total wall time is about the slowest child. Default: 90.",
+  "type": "integer"
+}
  3. Addedv1.1.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only give the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false); the description adds substantive context beyond that: it reads public data, requires an APIFY_TOKEN, consumes Apify credits per call, bills per sub actor run, and stores a baseline snapshot. The phrase 'writes nothing' sits in mild tension with readOnlyHint=false, though that is most plausibly about external data rather than the billing/state side effects it does disclose.

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?

Four sentences, front-loaded with purpose and return shape, then parameter/cost guidance, then auth and billing constraints. Nothing is redundant, though the final sentence packs three separate constraints together rather densely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with a nested object and no output schema, the description covers purpose, cost model, auth requirement, and baseline behavior. The return value is only sketched ('typed change events in flat, Clay-ready JSON'), which is thin given no output schema exists, but it is enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: omitting 'sources' costs five sub actor runs versus one, and 'previous_snapshot' replaces stored state and makes scheduled runs cheap. These are real decision-relevant semantics layered on top of the field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Monitor a company domain for changes') and enumerates the five monitored dimensions, plus what is returned ('only what changed as typed change events'). It is clear what the tool does, but it never distinguishes itself from the sibling scan/detect tools (scan_gtm_hiring_signals, detect_gtm_tech_stack, get_funding_press_signals) that cover the same domains, leaving the delta framing as the only implicit differentiator.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Since the last run' and the snapshot baseline imply a recurring/scheduled monitoring use case, and the description advises passing 'sources' and 'min_severity' to reduce scope and cost. However, it never states when to prefer this aggregator over the individual sibling signal tools, so the when-to-use guidance remains implied rather than explicit.

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