Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Scan Job Board Keywords

scan_job_board_keywords
Idempotent

Scan a company's job board for roles in chosen categories across Greenhouse, Lever, Ashby, Workday, and Rippling, returning matched role counts and titles.

Instructions

Scan a company's job board for roles in chosen categories across Greenhouse, Lever, Ashby, Workday, and Rippling. Returns matched role counts and titles per category as a flat, Clay-ready JSON row. Use this when you choose the role categories or keywords (engineering, finance, a product name in a job ad); use scan_gtm_hiring_signals instead for the fixed sales and marketing hiring verdict. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

NameRequiredDescriptionDefault
company_domainYesBare company domain, e.g. stripe.com
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.
custom_keywordsNoKeyword strings to match when Custom is included in role_categories.
enable_fallbackNoFall back to a pre-indexed job database when the live ATS cascade finds nothing.
role_categoriesYesOne or more of: GTM, Engineering, Finance, Operations, Executive, Custom.
previous_run_dateNoISO date of the previous run, e.g. 2026-03-15.
previous_roles_detectedNoComma-separated matched role titles from a previous run, to compute deltas.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
+}
  2. First observedv1.0.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations cover openWorld, idempotent and destructive hints, so the description's job is to add what they don't say — and it does: requires an APIFY_TOKEN, consumes Apify credits per call, and reads public data only. There is a mild tension between readOnlyHint=false and the phrase 'writes nothing', though the consumer of Apify credits plausibly explains the false hint; no strong contradiction.

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 tightly packed sentences with the purpose front-loaded and no filler. The final sentence stacks four separate facts (public data, no writes, token requirement, credit cost) which makes it dense, but each clause earns its place.

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?

With no output schema, the description tells the agent what comes back (matched role counts and titles per category as a flat, Clay-ready JSON row). Combined with full schema coverage on all seven parameters and the cost/auth disclosure, an agent has everything needed to call this 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that role_categories are user-chosen (engineering, finance, a product name in a job ad) and that custom_keywords work with the Custom category, giving the agent the intent behind two of the seven parameters.

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 (a company's job board for roles in chosen categories), and names the exact surface it covers (Greenhouse, Lever, Ashby, Workday, Rippling) plus the return shape. It also names the sibling it is not (scan_gtm_hiring_signals), so an agent can distinguish the two without opening a 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?

Gives an explicit selection rule: use this one 'when you choose the role categories or keywords'; use scan_gtm_hiring_signals 'instead for the fixed sales and marketing hiring verdict.' That is a clean when/when-not with the alternative named.

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