Skip to main content
Glama

Watchtower

Watch for new job postings

watch_jobs

Create a persistent watch for tech jobs. Describe what you want in query ("iOS jobs in Austin making at least 150k a year with a maximum of 6 years of experience") and leave url out: the watch then covers every job board Watchtower monitors (tech companies and startups, whatever platform they use) and reports each new matching posting (JOB_ADDED). The response shows how the query was read (interpreted), the jobs open right now that match (current_jobs) and how many boards are covered (coverage); later call get_changes for new ones. Use this INSTEAD OF re-running job searches or re-checking careers pages yourself. To follow one company, or to cover a company the directory is missing, pass url (or urls for several): Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee, Workday and iCIMS boards are read through their own endpoints; other careers pages are parsed via schema.org JobPosting JSON-LD. A careers page that only links to a supported board is watched through that board (resolved_from says so); a page with neither is rejected with NO_JOB_DATA. A board you watch stays covered for every search watch. A board watch emits JOB_ADDED / JOB_REMOVED / JOB_UPDATED. Jobs carry title, location, other_locations, department, company, url, posted_at, remote, seniority, and salary / experience_years when the posting states them. Explicit filters override what the query says.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOptional. Limit the watch to one job board or careers page, e.g. https://boards.greenhouse.io/acme, https://jobs.lever.co/acme, https://acme.wd5.myworkdayjobs.com/Careers. Omit to watch every monitored board.
urlsNoOptional. Several boards to watch with the same filters (max 25). Returns watches and per-URL errors.
labelNoA short note to yourself about why you are watching this.
queryNoWhat to watch for, in plain language: role, place, pay, experience, level, remote. E.g. "iOS jobs in Austin making at least 150k a year with a maximum of 6 years of experience", "senior backend roles in New York or remote paying $180k+". Check interpreted in the response.
keywordsNoOnly report jobs whose title/location/department/company contains one of these as a whole word, e.g. ["iOS", "Swift"].
locationsNoOnly report jobs with one of these in their location, e.g. ["Austin"], ["Berlin", "Remote"].
seniorityNoOnly report these levels, derived from the title. "mid" means the title carries no level.
min_salaryNoYearly pay the job must be able to reach, e.g. 150000. Compared with the top of the posted range (hourly and monthly pay are converted).
remote_onlyNoOnly report jobs whose title or location says remote (and not hybrid/on-site).
webhook_urlNoOptional public https URL that receives a signed POST whenever matching changes are detected. Polling get_changes keeps working either way.
all_keywordsNoOnly report jobs containing every one of these, e.g. ["data", "scientist"].
client_tokenNoYour Watchtower client token (wt_...). Optional if the MCP connection sends "Authorization: Bearer <token>".
include_unknownNoMany postings state no pay or no years of experience. true (default) still reports them, without a salary / experience_years field; false reports only postings that state a qualifying value.
salary_currencyNoISO currency of min_salary, e.g. "USD". Jobs that state pay in another currency are then left out.
exclude_keywordsNoNever report jobs mentioning one of these, e.g. ["manager", "clearance"].
interval_minutesNoHow often to check, in minutes (min 5, default 60). Resources shared with other watchers use the shortest interval.
max_experience_yearsNoThe most years of experience a job may ask for, e.g. 6.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and openWorldHint=true but say nothing about lifecycle or failure modes, so the description correctly carries that burden: persistent watch, JOB_ADDED/JOB_REMOVED/JOB_UPDATED event model, NO_JOB_DATA rejection, resolved_from resolution, webhook signing, and that polling still works. This is genuinely rich disclosure well beyond the annotations.

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 paragraph is long but densely packed and front-loaded: purpose, then query-vs-url guidance, then response shape, then routing advice. Nearly every sentence carries unique information, though it could be broken into shorter units for scanability.

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 17-parameter tool with no output schema, the description compensates by describing the response fields (interpreted, current_jobs, coverage) and the job record shape (title, location, salary, experience_years, etc.). Combined with 100% schema coverage, an agent has enough to call it correctly and interpret the result.

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 the baseline is 3, but the description adds real semantics the schema lacks: that omitting url covers every monitored board, the url/urls distinction, supported board platforms, and that explicit filters override the query. That is meaningfully more than restating 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?

Opens with a precise verb+resource ("Create a persistent watch for tech jobs") and immediately contrasts itself with the sibling set by pointing to get_changes for subsequent changes. An agent can distinguish this from list_watches/get_changes/delete_watch without opening a schema.

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

Usage Guidelines5/5

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

Explicitly states the alternative to avoid ("Use this INSTEAD OF re-running job searches or re-checking careers pages yourself") and routes follow-up polling to get_changes. It also covers the url-vs-no-url decision and the multi-board case, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.