mcp-gtm-suite

Scan GTM Hiring Signals

scan_gtm_hiring_signals

Idempotent

Detect go-to-market hiring by scanning company career pages and returning sales, marketing, and revenue ops postings from Greenhouse, Lever, and Ashby as Clay-ready JSON.

Instructions

Scan company career pages to detect GTM hiring activity. Returns sales, marketing, and revenue operations job postings across Greenhouse, Lever, and Ashby as a flat, Clay-ready JSON row. Use this for a go-to-market hiring verdict (is the company building its sales and marketing team, and how fast); use scan_job_board_keywords instead to count open roles in categories or keywords you choose, including non-GTM roles. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

Name	Required	Description
`mode`	No	Processing mode. "single" scores the domain. "velocity" compares this run against previous_gtm_role_count and previous_run_date. "batch" is an actor-level mode this single-call tool supplies no list for. Default: "single".
`domain`	Yes	Bare company domain, e.g. stripe.com
`ats_slug`	No	Optional ATS board slug override when it differs from the domain.
`role_filter`	No	Optional list of GTM role keywords to filter on. Defaults to the built-in list.
`max_charge_usd`	No	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.
`previous_run_date`	No	ISO date of the previous run for this domain, used in velocity mode to report days between runs.
`include_role_details`	No	When true, include the full per-role detail array (title, department, location, url). Default: false.
`previous_gtm_role_count`	No	GTM role count from the previous run for this domain, used in velocity mode to compute the delta.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.14.0Oct 16, 2026

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"
+}

Changed4 schema fields changedv1.1.1Oct 13, 2026

addedInput schema / properties / include_role_details

Added value: +{
+  "description": "When true, include the full per-role detail array (title, department, location, url). Default: false.",
+  "type": "boolean"
+}

addedInput schema / properties / mode

Added value: +{
+  "description": "Processing mode. \"single\" scores the domain. \"velocity\" compares this run against previous_gtm_role_count and previous_run_date. \"batch\" is an actor-level mode this single-call tool supplies no list for. Default: \"single\".",
+  "enum": [
+    "single",
+    "batch",
+    "velocity"
+  ],
+  "type": "string"
+}

addedInput schema / properties / previous_gtm_role_count

Added value: +{
+  "description": "GTM role count from the previous run for this domain, used in velocity mode to compute the delta.",
+  "type": "integer"
+}

addedInput schema / properties / previous_run_date

Added value: +{
+  "description": "ISO date of the previous run for this domain, used in velocity mode to report days between runs.",
+  "type": "string"
+}

First observedv1.0.3Jun 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds genuinely useful context not in the annotations: it reads public data, writes nothing, requires an APIFY_TOKEN, and consumes Apify credits per call. It does not disclose rate limits or failure modes, but for a read-only scraper this is strong additional context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what it does and what it returns, followed by the routing rule to the sibling, then the operational requirements. Every sentence earns its place with no filler.

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 an 8-param, no-output-schema, open-world scraper, the description covers purpose, return shape ("flat, Clay-ready JSON row"), routing, and operational prerequisites. Slightly less than complete because it doesn't mention the batch mode's limitation (that this single-call tool supplies no list) which the schema notes, but the schema already carries that.

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 all 8 parameters (including mode's enum semantics and velocity-mode dependencies on previous_gtm_role_count/previous_run_date) are already fully documented in the schema. The description adds no parameter-level detail beyond what the schema provides, which is correct given full coverage — baseline 3.

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 (scan) and resource (career pages) and defines the narrow scope (GTM hiring activity: sales, marketing, revops). It explicitly names the sibling it differs from, scan_job_board_keywords, and the axis of difference (GTM-only vs arbitrary keyword counts).

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?

Provides an explicit when-to-use case ("for a go-to-market hiring verdict") and an explicit alternative with the condition that selects it ("use scan_job_board_keywords instead to count open roles in categories or keywords you choose, including non-GTM roles"). No inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Scan GTM Hiring Signals

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools