What a job postings MCP server can do: worked examples

Claude Desktop

Claude Desktop's config launches local servers, so bridge the remote endpoint with mcp-remote. Add this to claude_desktop_config.json (Settings → Developer → Edit Config) and restart the app:

Cursor

Cursor reads remote servers with custom headers directly. Put this in .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):

A custom agent over the Anthropic SDK

For your own agent, connect with the official MCP SDK (the connection is client-side, so the X-API-Key header works as-is) and hand the discovered tools to the Anthropic SDK's tool runner. Python shown; the TypeScript SDK has the same helpers:

Example 1 — the core loop: from a domain to a webhook that fires on new postings

The sequence almost every workflow builds on. The agent resolves a company, gates it on whether it is hiring, reads its pulse, then saves a watch so new postings push to your endpoint — no polling afterwards.

The prompt:

"Is Braze hiring? If they are and hiring is picking up, watch them and push new postings to https://hooks.example.com/reqbeat."

Step 1 — resolve the company. find_company turns a domain or name into the company_id every other tool takes. Never billed.

Step 2 — gate cheaply. is_hiring is the yes/no check before spending a richer call. A company with coverage_status: "no_ats_signal" is unknown, not quiet — don't score it as a negative.

Step 3 — read the pulse. hiring_pulse answers "is hiring picking up": reqs opened in the last 30 days, velocity against the 30 before, direction, surge flag. A company still being crawled returns {"job_id": …, "status": "crawling"} — poll again later rather than reading it as "not hiring".

Step 4 — register the delivery target. register_webhook is idempotent: the same URL twice returns the same id, so retries never leave two endpoints. The signing secret is returned once, on this call only.

Step 5 — save the watch. watch_company subscribes the company's hiring events to that endpoint. opened is the event to treat as a fresh trigger; reposted is a req that came back, not a new opening.

What lands on your endpoint when Braze posts a new req — the same signed envelope documented on the webhook reference, abridged here. Verify X-Reqbeat-Signature before acting on it:

Prefer pull over push? get_changes is the same ledger as a replayable feed: events with event_seq greater than your cursor, ascending, plus a next_cursor to resume from.

Example 2 — GTM engineer: qualify an account list

The prompt:

"Here are 40 target domains. Which should we work this week, and why?"

The agent runs the gate-then-rank loop per domain — the two cheap calls first, the richer one only for accounts that clear the gate:

pre_action_brief exists so the "write me an opener for this account" step doesn't take five calls. Need the full req list instead of the brief's top slice? get_open_reqs returns every active req, deduped across boards, filterable by function and country. The complete recipe — system prompt included — is at the hiring-pulse agent recipe.

Example 3 — automation builder: wire hiring signals into outreach

The prompt:

"Find live senior data-engineer roles at product companies in Germany and the US. For each, draft an intro that references the actual posting."

find_qualified_reqs collapses the whole ICP into one call — countries, title keywords and seniority together, agencies and expired postings excluded by default:

Each row names the company and carries the posting URL — enough to personalize without another lookup. For free-text search across titles there's search_jobs, and get_role pulls one role's detail by the company_id + req_key pair a search row already carries. When an account converts, the agent reports it back — so your outcome data accrues against the signals that produced it, visible only to your account:

Example 4 — agency: monitor clients' competitors

The prompt:

"Watch these five competitors of our client. Tell me when any of them starts or stops hiring for growth roles."

Same core loop, multiplied — resolve each name, save a watch for opened and closed events. By name, find_company returns up to five candidates with a match_confidence, so the agent can pick the exact-name match. The part that matters for a retainer: list_watches reports each watch's heartbeat, so a watch that is silent because nobody is hiring reads differently from one whose endpoint is failing:

When the engagement ends, cancel_watch frees the slot — it's idempotent, so cancelling twice succeeds twice. A free key holds a limited number of watches at once; cancelling returns the slot.

Cost and correctness notes

• find_company, is_hiring, list_watches, cancel_watch and write_outcome are never billed. register_webhook is free; the watch that follows is what meters.
• who_is_hiring_for and find_qualified_reqs bill per company or row returned ($0.10 each) — an empty result bills nothing.
• Errors are explicit, never quietly partial: an unresolvable geo, an unknown function name, or an invalid event_type each return an error that names the rule. Let the agent read them — the messages are written for it.
• Pages are bounded. An oversized limit is rejected rather than truncated — page through with the cursor instead.
• The corpus is LinkedIn-excluded (ATS tenants plus public job boards and aggregators) and freshness-floored; the method page states the sample and the known biases.