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 agent? Setup for Cursor, VS Code and other tools is 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 25 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, board_stats, search, fetch answer with no key at all — 25 calls a day per network address, 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 kinds of key

Read tools — search_jobs, get_job, get_jobs, check_jobs_open, check_apply_support, 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 needs a paid key, exactly like POST /v1/fit on the data API.

Apply tools — request_application, application_status — act on your account, so they need an agent key minted from a signed-in session on this page, plus an active Agent plan or a live pass (sold on the page) and the mandate set up in Account. 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; a live pass raises both for its hours.

Which hosts can reach which tools

Every keyed tool call carries a credential, and hosts hold it two ways. From Claude Code, Cursor, VS Code and More…: 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, quota and pass a pasted key would use); before sign-in, or while it is off, the unkeyed tools — search_jobs, board_stats, search, fetch — still answer, 25 calls a day per network address, 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 connector in developer mode; there is no field for an API key, and search and fetch (the names its research connector calls) answer with no sign-in — 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.
• Cursor — reaches every tool: the headers block in ~/.cursor/mcp.json, with Cursor's ${env:NAME} interpolation so the key never sits in the file.
• VS Code — reaches every tool: the headers block in .vscode/mcp.json, fed by a promptString input with password: true so the key is typed into VS Code, never into the file.
• More… — reaches every tool: an Authorization header on each POST — Streamable HTTP, stateless; each app below has its own block.

All 15 tools

• search_jobs (any free key; answers with no key, 25/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) — 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) — 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) — Are these postings still on the board? Up to 200 ids per call, 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.
• check_apply_support (any free key) — Whether the apply agent can submit to this job on your behalf, and what that requires. Non-supported jobs still return their direct apply URL for you to use.
• board_stats (any free key; answers with no key, 25/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) — 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) — 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, whether the paid tools are open on it, and whether the apply tools would work — 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, 25/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, 25/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 (paid key) — 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. Paid keys, exactly like POST /v1/fit — and a live pass.
• request_application (agent key) — Ask your apply agent to submit an application to a job — on an Agent plan, or on a live pass that pays for it at accept. Passes through every gate of the signed-in flow — mandate, honesty classifier, vendor boundary, daily cap.
• application_status (agent key) — Status of the applications your agent has requested — queued, submitted, refused (with the refusing gate named), or failed.

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

• find_roles_for_my_cv — Find roles that fit my CV: Reads the occupation out of a CV, searches the live board without a key, then verifies the shortlist is still open — the one step that needs a key or a sign-in. Never invents a CV and never requests an application without a yes per job.
• apply_to_my_shortlist — Apply to my shortlist: Asks what this connection may do first (plan or pass, mandate, résumé on file, applications left), checks each job's hiring system, shows the cards, and requests one application per job only after the person confirms it.
• what_can_my_key_do — What can this connection do right now: One status call, explained in plain words: tier, calls left, whether the paid scorer and the apply tools would answer, and what would change each closed answer — the gate, never a price.

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, which tools would answer, and the pass if the account holds one.

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.

What your agent can and cannot do

Applications requested here go through the exact same pipeline as the signed-in flow — the MCP layer is a translator, never a bypass. Your agent can do at most what you could do yourself, signed in.

• Your mandate's off switch always wins. Agent switched off or paused in Account? Every request refuses, including from this endpoint.
• The honesty classifier never invents answers. Application answers are drawn from your own profile; any answer it cannot support blocks the send and waits for you.
• Only 5 hiring systems are agent-submittable today: Breezy, Oracle, Personio, Pinpoint and Teamtailor. Jobs on other systems get prepared for you to send yourself — check_apply_support tells you which is which before you ask.
• Daily caps apply. The same release caps as the signed-in agent — a connected agent does not get a bigger allowance.
• Every refusal is named. A request that does not go out shows up in application_status with the refusing gate stated, not a silent disappearance.