Skip to main content
Glama
gzchenhao

OpenHire — Real Job Postings, Ghost Jobs Scored

Read an employer's board

read_board
Read-onlyIdempotent

Read one employer's live job board when search_jobs finds nothing, returning postings, apply links, and dates. Use for employers outside this index on supported ATS vendors.

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/) or Workday (.wd5.myworkdayjobs.com/). 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. 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); the filter for roles no skill tag names. limit / offset: page through total_matching (newest posting date first, undated last).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
limitNo
titleNo
offsetNo
locationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.10

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, but the description goes well beyond them: a 15-minute per-board read limit with from_cache:true on repeats, explicit privacy behavior (only the tenant is sent, nothing stored), and the full ERR_UNSUPPORTED_BOARD refusal list with reasons. 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?

Long for a tool description, but well front-loaded and organized under clear sub-headers (What you get, What you do not get, Refused, Politeness, Privacy, Args). Almost every sentence carries information an agent needs, though the vendor/refusal enumerations make it heavier than strictly necessary.

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 complex live-web tool with no output schema, the description covers what is returned (title, location, posting date, days_open or date_signal, apply link, excerpt), what is absent (skills, ghost_score, relist history, watches), non-persistence, and failure modes. Nothing required for correct invocation 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 so well: url is 'as the user pasted it', location is a contains-match with bilingual equivalence (香港 = Hong Kong = HK, 广州 reaches 天河区), title matches any word in the title ('hr' reaches HRBP, recruiter), and limit/offset page through total_matching ordered newest-first with undated last.

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 (read) and resource (one employer's public job board, live) and immediately distinguishes itself from the index-based sibling by noting it works whether or not the employer is in the index. An agent can separate it from search_jobs 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 names the trigger condition (search_jobs returned the empty-result object, or the employer is outside AI infra / autonomous driving / embodied AI) and the required precondition (a board URL on a supported vendor). It also routes the follow-up action (add_employer) and states when search_jobs is the richer source instead.

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