Skip to main content
Glama

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, iCIMS, Oracle Recruiting, Eightfold and SuccessFactors boards, and the Apple, Google, Amazon and Microsoft careers sites, 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

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_tokenNoOnly if this conversation already uses a Watchtower token (wt_...) from before the app was connected. Otherwise leave it out; never ask the user for one.
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. Changed1 schema field changed
    • changedInput schema / properties / client_token / description
      Previous value: -"Your Watchtower client token (wt_...). Optional if the MCP connection sends \"Authorization: Bearer <token>\"."New value: +"Only if this conversation already uses a Watchtower token (wt_...) from before the app was connected. Otherwise leave it out; never ask the user for one."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a write operation (readOnlyHint false), non-destructive (destructiveHint false), and open-world. The description adds substantial operational detail: persistent watch creation, JOB_ADDED/JOB_REMOVED/JOB_UPDATED events, response fields (interpreted, current_jobs, coverage), supported board endpoints, JSON-LD fallback parsing, NO_JOB_DATA rejection, and filter precedence. No contradictions.

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 core purpose and key usage routing are front-loaded in the first two sentences, and most sentences carry distinct information for a complex open-world tool. However, it is a single dense paragraph that could be more scannable for a 17-parameter operation; bullets or shorter sentences would improve readability.

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?

There is no output schema, but the description explains the response shape (interpreted, current_jobs, coverage) and the change events that follow. Combined with the annotations and a fully documented input schema, it gives an agent enough context to invoke the tool correctly across many job-board sources.

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 description coverage is 100%, so the schema already documents all 17 parameters and establishes a baseline of 3. The description adds useful cross-parameter semantics beyond the schema: the query is interpreted in the response and explicit filters override what the query says, plus url omission scopes the watch to every monitored board.

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 and resource: 'Create a persistent watch for tech jobs.' It further clarifies scope (every monitored job board) and distinguishes itself from re-running searches and from later get_changes calls. An agent can identify the tool without opening sibling schemas.

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 instructs to use this INSTEAD OF re-running job searches or re-checking careers pages yourself, which directly routes against search_jobs. It also explains when to pass url/urls versus omitting them, and directs the agent to get_changes for later new postings.

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.