Skip to main content
Glama

Fairquery Agent Trust & Data Safety

by com.getfairquery
OverviewDiscussionsAdmin

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

jobs_check_open
Read-onlyIdempotent

WHAT: Re-check ONE job on the employer's ATS right now and report open or closed. WHEN: Before applying, alerting or contacting about a specific job you got earlier (job_key or ats + slug + jobId), when you only need open or closed. WHEN NOT: One job's full detail (jobs_get_job). Listing a board (jobs_get_board). Checking many jobs at once (jobs_search_companies with confirmOpen, paid). BEHAVIOR: Runs on this Fairquery-hosted Worker (Cloudflare), not on the caller's machine; inputs leave the client. This Worker's code is designed not to store inputs or results. The job id and board slug are sent to the public ATS host in the requests below. Greenhouse, Lever: one GET to the documented per-job endpoint; HTTP 404 = closed. Ashby, Personio, Pinpoint and Gem have no per-job read here, so the documented board feed is fetched once and searched for the id (method "board_listing"). Personio is robots.txt then /xml. Pinpoint is robots.txt then /postings.json. Gem is GET /job_posts/ only. No apply URL is requested. "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: A malformed jobKey, or neither jobKey nor a complete ats + slug + jobId, returns INVALID_INPUT without a request. An Ashby, Personio, Pinpoint or Gem id costs one full board download; 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 and makes the Ashby or Personio board download include descriptions. Pinpoint and Gem description_text stay empty (the row links out). description_text is plain text, <= 20,000 chars, e-mails/phones removed, exactly as in jobs_get_board. 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" | "personio" | "pinpoint" | "gem" (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}, or the Personio account, Pinpoint subdomain or Gem vanity; the middle part of job_key), case-insensitive, 1-100 chars: a letter or digit, then letters, digits, ".", "_" or "-". A Personio account, Pinpoint subdomain or Gem vanity cannot contain a dot. 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 and Personio, a UUID on Lever and Ashby, the posting id on Pinpoint, the job post id on Gem. 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 | personio | pinpoint | gem); any other shape returns INVALID_INPUT. Examples: "greenhouse:stripe:8172503", "personio:acme:4103", "gem:acme:am9icG9zdA"
includeDescriptionNoOptional boolean, default false. true adds job: the full job row (title, location, compensation, posted_at, description_text, ...) when the job is open. On Pinpoint and Gem, description_text stays empty. 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. Changed6 schema fields changed
    • changedInput schema / properties / ats / description
      Previous value: -"Required unless jobKey is given. The applicant-tracking system hosting the board: \"greenhouse\" | \"lever\" | \"ashby\" | \"personio\" (the first part of job_key). Example: \"greenhouse\""New value: +"Required unless jobKey is given. The applicant-tracking system hosting the board: \"greenhouse\" | \"lever\" | \"ashby\" | \"personio\" | \"pinpoint\" | \"gem\" (the first part of job_key). Example: \"greenhouse\""
    • changedInput schema / properties / ats / enum
      Previous value: -[
-  "greenhouse",
-  "lever",
-  "ashby",
-  "personio"
-]New value: +[
+  "greenhouse",
+  "lever",
+  "ashby",
+  "personio",
+  "pinpoint",
+  "gem"
+]
    • changedInput schema / properties / includeDescription / description
      Previous value: -"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"New value: +"Optional boolean, default false. true adds job: the full job row (title, location, compensation, posted_at, description_text, ...) when the job is open. On Pinpoint and Gem, description_text stays empty. Example: true"
    • changedInput schema / properties / jobId / description
      Previous 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 and Personio, a UUID on Lever and Ashby. 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 and Personio, a UUID on Lever and Ashby, the posting id on Pinpoint, the job post id on Gem. Example: \"8172503\""
    • changedInput schema / properties / jobKey / description
      Previous 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 | personio); any other shape returns INVALID_INPUT. Examples: \"greenhouse:stripe:8172503\", \"personio:acme:4103\""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 | personio | pinpoint | gem); any other shape returns INVALID_INPUT. Examples: \"greenhouse:stripe:8172503\", \"personio:acme:4103\", \"gem:acme:am9icG9zdA\""
    • changedInput schema / properties / slug / description
      Previous 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}, or the Personio account; the middle part of job_key), case-insensitive, 1-100 chars: a letter or digit, then letters, digits, \".\", \"_\" or \"-\". A Personio account cannot contain a dot. Example: \"stripe\""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}, or the Personio account, Pinpoint subdomain or Gem vanity; the middle part of job_key), case-insensitive, 1-100 chars: a letter or digit, then letters, digits, \".\", \"_\" or \"-\". A Personio account, Pinpoint subdomain or Gem vanity cannot contain a dot. Example: \"stripe\""
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only, open-world and idempotency, yet the description adds substantially more: the tool runs on a hosted Worker with inputs leaving the client, code is designed not to store inputs/results, which ATS hosts get a per-job GET vs a full board feed, that a 404 means closed, robots.txt ordering, and the absence of billing. The caveat that "open" means published, not actively filled, is a disclosure no structured field carries.

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?

Dense but well sectioned with WHAT/WHEN/WHEN NOT/BEHAVIOR/COST/RETURNS/PARAMETERS/EXAMPLE and the example is front-loaded enough to anchor behavior. Some ATS-by-ATS detail in BEHAVIOR borders on verbose, but each sentence carries operational meaning.

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 five-parameter, zero-required tool with an output schema, the description still covers error taxonomy (INVALID_INPUT, BOARD_NOT_FOUND, HOST_BLOCKED, NETWORK_ERROR and which are retryable), the retry shape of the return value, and the privacy posture. Nothing an agent needs in order to call it correctly is missing.

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; the description earns more by explaining that jobKey wins over ats+slug+jobId, that a malformed key returns INVALID_INPUT with no request, and that an Ashby/Personio/Pinpoint/Gem id forces a full board download while includeDescription is free on Greenhouse and Lever. These are cost consequences of parameter choices that the schema cannot express. It stops short of 5 only because the per-field formats (UUID, numeric id) are already fully documented in 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?

The WHAT line states a specific verb and scope: re-check ONE job on the employer's ATS right now and report open or closed. It explicitly contrasts with the sibling tools that do adjacent things (jobs_get_job, jobs_get_board, jobs_search_companies).

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?

WHEN and WHEN NOT are both spelled out, each with a named alternative, including the paid batch alternative (jobs_search_companies with confirmOpen). An agent can route without opening any other schema.

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

All Fairquery Agent Trust & Data Safety toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources