OpenHire — Real Job Postings, Ghost Jobs Scored

Overview Schema Source Related Servers Discussions Admin

Add an employer to my index

add_employer

Idempotent

Index an employer's public job board on this machine and crawl it now so you can search, score ghost jobs, and watch postings outside the public list.

Instructions

Put one employer's public job board into the index on THIS machine, and crawl it now.

The public index is a curated list (AI infra, autonomous driving, embodied AI). The employers a user actually targets are wider than that, so any board a vendor adapter can read goes into the user's own index on request: Greenhouse, Lever, Ashby, Moka, 北森, Workable, SmartRecruiters, Workday, Rippling or Personio (.wd5.myworkdayjobs.com/), any sector. After this call the employer behaves like a seeded one: search_jobs(company=...) with the board's own posting dates, days_open and ghost_score; watch_intent on it; refresh_index re-crawls it; the weekly refresh keeps it. It is flagged user_added, is never part of the public snapshot, and remove_employer takes it out.

Use it when the user names an employer this index does not carry and has its careers URL (read_board shows the board first without storing anything; add_employer is the step after, when the user wants it watched). A closed portal (Feishu Hire, SuccessFactors, Taleo, iCIMS, LinkedIn, BOSS直聘) is refused with the reason, as read_board refuses it.

Privacy: the vendor sees the same tenant read the weekly crawl makes; nothing about the user is sent anywhere, and which employers a user added stays on this machine.

Args: url: the careers or board URL as the user pasted it. name: the employer's display name (defaults to the board's tenant name).

Returns: added, company_id, jobs_indexed, count_on_board, and suggest_for_public_index, a prefilled GitHub issue link the user may open to propose the employer for everyone.

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": "add_employer"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes
`name`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.13Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover readOnly/openWorld/idempotent/destructive; the description adds substantially more: post-call behavior (search_jobs with posting dates, days_open, ghost_score; watch_intent; refresh_index; weekly refresh retention), the user_added flag, exclusion from the public snapshot, removal via remove_employer, and a privacy statement about what the vendor sees. This is exactly the behavioral context annotations cannot provide.

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 with the core action and reasonably structured, but the vendor enumeration and the parenthetical Workday URL format add length that could be trimmed; nearly every sentence still carries information an agent needs, so the verbosity is closer to dense than padded.

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?

With no output schema, the description supplies the return fields (added, company_id, jobs_indexed, count_on_board, suggest_for_public_index), the side effects, and the failure mode for unsupported portals. An agent has everything needed to call it correctly and set expectations.

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 0%, so the description must carry parameter meaning; the Args block does document both: url as the careers/board URL 'as the user pasted it' and name as the display name defaulting to the board's tenant name. The url semantics are slightly thin (accepted formats are only implied by the vendor list), keeping it below a 5.

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+resource+scope: 'Put one employer's public job board into the index on THIS machine, and crawl it now.' The 'THIS machine' phrasing distinguishes it from the curated public index, and the later sentence explicitly contrasts it with read_board (preview, stores nothing).

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?

Gives a concrete trigger condition ('when the user names an employer this index does not carry and has its careers URL'), names the alternative (read_board shows the board first without storing anything; add_employer is the step after), and states the exclusion (closed portals refused with reason). Nothing 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.

Deploy Server