OpenHire · 开聘

A job-search radar for your AI assistant — first-party listings, ghost jobs scored, and your résumé never touches our servers. 让 AI 助手替你盯岗的求职雷达 —— 一手职位、幽灵岗位打分，简历不经过我们的服务器。

_{Real terminal output — install from PyPI, download the public index, search. No account, no signup.}

An MCP server that turns your AI assistant (Claude, Cursor, Windsurf) into a private radar for AI / Infra, autonomous-driving and embodied-AI jobs — pulled straight from 139 employers' own career sites and public ATS APIs (Greenhouse / Lever / Ashby / 北森 Beisen / Moka), across the US, Europe and China (Waymo, Figure, Zoox — and Unitree, XPeng, UBTECH, Mech-Mind…). No account. No signup. No résumé upload. Ever.

Three things a job board won't do for you:

• Kills ghost-job noise. Every listing carries a ghost_score aged off the employer's real posting date — the "2 days ago" a board shows you can be 300 days old in the ATS.
• Structural privacy, not a pinky-promise. There is no résumé field in the protocol; a CI test fails the build if anyone adds one. Matching runs on your machine — only an anonymous fingerprint reaches the server.
• Ranking you can't buy. Order is a locked pure function of (match, freshness). No sponsored slots, no bidding — the signature is frozen by a test.

This is the 「哨兵 / Sentinel」 reference implementation — see design_handoff_openhire_v01/README.md for the full protocol spec.

Quickstart — under a minute

# 1. Install (pipx keeps it isolated and puts `ohp` on your PATH)
pipx install openhire

# 2. Get a job index. Default: download the public snapshot, then refresh it live.
ohp bootstrap                    # 139 employers · ~16k live postings · no account

# 3. Use it directly…
ohp search --required-skills rust,k8s --remote --role-family engineering
ohp search --currency CNY --role-family engineering   # e.g. CN autonomous-driving / robotics roles

# …or connect it to an MCP client:
ohp serve

Then point your MCP client at it — see Works with below.

Works with

All clients use the same MCP entry. If you ran pipx install openhire, use ohp; otherwise uvx openhire serve fetches and runs it with no prior install (needs uv).

Claude Desktop — %APPDATA%\Claude\claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/); quit & reopen after editing:

{ "mcpServers": { "openhire": { "command": "ohp", "args": ["serve"] } } }

Cursor — ~/.cursor/mcp.json (or a project .cursor/mcp.json):

{ "mcpServers": { "openhire": { "command": "uvx", "args": ["openhire", "serve"] } } }

Windsurf — ~/.codeium/windsurf/mcp_config.json:

{ "mcpServers": { "openhire": { "command": "uvx", "args": ["openhire", "serve"] } } }

Run ohp bootstrap once first so the index has data. On Windows Claude Desktop from the Microsoft Store, the config is under …\Packages\<Claude package>\LocalCache\Roaming\Claude\.

What it does

Optional, entirely local: ohp init --scan <dir> derives a skill fingerprint from your own repos. You never write a résumé; the code never leaves your machine — only an anonymous vector does.

The five protocol fields

Every listing is valid schema.org/JobPosting, plus:

• verified_at — last moment confirmed live on the employer's own site
• source — employer_site | ats_public_api (never a job board)
• ghost_score — 0–1 listing-activity signal, aged off the real posting date (lower = fresher). A noise filter, not an accusation: long-open listings are often evergreen talent pools or slow pipelines — the score simply lets agents down-rank low-activity noise
• response_sla_days — employer's committed response window (v0.1: always null)
• apply_channel — always the employer's own application URL, deep-linked to the specific job

Privacy model

First-run data — the snapshot vs. fresh

ohp bootstrap (default) downloads a small public index snapshot (a GitHub Release asset — companies + jobs only, zero user data) and then runs one incremental crawl to refresh verified_at / delisting. --fresh skips the snapshot and crawls the public ATS from scratch with the free offline heuristic extractor. Either way: no account, no PII.

Three rules this project will never break

1. Your résumé stays on your machine — it never transits the server, and we never store it.
2. Ranking is not for sale — it is only f(match_quality, freshness), a locked pure function.
3. Employers pay only for authorized, delivered outcomes — never for exposure. (v0.1 has no billing at all.)

These are enforced by CI (tests/test_privacy.py, tests/test_ranking.py, tests/test_snapshot.py).

Development

python -m venv .venv && . .venv/Scripts/activate   # Windows
pip install -e ".[dev]"
pytest        # privacy red lines + ranking + snapshot must be green

Set OPENHIRE_DATABASE_URL=postgresql+psycopg://… to run against Postgres instead of the default local SQLite file (~/.openhire/openhire.db).

Roadmap

• v0.2 – v0.3 (shipped) — CN ATS adapters (北森 Beisen + Moka) · weekly auto-refreshed public snapshot · ghost_score public beta · 139 employers across US / EU / China
• next — Employer claim + verified badges — employers can reserve their claim today via a corporate-identity GitHub issue (zero-cost now; badges + listing-status control ship next) · response-SLA enforcement (7-day auto-delist) · redacted proof-of-fit — an anonymous, candidate-authorized match summary that travels with an application (skills overlap only; identity never included, résumés still never transit the server)
• v1.0 — Open, vendor-neutral schema extension for AI-readable job postings

FAQ

Where does the job data come from? Directly from 139 employers' own public ATS APIs (Greenhouse, Lever, Ashby, 北森 Beisen, Moka) — the same endpoints that power their careers pages. No scraping, no third-party job boards. source is always ats_public_api, and verified_at records the last time we confirmed each posting live. The public index is auto-refreshed weekly, so a fresh ohp bootstrap starts from recent data.

Why should I trust ghost_score? It's a pure, open, unpurchasable function — min(1, 0.15·relist_count + staleness) aged off the real ATS posting date, not our crawl date. The formula lives in pipeline/ghost_score.py, is unit-tested, and takes no money as input (red line #2). Long-open, repeatedly-relisted postings score higher; you can always re-rank client-side. Read it as signal-to-noise, not bad faith: plenty of high-scoring listings are legitimate evergreen talent pools. Employers who want their listing activity represented accurately can claim their tenant (see Roadmap).

Does my résumé actually go through the server — really? No. There is no résumé anywhere in the protocol. authorize_application has no résumé/file parameter (it structurally cannot accept one), matching runs on your machine, and the only thing that ever transits the server is a short anonymous fingerprint like #a3f9. This is enforced by tests/test_privacy.py, and the published snapshot carries zero user data (tests/test_snapshot.py).