Your AI agent can use this job board directly

Which agent do you use?

Pick one. You will see only the steps for that app.

Using a different app? Setup for other apps is in the install repository on GitHub →

Test the server

On the live page, a button asks the server what it is, lists its tools and prompts, and runs one search for "nurse" with no key — one of your 100 free calls for today — and prints the answer in words, including whether sign-in for the chat apps is switched on. The first of those four calls, as a curl line:

curl -s -X POST https://bwhdazbotpblihdxcmho.supabase.co/functions/v1/agent-mcp -H 'content-type: application/json' -H 'mcp-protocol-version: 2025-06-18' -d '{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": { "name": "your-client", "version": "1.0" } } }'

If it does not work

Each row quotes what the server or your app actually says.

The server address

https://bwhdazbotpblihdxcmho.supabase.co/functions/v1/agent-mcp

This address is on Supabase, the company that hosts our server; it is ours. Paste it exactly as it is. Streamable HTTP transport, stateless, POST only. Tool discovery (initialize, tools/list) works with no key, so an agent can see what is here before anyone mints anything. search_jobs, get_job, get_jobs, check_jobs_open, apply_myself, board_stats, employer_hiring_record, employer_growth, search, fetch answer with no key at all — 100 calls a day per network address (from ChatGPT, per person; from Claude, a shared pool of 10000 first), search capped at 10 rows, each answer saying how many are left. Every other tool call needs a credential — the key as Authorization: Bearer rb_live_…, or the sign-in a chat host performs for you while the server's sign-in service is on; the live page's Test the server button prints today's state, and the initialize result carries it under _meta["work.resumebooster/sign-in"].state.

Two hiring systems on the job board are not handed on by this server or the data API: the U.S. federal job feed, whose terms forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. Their postings stay on the job board, where you can open them yourself.

Two kinds of key

Read tools — search_jobs, get_job, get_jobs, check_jobs_open, apply_myself, board_stats, employer_hiring_record, employer_growth, key_status, debug_search, search, fetch — work with any free API key from Hiring Data & API: no account, no card. fit_resume gives 25 scorings a day on a confirmed free key, 1,000 on an account with a paid plan, counted together with POST /v1/fit on the data API.

Read-only keys stay read-only by design. A free key meters at 60 requests a minute and 1,000 calls a day per key.

Which hosts can reach which tools

Every keyed tool call carries a credential, and hosts hold it two ways. From Claude Code: the key in an Authorization header — every tool your key's tier allows. From Claude and ChatGPT: a sign-in instead of a key, while the server's sign-in service is on — the call then runs on your own account key (the same row and quota a pasted key would use); before sign-in, or while it is off, the unkeyed tools — search_jobs, get_job, get_jobs, check_jobs_open, apply_myself, board_stats, employer_hiring_record, employer_growth, search, fetch — still answer, 100 calls a day per network address (from ChatGPT, per person; from Claude, a shared pool of 10000 first), search capped at 10 rows. Each host's own note below says which.

• Claude — sign in when needed: paste the address as a custom connector and choose Sign in when needed — while the server's sign-in is on, the first tool that needs your account shows a Connect card that signs you in through OAuth; the dialog has no field for a key (a static header is an org-admin beta), and with No sign-in only the unkeyed tools answer.
• ChatGPT — sign in when needed: add the address as a custom MCP server under chatgpt.com/plugins with No authentication; there is no field for an API key — while the server's sign-in is on, a tool that needs your account shows ChatGPT's own OAuth sign-in and you press Allow on the consent page.
• Claude Code — reaches every tool: the --header flag on claude mcp add, with the key in a shell variable.

Any other app reaches every tool your key allows when it can send an Authorization header; how to set each one up is in the install repository.

The search and read tools

• search_jobs (any free key; answers with no key, 100/day per network address) — Search the live board. Returns compact job cards with the board's own parsed pay and experience fields, plus its honesty disclosures: exact totals when knowable, filters it couldn't honour, words it read as filters, spelling suggestions.
• get_job (any free key; answers with no key, 100/day per network address) — Full detail for one job id, including the complete description text and when the employer's feed last confirmed it open. A dead id answers with what the board knows — a watched closure or an aged-out stub — never a stale card.
• get_jobs (any free key; answers with no key, 100/day per network address) — Up to 10 job ids in one call — the shortlist form of get_job. Ids that closed, aged out or were never here come back in `unavailable` with the reason named, so one dead id never costs the other nine.
• check_jobs_open (any free key; answers with no key, 100/day per network address) — Are these postings still on the board? Up to 200 ids per call with a key (50 with none), answered from the board's index rather than the employer's site at that instant — it names that basis so a shortlist is re-verified honestly.
• apply_myself (any free key; answers with no key, 100/day per network address) — Help a person apply to one posting themselves, on the employer's own site. When the employer uses Greenhouse, Ashby, Recruitee, Breezy or Pinpoint, it returns the employer's real application form: every question with its options, and who should answer it — the person for the questions that look like they are about them (facts, demographics, consents), their AI for open questions about work done or motivation. The marks are read from the question's words, so a question about the person, even a plainly worded one, can be marked for their AI and some work questions are marked for the person: the person reads every answer before they send. Otherwise it returns the posting's apply link and the terms the posting uses. Inside ChatGPT it reads the form only for Greenhouse or Recruitee.
• board_stats (any free key; answers with no key, 100/day per network address) — Live board statistics from cache: servable and tracked posting totals, the count of company job boards with open roles (boards, not employers — one employer can run several), the category set, and the freshness stamp.
• employer_hiring_record (any free key; answers with no key, 100/day per network address) — An employer's record on its own board, from the closure ledger no other board keeps: roles open now, roles watched coming down in the last 90 days with re-lists counted separately, medians from the employer's own stated dates, and how long that board has been watched — per board, never summed across an employer's boards, and a takedown is never called a hire; a board with no closure observed answers unknown with the reason, never a verdict.
• employer_growth (any free key; answers with no key, 100/day per network address) — Whether an employer's board served more roles than a week earlier, judged by the board itself from our own daily observation and passed through untouched: grew, no-growth, or unknown with the gate that refused named — an unknown is never a no, one board is never summed with another, and nothing here ranks employers.
• key_status (any free key) — What this key is and may do: tier, requests left this minute, calls left today and which tools answer on it — with any blocker named, so nothing has to be discovered by refusal.
• debug_search (any free key) — Explain why a search returns what it does: the parsed query, which filters were applied or ignored and why, the route and ranking regime chosen, timings and count basis. Takes the same arguments as search_jobs.
• search (any free key; answers with no key, 100/day per network address) — An alias of search_jobs in the fixed shape ChatGPT's deep-research and company-knowledge connectors call: one query in, a list of {id, title, url} out, the same page size as an unkeyed search. Every other client should call search_jobs, which takes every filter.
• fetch (any free key; answers with no key, 100/day per network address) — An alias of get_job in the same ChatGPT research shape: one id in, {id, title, text, url, metadata} out — the full description as text and the card's structured fields as metadata. A dead id answers with what the board knows, never a stale card.
• fit_resume (free key, 25 scorings a day) — Score a résumé against the board — the site's résumé drop for an agent holding a CV. Reads the occupation out of the text, searches for it, and scores up to 20 results with matched and missing terms. Needs a key: 25 scorings a day on a confirmed free key, 1,000 on an account with a paid plan — the same allowance as POST /v1/fit. Never offered inside ChatGPT, and the CV is never stored.

Prompts and resources your host can list

Beside the tools, the server registers ready-made prompts and a few readable documents. Hosts that list them show them under the server's name; listing costs no call and needs no key.

Prompts

• browse_jobs — Browse jobs: Searches the live board for a role and a place with no key, reads postings, re-checks that a shortlist is still open, and hands any posting to apply_myself.
• find_roles_for_my_cv — Find roles that fit my CV: Your AI reads the job titles out of the CV you give it in the chat and searches the live board for them with no key. The CV itself is never sent to the server, and the prompt never invents one.
• apply_myself — Help me apply myself: It can take a question about you, even a plainly worded one, for a work question, so read every answer before you send.
• apply_to_my_shortlist — Apply to my shortlist, one at a time: Re-checks which saved jobs are still open, then helps you apply to each open one yourself through apply_myself, one at a time.
• what_can_my_key_do — What can this key do right now: One status call, explained in plain words: tier, calls left and fit scorings left today, and what would change a closed answer — the gate, never a price. Listed only to a connection holding a key.

Resources

• resumebooster://guide (reads with no key) — The tiers, which tools answer unkeyed, how to verify a shortlist cheaply, and what the closure ledger can and cannot say — built from the tool registry at request time, so it cannot describe a tool the server does not have.
• resumebooster://board/stats (reads with no key) — The same payload as board_stats: servable and tracked totals, open company boards, the category set, the freshness stamp.
• resumebooster://me/key (needs a key or sign-in) — The same payload as key_status: tier, calls left, and which tools would answer.

On the board, every posting and every search has a control that copies a prompt for your agent — it names the posting's id or the search's arguments and this server's URL.

Applying stays yours

Search the board from your own AI (Claude, ChatGPT or Claude Code), read each posting in full, and apply yourself on the employer's own site: you check every answer and you press submit. Your AI can read a posting in full and help you draft; you check every answer before it goes anywhere.