Get a composite GTM signal score for one company domain via a single MCP tool.
Score a company by its bare domain (e.g., stripe.com) and receive a flat JSON row.
Aggregate any combination of signals: hiring, tech_stack, funding, events, workplace (default: hiring, tech_stack).
Include a plain-English gtm_signal_summary (include_summary) or request a longer detailed explanation (explain_mode).
Get a composite_score, composite_signal, recommended_action, and underlying hiring/tech-stack signals in one row.
Use it read-only in MCP clients (e.g., Claude Desktop) for Clay, CRM, or AI agent workflows; consumes Apify credits.
An MCP server that rolls a company's go-to-market signals into one composite score. It wraps the Mamba Labs GTM Signals Aggregator actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-gtm-hiring-signal-scraper
Give it a company domain and it runs hiring-signal and tech-stack detection together, then returns a single composite GTM score, a recommended action, and an optional plain-English summary. One call, one row, ready to drop into Clay, a CRM, or an AI agent workflow. All of the analysis runs on Apify. This package is a thin client that calls the actor and hands back the result.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-gtm-signals": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-gtm-signals-aggregator"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The aggregate_gtm_signals tool will be available.
Node.js 18 or newer
An Apify account with an API token
"Give me the overall GTM signal score for stripe.com."
"How strong a GTM target is openai.com? Aggregate their signals."
"Score figma.com on hiring and tech stack, and explain why."
"Pull the composite GTM signal for datadoghq.com with a summary."
Every input the tool accepts, generated from the server's own tool list.
Input | Type | Required | Description |
| string | yes | Bare company domain without https:// and without a trailing slash. Example: stripe.com |
| array of | no | Which signals to aggregate. Default ["hiring", "tech_stack"], which is what this actor has always run. Each extra source is one more sub actor run on the caller's own Apify account, so this is the cost dial as well as the depth dial. The composite score is normalized over the sources you selected, so a funding only run is scored on its own scale rather than capped by absent sources. |
| boolean | no | Include a plain-English gtm_signal_summary field in the output. Defaults to the actor's default when omitted. |
| boolean | no | If true, gtm_signal_summary becomes a longer, more detailed explanation instead of a 1 to 2 sentence summary. |
| number | no | Optional spending cap for this call, in USD. The actor stops before any charge that would take the run past this amount and keeps every row already charged. |
The tool returns the actor's flat JSON row for the scanned company, including the composite GTM score, a recommended action, the underlying hiring and tech-stack signals, and an optional summary. See the Apify Store page for the full output schema.
{
"company_domain": "notion.so",
"composite_signal": "strong",
"composite_score": 82,
"recommended_action": "prioritize",
"gtm_hiring_signal": true,
"signal_strength": "high",
"gtm_role_count": 9,
"crm_detected": "salesforce",
"tech_stack_signal": "high",
"gtm_tool_count": 5,
"run_date": "2026-05-28"
}Combines hiring signals and tech stack detection in a single call
Flat row with composite_score, composite_signal, and recommended_action
Optional plain-English gtm_signal_summary
Designed for AI agent consumption
It does one thing: one composite GTM score for one company per call, built from the sources you pick in sources (hiring, tech stack, funding, events, workplace).
Each extra source is one more sub actor run on your own Apify account, so sources is both the depth dial and the cost dial.
It does not return the underlying signals one by one. For those, call the single purpose servers, or install @mambalabsdev/mcp-gtm-suite, which carries this tool and twenty other account-intelligence tools in one server.
It reads public company pages only. It writes nothing anywhere.
You pay per event on Apify, billed to your own Apify account. Prices from the live pricing record, read 2026-10-16:
Event | Price per event (USD) | Fires when |
| $0.055 on the Free plan, down to $0.0385 on higher Apify plans | Single result in the default dataset. |
| $0.00005 | Charged when the Actor starts running. Number of events charged depends on Actor memory (one event per GB, minimum one event). |
The actor's Apify page carries the current prices. Running this server consumes Apify credits.
Each call starts the actor run, polls it until it finishes, then reads the dataset. The run is allowed 1,800 seconds. If the run is still going when this call stops waiting, the call returns the run id and a console link instead of a timeout, so the result is never lost.
This server is a thin client and holds no analysis logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/b2b-buying-signals-hiring-tech-stack-intent-for-clay
This server is one of 58 Mamba Labs MCP servers, each backed by a dedicated Apify actor and published under @mambalabsdev on npm. The ones closest to this server:
Actor | Immutable Actor ID |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
To get twenty one of them in one install, use @mambalabsdev/mcp-gtm-suite.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Aggregate a company's GTM signals into one composite score. Runs hiring-signal and tech-stack detection in a single call and returns a flat, Clay-ready JSON row with a composite GTM score, a recommended action, and an optional plain-English summary. Read-only; requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | Which signals to aggregate. Default ["hiring", "tech_stack"], which is what this actor has always run. Each extra source is one more sub actor run on the caller's own Apify account, so this is the cost dial as well as the depth dial. The composite score is normalized over the sources you selected, so a funding only run is scored on its own scale rather than capped by absent sources. | |
| explain_mode | No | If true, gtm_signal_summary becomes a longer, more detailed explanation instead of a 1 to 2 sentence summary. | |
| company_domain | Yes | Bare company domain without https:// and without a trailing slash. Example: stripe.com | |
| include_summary | No | Include a plain-English gtm_signal_summary field in the output. Defaults to the actor's default when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower. The description goes beyond them usefully by naming the required APIFY_TOKEN and the fact that each call consumes Apify credits, which is real operational context an agent should know before invoking.
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?
Three sentences, front-loaded with the core action, then output shape, then auth/cost caveat. No filler and nothing repeated from the title.
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?
With no output schema, the description does its job by naming the return payload (composite GTM score, recommended action, optional plain-English summary). It stops short of describing failure modes or latency, which would be nice but is not required for correct invocation.
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 coverage is 100%, including rich prose on the 'sources' cost/depth dial and normalization behavior, so the schema carries parameter meaning fully. The description adds nothing parameter-specific beyond what the schema already documents; baseline 3 applies.
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 ('Aggregate a company's GTM signals into one composite score') and enumerates the concrete work performed ('runs hiring-signal and tech-stack detection in a single call'). Cheap to tell apart from anything else and leaves no ambiguity about the output artifact.
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?
Implies the usage context (call it to obtain a composite GTM score and recommended action) and notes the auth/cost precondition, but never says when to reach for this versus building the signals separately, nor when a narrower call would suffice. No sibling tools exist, so the routing burden is low and a 3 is fair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.6aggregate_gtm_signals2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / sourcesAdded value: +{
+ "description": "Which signals to aggregate. Default [\"hiring\", \"tech_stack\"], which is what this actor has always run. Each extra source is one more sub actor run on the caller's own Apify account, so this is the cost dial as well as the depth dial. The composite score is normalized over the sources you selected, so a funding only run is scored on its own scale rather than capped by absent sources.",
+ "items": {
+ "enum": [
+ "hiring",
+ "tech_stack",
+ "funding",
+ "events",
+ "workplace"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}v1.0.3aggregate_gtm_signalsScored across 1 tool
With only one tool in the set, there is no possibility of an agent confusing it with another tool. Its purpose—producing a composite GTM score plus recommended action—is stated unambiguously.
The single name aggregate_gtm_signals follows a clean verb_noun snake_case convention that would scale predictably. Consistency cannot be fully demonstrated across a set of one, so it falls just short of a 5.
A single tool is borderline thin for a server branded as a 'signals aggregator'; the composite design is defensible, but there is no surface for retrieving individual signals, batching companies, or inspecting components.
The one-tool surface covers the headline aggregation use case end-to-end, but it is read-only and monolithic, leaving no way to access raw hiring/tech-stack signals, batch multiple companies, or tune scoring inputs.
Open jobs from a company's ATS, plus hiring, tech stack, intent, email-security and launch signals.
Extracts verified emails, social links, 40+ tech stack signals, pricing tiers, and company summary
Company Insights: job postings, tech stack, news events, key customers, similar companies...
Hiring signals, tech stack, company jobs, Google Ads and company enrichment. x402 on Base.
