company-change-event-feed
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token for authentication |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.