Skip to main content
Glama
mambalabsdev

Account Hiring Watch MCP Server

Watch account hiring

watch_account_hiring
Read-only

Track company job boards by domain and return only new, closed, or reposted postings since the last run, with descriptions and hiring summaries.

Instructions

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.

Input Schema

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

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.

Deploy Server

Other Tools