Skip to main content
Glama
mambalabsdev

Job Posting Monitor MCP Server

Job Posting Monitor MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

MCP server for the Mamba Labs Job Posting Monitor actor on Apify.

Give it a list of role keywords and it returns the companies currently advertising those roles, one flat row per posting, each enriched with firmographics and the company LinkedIn URL.

Install

npx -y @mambalabsdev/mcp-gtm-job-discovery

Claude Desktop

{
  "mcpServers": {
    "mamba-gtm-job-discovery": {
      "command": "npx",
      "args": ["-y", "@mambalabsdev/mcp-gtm-job-discovery"],
      "env": { "APIFY_TOKEN": "your-apify-token" }
    }
  }
}

Get an Apify token at console.apify.com/account/integrations.

Related MCP server: mcp-job-board-keyword-signal-scanner

Tool

monitor_job_postings

Give it a list of role keywords and it returns the companies currently advertising those roles, one flat row per posting, each enriched with firmographics and the company LinkedIn URL.

Input

Type

Required

Notes

keywords

array

yes

Role titles to search for, one per entry. Each keyword runs through the source chain separately.

sources

array

no

Job boards, run as an ordered chain. Tier 0, no key: jobicy, remotive, arbeitnow, themuse, remoteok, weworkremotely, himalayas. Tier 1: adzuna (needs adzuna_app_id and adzuna_app_key). Tier 2, only for keywords still short: jobspipe, theirstack (each needs its key) and google_jobs (needs serpapi_key). A posting on two boards is counted once. Default ["google_jobs"].

country

string

no

Geographic filter, for example United States, United Kingdom, Canada. Default United States.

countries

array

no

Loop these countries in one run. Overrides country when set.

lookback_days

integer

no

Only return postings newer than this many days. Default 30.

company_size_min

integer

no

Drop companies with fewer employees than this (applied only when company size is known).

company_size_max

integer

no

Drop companies larger than this (applied only when company size is known).

exclude_staffing_agencies

boolean

no

Filter out staffing and recruitment agency postings. Default true.

exclude_freelance_marketplaces

boolean

no

Filter out postings where the company is a freelance marketplace (Upwork, Fiverr, and others). Default true.

freelance_marketplaces

array

no

Company names treated as freelance marketplaces. Default ["Upwork", "Fiverr", "Freelancer", "Toptal", "PeoplePerHour", "Guru", "99designs"].

remote_only

boolean

no

Only return remote postings. Default false.

previous_run_date

string

no

ISO date of your last run, for example 2026-06-01. Only newer postings are emitted, on top of the built in cross run delta cache.

max_results

integer

no

Upper bound on raw postings pulled before filtering. Higher values cost more. Default 100.

max_companies

integer

no

Cap on unique companies enriched per run (firmographics and LinkedIn). Default 40.

serpapi_key

string

no

Your SerpAPI key for the google_jobs source (free key at serpapi.com, 250 searches a month).

adzuna_app_id

string

no

Your Adzuna application id for the adzuna source.

adzuna_app_key

string

no

Your Adzuna application key for the adzuna source.

jobspipe_key

string

no

Your JobsPipe key for the jobspipe source. Billed by JobsPipe per job returned.

theirstack_key

string

no

Your TheirStack key for the theirstack source. Billed by TheirStack per job returned.

metered_window_days

integer

no

Ask the metered sources only for postings this many days old or newer, 1 to 7. Default 2.

enough_new_companies_per_keyword

integer

no

Stop the chain for a keyword once this many new companies are found. Default 3.

metered_run_cap

integer

no

Ceiling per metered source per country per run. Default 50.

Keys passed as inputs travel in the tool call and stay in the chat transcript.

Billing

You are charged per result row returned, plus a small actor start fee. Filtered postings are free.

Pricing is on the actor's Apify page. Running this server consumes Apify credits.

What this server does and does not do

It is a thin client for the Apify actor. It passes your input through and returns the actor's output unchanged. Every behavior described above lives in the actor, not here.

Errors are surfaced, never swallowed. An invalid input, an invalid token, an exhausted balance, a timeout, or a run that returns anything other than a dataset all come back as an explicit tool error rather than as an empty result.

Source

The actor is on the Apify Store. This wrapper is MIT licensed.

Built by Mamba Labs

Available Tools

1 tool
monitor_job_postingsMonitor Job PostingsA
Read-onlyIdempotent

Find companies that are hiring for a set of role keywords across public job boards, and return one flat row per posting enriched with company firmographics and the company LinkedIn URL. Discovery runs through Google Jobs, and passing your own SerpAPI key runs that search on your own quota. Postings are filtered by age, by country, and optionally by employee count, and staffing agencies and freelance marketplaces are dropped by default because they are noise for direct outreach. A cross run delta cache means a repeat run returns only postings it has not emitted before, and previous_run_date lets you set that watermark yourself. max_results caps how many raw postings are pulled before filtering and max_companies caps how many unique companies get enriched, so the two together are the cost dial. Requires an APIFY_TOKEN and consumes Apify credits. Read only: this discovers and enriches, it writes nothing.

ParametersJSON Schema
NameRequiredDescriptionDefault
countryNoGeographic filter, e.g. United States, United Kingdom, Canada. Default: "United States".
keywordsYesEditorial / content role titles to search for across job boards.
max_resultsNoUpper bound on raw postings pulled from the discovery source before filtering. Higher values cost more. Default: 100.
remote_onlyNoOnly return remote / work-from-home postings. Default: false.
serpapi_keyNoSerpAPI key used for Google Jobs discovery (get a free key at serpapi.com, 250 searches/month, no card). Required to produce results unless a SERPAPI_KEY environment variable is set on the actor.
lookback_daysNoOnly return postings newer than this many days. Default: 30.
max_companiesNoCap on unique companies enriched per run (firmographics + LinkedIn). Bounds sub-actor cost. Default: 40.
company_size_maxNoOptional. Drop companies larger than this (only applied when company size is known).
company_size_minNoOptional. Drop companies with fewer employees than this (only applied when company size is known).
previous_run_dateNoOptional ISO date (e.g. 2026-06-01) of your last run. Only postings newer than this are emitted, on top of the built-in cross-run delta cache.
freelance_marketplacesNoCompany names treated as freelance marketplaces and excluded when the toggle above is on. Defaults shown; override or extend as needed. Default: ["Upwork", "Fiverr", "Freelancer", "Toptal", "PeoplePerHour", "Guru", "99designs"].
exclude_staffing_agenciesNoFilter out staffing and recruitment agency postings using name and job-description heuristics. Default: true.
exclude_freelance_marketplacesNoFilter out postings where the company is a freelance marketplace (Upwork, Fiverr, etc.), which are noise for direct outreach. Default: true.

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond annotations: it requires an APIFY_TOKEN, consumes Apify credits, uses Google Jobs/SerpAPI, explains the cross-run delta cache, and clarifies that max_results and max_companies act as cost dials. This openly discloses operational side effects and aligns with the readOnlyHint.

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?

The description is a single dense paragraph that front-loads the core purpose before diving into filtering, caching, and cost controls. Every sentence adds value, though it could be broken into clearer sentences for readability. It is appropriately sized for the tool's complexity.

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?

Given the tool has 13 parameters and no output schema, the description covers the essential context: output format (flat row with firmographics and LinkedIn URL), auth requirements, cost implications, default exclusions, and delta cache behavior. It does not enumerate all output fields but provides enough for an agent to understand what will be returned.

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?

The input schema already covers 100% of parameters with descriptions. The tool description adds macro-level semantics, such as the relationship between max_results and max_companies as a combined cost dial and the watermark behavior of previous_run_date. This enriches but does not repeat the schema.

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?

The description opens with a specific verb and resource: 'Find companies that are hiring for a set of role keywords across public job boards, and return one flat row per posting enriched with company firmographics and the company LinkedIn URL.' This clearly states the tool's function and output, distinguishing it from vague or tautological descriptions.

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

Usage Guidelines4/5

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

The description explains the intended use case (direct outreach) by noting that staffing agencies and freelance marketplaces are dropped as noise. It also provides practical guidance on cost control via max_results and max_companies. However, it does not explicitly state when to use this tool versus alternatives, though no siblings exist.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedmonitor_job_postings

TDQS

A4.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusing it with others. The tool's name and description clearly define its unique purpose.

Naming Consistency5/5

The single tool name 'monitor_job_postings' follows a clear verb_noun pattern. There are no other tools to introduce inconsistent naming conventions.

Tool Count3/5

Having only one tool is minimal, but the tool is comprehensive and well-scoped for the server's stated purpose of monitoring job postings. It is not trivial, so it does not warrant a score of 1, but it sits at the borderline of being too thin.

Completeness5/5

The single tool covers the full workflow: discovery, filtering, enrichment, deduplication, and delta tracking. There are no obvious gaps or dead ends for the domain of job posting monitoring.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers