Account Hiring Watch MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. Required for the server to make calls; the server lists its tool without a token, but a call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| watch_account_hiringA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
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.
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.
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.
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.