OpenHire — Real Job Postings, Ghost Jobs Scored

Overview Schema Source Related Servers Discussions Admin

Read an employer's board

read_board

Read-onlyIdempotent

Read an employer's public job board live from a supported ATS URL outside the index, returning postings, locations, posting dates, apply links, and full descriptions by job ID.

Instructions

Read one employer's public job board live, whether or not the employer is in this index.

Use it when the user names an employer this index does not carry (search_jobs returned the empty-result object, or the employer is outside AI infra, autonomous driving and embodied AI) and has, or can find on the employer's careers page, a board URL on a vendor this index knows how to read: Greenhouse (job-boards.greenhouse.io/), Lever (jobs.lever.co/), Ashby (jobs.ashbyhq.com/), Moka (app.mokahr.com/apply//), 北森 (.zhiye.com), Workable (apply.workable.com/), SmartRecruiters (jobs.smartrecruiters.com/) Workday (.wd5.myworkdayjobs.com/), Rippling (ats.rippling.com//jobs) or Personio (.jobs.personio.de). Any sector. To keep the employer, add_employer puts the same board into the user's own index.

What you get: the board's own postings with title, location, the board's own posting date and days_open where it reports one (date_signal: not_reported_by_ats otherwise), a direct apply link on the employer's own tenant, and a description excerpt that starts where the role does (company boilerplate skipped). Pass ats_job_id from a previous read to get that one posting with its whole description, when the user wants the job description itself read or summarised. What you do not get: skills, ghost_score, relist history or watches, which need repeated observation; and nothing is stored. If the employer turns out to be in the index the result says so and search_jobs is the richer source.

Refused with ERR_UNSUPPORTED_BOARD, with the reason: a Feishu Hire / Lark portal (request signatures, an access control this index never bypasses), SuccessFactors, Taleo, iCIMS, LinkedIn, JobsDB or BOSS直聘. Tell the user to open that page themselves; never look for another way in.

Politeness: one live read per board per 15 minutes per server process (a repeat within that window is answered from memory, from_cache: true), with the same request headers as the weekly crawl. A board that does not answer is reported as such, never as a fact about the employer.

Privacy: sends only the board's tenant to the vendor's public endpoint. Nothing about the user is sent anywhere, and nothing read is stored.

Args: url: the careers or board URL as the user pasted it. location: only postings whose location text contains this, in either language (香港 = Hong Kong = HK, 广州 reaches 天河区). title: words in the job title, any match ("hr" reaches HR, HRBP, recruiter, talent acquisition; "recruit" or "招聘" reach recruiting titles only); the filter for roles no skill tag names. limit / offset: page through total_matching (newest posting date first, undated last). ats_job_id: one posting's id from an earlier read; returns it alone with the full text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "read_board"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No
`title`	No
`offset`	No
`location`	No
`ats_job_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.41Oct 30, 2026

addedInput schema / properties / ats_job_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ats Job Id"
+}

Addedv0.8.10Oct 14, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, but the description adds substantial context: a 15-minute-per-board politeness window with from_cache behavior, the ERR_UNSUPPORTED_BOARD refusal reasons and the anti-circumvention rule, that failures are 'never a fact about the employer,' and a privacy statement about what is sent and stored. These are genuine add-ons, though the rate-limit/caching detail is embedded in prose rather than front-loaded.

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?

Front-loaded and organized with labeled blocks (What you get, What you do not get, Politeness, Privacy, Args), so the agent can scan. It is long and repeats the 'is the employer in this index' condition in two places, and the ten-vendor URL inventory is dense, but nearly every sentence carries actionable information.

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 six-parameter, no-output-schema, open-world read tool, the description covers return fields, the days_open/date_signal nuance, pagination ordering, what is deliberately absent (ghost_score, watches, relist history), refusal modes, and privacy. Nothing an agent needs to call or interpret it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does it well: url is the pasted careers URL, location is a substring match with bilingual equivalences (香港 = Hong Kong = HK), title is any-word matching with concrete examples ('hr' reaches HRBP, recruiter...), limit/offset page through total_matching in newest-first/undated-last order, and ats_job_id returns one posting with full text.

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 specific verb and resource ('Read one employer's public job board live') and immediately states the scope that distinguishes it: works 'whether or not the employer is in this index.' The agent can tell it apart from search_jobs and add_employer 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?

States the exact triggering conditions (search_jobs returned the empty-result object, or the employer is outside the indexed sectors), the prerequisites (a board URL on a recognized vendor, with the vendor URL patterns enumerated), and the alternative (search_jobs is the richer source when the employer is in the index). It also names what it will refuse and what to tell the user instead.

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

Deploy Server