MCP — use terminalhire from any AI editor

The CLI ships a built-in Model Context Protocol server: terminalhire mcp. Any MCP-speaking host — Claude Code, VS Code, Cursor, Windsurf, OpenAI Codex CLI, Gemini CLI, Zed, JetBrains AI Assistant — can ask it for your matches.

The match tools are read-only and make zero network calls: their answers come from the local match cache the CLI already maintains. Claim preview performs governed public reads, and claim record writes intent to your local ledger only. Nothing about your profile crosses the wire because a model asked.

Setup

Print ready-to-paste config for every supported host:

terminalhire mcp --print-config

Claude Code is one line:

claude mcp add --scope user terminalhire -- terminalhire mcp

terminalhire init can also write the config for you (Cursor and Gemini CLI, consent-prompted, existing config backed up and merged — never clobbered).

A host that isn't on that list

--print-config covers VS Code, Cursor, Codex CLI, Gemini CLI and Claude Code. Any other host that launches local MCP servers takes the same entry — a command, not a URL:

{
  "mcpServers": {
    "terminalhire": { "command": "terminalhire", "args": ["mcp"] }
  }
}

VS Code names the map servers instead of mcpServers and wants an explicit "type": "stdio" on the entry. Codex CLI uses TOML. terminalhire must be on the PATH of whatever process starts the host — a foreign host launches the globally-installed binary, not the Claude Code plugin's bundled copy.

A host that only accepts a URL

Some services — Lovable, hosted agent builders, anything whose "add MCP server" dialog asks for a Server URL — run the connector on their machines, not yours. terminalhire mcp has no URL to give them. It is a local process reading a local cache, which is how your profile stays on your laptop. There is no hosted version of it and there will not be one.

The founder server is the one with a URL. Fill that dialog like this:

Field	Value
Server name	anything — `terminalhire` reads fine
Server URL	`https://terminalhire.com/api/founder/mcp`
Authentication	OAuth, or a bearer token — both work

With OAuth, the client sends you here to approve it. That page names the app and shows the exact address your authorization will be sent to. Read that address. The name beside it is supplied by the app itself, so it proves nothing — anyone can register a client and call it anything. If you do not recognise the address, close the page; nothing is shared until you press Approve. Approving hands the client a connector token, the same kind described below.

With a bearer token, create one yourself from your dashboard — the connectors row under postings takes a name and hands back the endpoint and a token. Use this when a client cannot do OAuth, or when you would rather not click through a browser.

The token is shown once. We store only a hash of it, so nothing can show it to you again — if you lose it, revoke that connector and create another. Name each one after the client you paste it into, because that name and its last-used date are how you tell them apart later.

If your GitHub profile carries a public email, we send a note there whenever a connector is created — so one you did not make means someone reached your signed-in session. Revoke it, and any other connector you do not recognise: connectors do not expire, so revoking is what stops them. (No public email on your profile means no note, which is a gap we are closing.)

It does not expire, and an expiry was never what protected it — you are told by email the moment one is created, which is the signal that catches a connector you did not make. It is not your browser session and cannot stand in for one: it reads your postings, and publishes drafts only if you granted it that when you created it. Nothing holding it can accept work or pay anyone. Treat it like a password anyway, and revoke it from that same list when you are done with a client — revoking one connector leaves your other clients and your browser session untouched.

The endpoint speaks JSON-RPC 2.0 over plain HTTP — one POST, one JSON response, no SSE stream. A host that insists on opening an event stream will not connect.

Tools

Tool	Returns
`jobs`	Your top matched roles (title, company, score, matched tags)
`contribute`	Credential-building open-source issues ranked by winnability — on by default (opt out with `contributeEnabled: false`)
`bounties`	Paid public bounties — opt-in surface, off by default
`inbox`	Aggregate counts only: unread chats, pending intro requests
`claim_preview`	Claimability, contention, and repository-policy facts; writes nothing
`claim_record`	A local `claimed` ledger entry; never starts, pushes, submits, or opens a PR

Every tool answers a structured not_onboarded hint when the CLI isn't set up yet.

What's deliberately NOT here

No message content. inbox returns counts, never chat text — your conversations don't enter a host model's context window.
No intro accept/decline. Consenting to share contact details requires a human-typed yes in the CLI. A model cannot perform consent for you.
No enrollment. contribute is on by default and never writes config; if you've explicitly opted out (contributeEnabled: false) it reports that gate rather than flipping it.
No execution or submission. Claim recording can register local intent, but MCP cannot start a worktree, fork, push, submit, or open a PR. A prohibited repository policy remains a human-only CLI decision.

The full frozen tool contract lives in the repo: docs/mcp-tools.md.

Posting work is a different server

This one is for finding and locally claiming work. Its claim tools make public GitHub reads, but never post or submit anything under your identity. If you are on the other side — you have work you want done — there is a separate hosted server that drafts a posting, and publishes it if you grant it that. Nothing to install, and it shares nothing with this one. See post work.