Skip to main content
Glama
mambalabsdev

Account Hiring Watch MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Account Hiring Watch MCP Server

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

An MCP server for the Mamba Labs Account Hiring Watch actor on Apify. Send a list of company domains. Each run reads every company's own job board and returns only what changed since the last run: new, closed, and reposted postings, with the full job description, a stable posting key, and 30 day hiring velocity per company.

What's Inside

Related MCP server: company-change-event-feed

What it does

Watch a list of company domains and get back only what changed on their job boards since the last run with the same watch name: new, closed, and reposted postings, read live from 17 job boards including Greenhouse, Lever, Ashby, and Workday. Each change row carries the full job description, a stable posting key, and the board it came from; each company also gets a summary row with open postings and 30 day hiring velocity. The first run for a watch sets the baseline, and its rows are marked is_backfill and never charged. Optional signed webhook delivery. A run that does not succeed is returned as an error with its run ID. Read-only on the boards; requires an APIFY_TOKEN and consumes Apify credits per change returned.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-account-hiring-watch": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-account-hiring-watch"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The watch_account_hiring tool appears.

Prerequisites

Example prompts

  • "Watch stripe.com, ramp.com, and vercel.com for new sales and RevOps postings."

  • "Run my target account watch again and tell me which companies opened or closed GTM roles since last week."

Tool

watch_account_hiring. One tool. Example arguments:

{
  "domains": ["stripe.com", "ramp.com", "vercel.com"],
  "watch_name": "target-accounts",
  "keyword_categories": ["GTM"]
}

Inputs

Every buyer facing input of the live actor, unchanged. Omitted inputs take the actor's own defaults.

Input

Type

Required

Description

domains

array

yes

Company website domains to watch, for example stripe.com. The watch reads each company's own job board. Up to 2,000 per run.

watch_name

string

no

Keeps separate watch lists apart. Use one name per list or client. Changing the name starts a new watch, and its first run sets the baseline. Default default.

keyword_categories

array

no

Only changes to postings whose title matches these role categories are returned and charged. All returns every posting change. Every posting still counts toward hiring velocity. Default ["All"].

custom_keywords

array

no

Extra title keywords, matched on whole words. Prefix with T1: for the strongest tier or T3: for the weakest; no prefix is tier 2. Adding any keyword also adds the Custom category.

board_hints

array

no

Point a domain at its job board when the watch cannot find it, as domain=provider:slug, for example acme.com=greenhouse:acmeinc or acme.com=workday:acme.wd5/External. Providers: greenhouse, lever, ashby, workable, smartrecruiters, personio, recruitee, workday, rippling.

first_run_mode

string

no

What a domain's first run returns. recent returns postings the board dates inside the last N days, baseline_only returns the summary row, all_open returns every open posting. First run rows are marked is_backfill and never charged. Default recent.

first_run_recent_days

string

no

With first_run_mode recent: how many days back counts as recent. 1 to 30. Default 7.

closed_after_misses

string

no

A posting closes after this many complete board reads without it. A partial read never counts. 1 to 5. Default 2.

repost_window_days

string

no

A closed posting that comes back inside this many days is reported as reposted, not new. 7 to 60. Default 30.

include_job_description

string

no

Adds the full description text to new and reposted rows. Closed rows carry no description. Default true.

description_max_chars

string

no

Longest description kept per row. job_description_chars always reports the full length. 500 to 100000. Default 20000.

webhook_url

string

no

Optional HTTPS endpoint. Changes are sent as signed Standard Webhooks requests, and a change is charged only after your endpoint answers 2xx.

webhook_secret

string

no

Required with webhook_url. Signs each request (HMAC SHA256). A whsec_ prefixed secret is base64 decoded per the Standard Webhooks spec.

webhook_batch_mode

string

no

batch sends up to 50 changes per request, grouped by company. per_change sends one request per change, for tools where one request is one row (Clay table webhooks, Zapier). Default batch.

state_store

string

no

Optional key value store that holds the watch state. Leave empty to use the store account-hiring-watch-state in your own Apify account.

max_domains

string

no

Domains past this number are skipped. 1 to 2000. Default 500.

max_charge_usd

string

no

Optional. When the next change would take this run's charges over this amount, the remaining changes are held and delivered first on the next run.

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

posting_change, per change returned (new, closed, or reposted)

$0.01

$0.0095

$0.009

$0.0085

apify-actor-start, per run start

$0.002

$0.002

$0.002

$0.002

First run rows (is_backfill) and rows from a board the run could not confirm are never charged. With a webhook set, a change is charged only after your endpoint answers 2xx.

Your keys

The actor needs no provider key. It reads public job board APIs and holds no key of its own. A webhook secret, if you set one, is yours and is stored by Apify as a secret input.

Full actor documentation

apify.com/mambalabs/account-hiring-watch

License

MIT. See LICENSE.

Available Tools

1 tool
watch_account_hiringWatch account hiringA
Read-only

Watch a list of company domains and get back only what changed on their job boards since the last run with the same watch name: new, closed, and reposted postings, read live from 17 job boards including Greenhouse, Lever, Ashby, and Workday. Each change row carries the full job description, a stable posting key, and the board it came from; each company also gets a summary row with open postings and 30 day hiring velocity. The first run for a watch sets the baseline, and its rows are marked is_backfill and never charged. Optional signed webhook delivery. A run that does not succeed is returned as an error with its run ID. Read-only on the boards; requires an APIFY_TOKEN and consumes Apify credits per change returned.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainsYesCompany website domains to watch, for example stripe.com. The watch reads each company's own job board. Up to 2,000 per run.
watch_nameNoKeeps separate watch lists apart. Use one name per list or client. Changing the name starts a new watch, and its first run sets the baseline. Default default.
board_hintsNoPoint a domain at its job board when the watch cannot find it, as domain=provider:slug, for example acme.com=greenhouse:acmeinc or acme.com=workday:acme.wd5/External. Providers: greenhouse, lever, ashby, workable, smartrecruiters, personio, recruitee, workday, rippling.
max_domainsNoDomains past this number are skipped. 1 to 2000. Default 500.
state_storeNoOptional key value store that holds the watch state. Leave empty to use the store account-hiring-watch-state in your own Apify account.
webhook_urlNoOptional HTTPS endpoint. Changes are sent as signed Standard Webhooks requests, and a change is charged only after your endpoint answers 2xx.
first_run_modeNoWhat a domain's first run returns. recent returns postings the board dates inside the last N days, baseline_only returns the summary row, all_open returns every open posting. First run rows are marked is_backfill and never charged. Default recent.
max_charge_usdNoOptional. When the next change would take this run's charges over this amount, the remaining changes are held and delivered first on the next run.
webhook_secretNoRequired with webhook_url. Signs each request (HMAC SHA256). A whsec_ prefixed secret is base64 decoded per the Standard Webhooks spec.
custom_keywordsNoExtra title keywords, matched on whole words. Prefix with T1: for the strongest tier or T3: for the weakest; no prefix is tier 2. Adding any keyword also adds the Custom category.
keyword_categoriesNoOnly changes to postings whose title matches these role categories are returned and charged. All returns every posting change. Every posting still counts toward hiring velocity. Default ["All"].
repost_window_daysNoA closed posting that comes back inside this many days is reported as reposted, not new. 7 to 60. Default 30.
webhook_batch_modeNobatch sends up to 50 changes per request, grouped by company. per_change sends one request per change, for tools where one request is one row (Clay table webhooks, Zapier). Default batch.
closed_after_missesNoA posting closes after this many complete board reads without it. A partial read never counts. 1 to 5. Default 2.
description_max_charsNoLongest description kept per row. job_description_chars always reports the full length. 500 to 100000. Default 20000.
first_run_recent_daysNoWith first_run_mode recent: how many days back counts as recent. 1 to 30. Default 7.
include_job_descriptionNoAdds the full description text to new and reposted rows. Closed rows carry no description. Default true.

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses first-run baseline semantics (is_backfill, never charged), credit consumption per change, the APIFY_TOKEN requirement, error-with-run-ID behavior, webhook signing, and max_charge_usd holding logic. The 'Read-only on the boards' claim is consistent with readOnlyHint=true.

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?

Front-loads the core purpose and delta semantics before behavioral/charg- related detail, and every sentence carries information. It is a dense single paragraph, which reads heavily, but little of it is wasted.

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?

For a complex 17-parameter tool with no output schema and no siblings, the description covers return shape (change rows with full JD, stable posting key, board; per-company summary with open postings and 30-day velocity), state model, billing, and failure handling. Nothing material is missing.

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 baseline is 3, but the description adds meaning beyond the schema: it clarifies that watch_name scopes state across runs, that billing is per change returned (interacting with keyword_categories), and that first-run rows are free. Useful reinforcement, though most individual parameter details still live in 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?

States a specific verb (watch), resource (company domains / job boards) and precise output scope (new, closed, reposted postings). It even names the source breadth (17 boards including Greenhouse, Lever, Ashby, Workday), so an agent knows exactly what it does without opening the schema.

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?

Clearly frames when to use it: monitor domains and receive only deltas since the last run with the same watch_name, with first-run baseline behavior spelled out. There are no siblings to differentiate against and no explicit exclusions, so it lands just shy of a 5.

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 observedwatch_account_hiring
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection between tools. Its purpose (delta-detection on company job boards) is unambiguous within the set.

Naming Consistency5/5

The single name watch_account_hiring is clear snake_case with an action_target form. With only one tool there is no inconsistency to detect.

Tool Count2/5

A one-tool surface is very thin for a monitoring domain: the tool bundles watching, diffing, and webhook delivery into one opaque call with no way to manage or inspect watches separately. The rubric places a single tool at 2 even when that tool is well-scoped.

Completeness3/5

The tool covers the watch/diff lifecycle well (baseline, new, closed, reposted, error runs), but there is no way to list or delete existing watches, reconfigure a watch, or fetch a current snapshot of open postings on demand. These are notable gaps an agent would eventually hit, though it can work around some by re-running with a new watch name.

Maintenance

ActivityNo data
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers