Skip to main content
Glama
company-jobs-feed

company-jobs-feed

Official

Re-check whether one job is still published (free)

jobs_check_open
Read-onlyIdempotent

Verify whether a specific job is still open or closed on Greenhouse, Lever, or Ashby before applying; optionally fetch the full job description and details.

Instructions

WHAT: Re-check ONE job on the employer's ATS right now and report open or closed; optionally return that job's full row with its description. WHEN: Before applying, alerting or contacting about a specific job you got earlier (job_key or ats + slug + jobId), or to read one job's full details (includeDescription=true). WHEN NOT: Listing jobs (jobs_get_board) or checking many jobs at once (jobs_search_companies with confirmOpen, paid). BEHAVIOR: Greenhouse, Lever: one GET to the documented per-job endpoint; HTTP 404 = closed. Ashby has no per-job endpoint, so the whole board is fetched once and searched for the id (method "board_listing"). "open" means currently published by the employer; it does not prove the role is still being filled. COST: No APIFY_TOKEN, no billing. RETURNS: One "open_check" row (job = the full "job" row when includeDescription=true and the job is open, else null), or a tool error: INVALID_INPUT, BOARD_NOT_FOUND, HOST_BLOCKED or NETWORK_ERROR (the last two retryable). PARAMETERS: Give either jobKey alone, or ats + slug + jobId; jobKey wins when both are given. A malformed jobKey, or neither form complete, returns INVALID_INPUT without a request. An Ashby id costs one full board download (the same request as jobs_get_board); on Greenhouse and Lever a 404 triggers one extra board request so a closed job (status closed) is told apart from a missing board (BOARD_NOT_FOUND). includeDescription adds no request on Greenhouse and Lever (the per-job response already holds the text) and makes the Ashby board download include descriptions; description_text is plain text, <= 20,000 chars, e-mails/phones removed, exactly as in jobs_get_board. A closed job has no data left to return (job = null). EXAMPLE: {"jobKey":"greenhouse:stripe:8172503"} -> {"status":"open","method":"detail_endpoint"}.

Input Schema

NameRequiredDescriptionDefault
atsNoRequired unless jobKey is given. The applicant-tracking system hosting the board: "greenhouse" | "lever" | "ashby" (the first part of job_key). Example: "greenhouse"
slugNoRequired unless jobKey is given. Board slug from the public board URL (boards.greenhouse.io/{slug}, jobs.lever.co/{slug}, jobs.ashbyhq.com/{slug}; the middle part of job_key), case-insensitive, 1-100 chars: a letter or digit, then letters, digits, ".", "_" or "-". Example: "stripe"
jobIdNoRequired unless jobKey is given. The ATS job id (job_id field, the last part of job_key), 1-100 chars: numeric on Greenhouse, a UUID on Lever and Ashby. Example: "8172503"
jobKeyNoOptional if ats + slug + jobId are given; wins when both are given. The job_key field of a job row, format "{ats}:{slug}:{job_id}" with ats in lowercase (greenhouse | lever | ashby); any other shape returns INVALID_INPUT. Examples: "greenhouse:stripe:8172503", "lever:palantir:10dfc8bc-99ad-4ca2-ab76-853cb90a92c2"
includeDescriptionNoOptional boolean, default false. true adds job: the full job row (title, location, compensation, posted_at, description_text, ...) when the job is open. Example: true

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context: board totals, request counts, cost notes
countYesNumber of items in this page
itemsYesResult rows. Each has "type": "job" (job_key, title, company, locations, countries, remote, posted_at, verified_open_at, age_days, long_open, apply_url, source_url, ...), "board", "company", "seed_board", "open_check" or "error" (code, message, retryable)
totalYesTotal items after filters, before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null when done

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / properties / includeDescription
      Added value: +{
      +  "description": "Optional boolean, default false. true adds job: the full job row (title, location, compensation, posted_at, description_text, ...) when the job is open. Example: true",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changedv1.0.5
    • changedInput schema / properties / ats / description
      Previous value: -"Required. The applicant-tracking system hosting the board: \"greenhouse\" | \"lever\" | \"ashby\". Example: \"ashby\""New value: +"Required unless jobKey is given. The applicant-tracking system hosting the board: \"greenhouse\" | \"lever\" | \"ashby\" (the first part of job_key). Example: \"greenhouse\""
    • changedInput schema / properties / jobId / description
      Previous value: -"Optional if jobKey is given. The ATS job id (job_id field). Example: \"8172503\""New value: +"Required unless jobKey is given. The ATS job id (job_id field, the last part of job_key), 1-100 chars: numeric on Greenhouse, a UUID on Lever and Ashby. Example: \"8172503\""
    • changedInput schema / properties / jobKey / description
      Previous value: -"Optional if ats/slug/jobId are given. The job_key from a job row: \"<ats>:<slug>:<job_id>\". Example: \"lever:palantir:10dfc8bc-99ad-4ca2-ab76-853cb90a92c2\""New value: +"Optional if ats + slug + jobId are given; wins when both are given. The job_key field of a job row, format \"{ats}:{slug}:{job_id}\" with ats in lowercase (greenhouse | lever | ashby); any other shape returns INVALID_INPUT. Examples: \"greenhouse:stripe:8172503\", \"lever:palantir:10dfc8bc-99ad-4ca2-ab76-853cb90a92c2\""
    • changedInput schema / properties / slug / description
      Previous value: -"Required. Board slug as it appears in the public board URL (case-insensitive): boards.greenhouse.io/<slug>, jobs.lever.co/<slug>, jobs.ashbyhq.com/<slug>. Example: \"ramp\" or \"palantir\""New value: +"Required unless jobKey is given. Board slug from the public board URL (boards.greenhouse.io/{slug}, jobs.lever.co/{slug}, jobs.ashbyhq.com/{slug}; the middle part of job_key), case-insensitive, 1-100 chars: a letter or digit, then letters, digits, \".\", \"_\" or \"-\". Example: \"stripe\""
  3. First observedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description goes well beyond them: per-ATS request behavior (single GET on Greenhouse/Lever, full board download on Ashby via method "board_listing"), HTTP 404 meaning, the extra board request that disambiguates 'closed' from BOARD_NOT_FOUND, the enumerated error codes with which are retryable, and the cost statement (no APIFY_TOKEN, no billing). This is unusually rich behavioral disclosure.

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 WHAT/WHEN/WHEN NOT/BEHAVIOR/COST/RETURNS/PARAMETERS/EXAMPLE scaffolding is highly scannable and the most decision-relevant content (WHAT, WHEN NOT) is front-loaded. It is however lengthy for a 5-parameter read tool, and the RETURNS and PARAMETERS blocks partially duplicate the output schema and input schema.

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?

An output schema exists, yet the definition still covers the tricky cases an agent needs: closed jobs return job=null, Ashby has no per-job endpoint so behavior differs, errors are enumerated with retryability, and a concrete example call is given. Nothing material is missing for correct invocation.

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% and the schema already documents formats, the jobKey-wins precedence rule, and the INVALID_INPUT shape, so much of the PARAMETERS block is restatement. The description still adds genuine semantics the schema lacks: the malformed-key check happens with no request issued, includeDescription costs no extra request on Greenhouse/Lever but expands the Ashby download, and description_text limits (plain text, <=20,000 chars, contact info stripped).

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 scope: 'Re-check ONE job on the employer's ATS right now and report open or closed', with an optional mode to fetch the full row. It explicitly distinguishes itself from the two closest siblings by name (jobs_get_board for listing, jobs_search_companies for bulk checks), so an agent can route correctly without opening any 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?

The WHEN line gives the triggering situations (before applying/alerting about a specific previously-fetched job, or reading one job's full details) and WHEN NOT names both alternatives with the condition that selects them, including that the bulk path is paid. Nothing about tool selection is left to inference.

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