Jobby.dev MCP server

Short answer: the Jobby.dev MCP server lets any MCP-capable agent — Claude Desktop, ChatGPT (Apps SDK), Cursor, Zed, Continue — drive the full Jobby.dev surface in natural language. Same scopes, same rate limits, same data as the REST API.

Why MCP?

The Model Context Protocol is an open standard for connecting LLM agents to external tools and data. The agent decides when to call a tool and which tool to call, based on a tool catalog the server publishes. Jobby.dev publishes ~35 such tools (the jobbydev_* namespace), each mapping 1:1 to a v1 REST endpoint.

Two transports

stdio binary — install via npx -y @jobbydev/mcp or download an .mcpb bundle. Runs locally; the agent spawns it as a subprocess. Best for desktop clients (Claude Desktop, Cursor, Zed).
HTTP endpoint at https://jobby.dev/api/mcp — stateless JSON-RPC 2.0 over HTTP. Best for hosted clients and the ChatGPT Apps SDK. Same tool catalog, same auth.

Authentication

Mint a Personal Access Token at jobby.dev/account/api-tokens and pass it as the bearer for HTTP, or via the JOBBYDEV_API_TOKEN env var for stdio. The discovery tools (jobbydev_live_now, jobbydev_jobs_search) work without a token; everything personal requires one.

Tool naming convention

Every tool is namespaced jobbydev_* so the agent can disambiguate from other connected servers. Tool names are stable — we add new tools rather than renaming existing ones. A non-exhaustive sampler:

jobbydev_live_now — discover currently-live events
jobbydev_jobs_search — query jobs at live events
jobbydev_queue_join — enter the queue for an event
jobbydev_queue_status— read the user's queue position
jobbydev_billing_status — current plan + minutes balance
jobbydev_create_upgrade_checkout — open a Stripe Checkout for a paid plan
jobbydev_webhook_create — subscribe to event push notifications

The full reference (every tool, every argument, every example) lives in the API reference — everyjobbydev_* tool maps to one REST endpoint and shares its docs.

What an agent cannot do

By design, three actions are off-limits to agents — only humans can perform them, from a browser or native client:

Accept a match. The agent can read pending matches (jobbydev_matches_list), but acceptance is a human tap.
Sit in the live video room. The agent can fetch a one-time join URL (jobbydev_interview_room_url) for the user, but cannot present it itself.
Approve off-session charges without consent. The first off-session charge requires the user to complete a hosted Stripe Checkout that captures explicit consent. After that, the agent can charge silently for upgrades within the consented surface.

See the humans-only rule for the rationale.

Install

Per-client install guides (coming soon as supporting pages):

Claude Desktop
ChatGPT App
Cursor
Zed
Continue

Why MCP and not just REST?

Most B2B SaaS products today ship a REST API plus, optionally, a chat plugin per LLM platform (a ChatGPT plugin, a Claude plugin, a Cursor extension, etc.). MCP collapses that fan-out:

One server, every client. The same jobbydev_*tools work in Claude Desktop, ChatGPT, Cursor, Zed, Continue, Replit, and every future MCP-capable client. We don't maintain a separate plugin per platform.
Tool catalog is self-describing. The agent discovers tools at connect time — names, parameters, return shapes. No per-client manifest authoring; the same MCP tool definition that Claude reads is what Cursor reads.
The auth model fits agents.Personal Access Tokens are user-minted and user-scoped. The agent doesn't need its own OAuth client registration; the user pastes a token into the MCP config once and they're done.

The REST API still exists and is the source of truth — every MCP tool is a thin wrapper over a REST endpoint. Use REST when you're building a non-conversational integration (a Slack bot, an ATS sync, a Zapier flow). Use MCP when you want the user's agent to drive Jobby.dev directly in conversation.

Example conversations

What this looks like end-to-end with a connected agent:

User: Are there any backend roles open right now on Jobby.dev?
Claude: (calls jobbydev_jobs_search with { skills: ["backend"] })
Three live now: a Senior Backend Engineer at Acme (Go, Postgres, $180k-$220k), a Staff Engineer at Beta Corp (Rust, distributed systems, $250k-$300k), and a Backend / Data Engineer at Gamma (Python + Snowflake, $160k-$190k). Want me to queue you for any of them?
User: Queue me for the Acme one.
Claude: (calls jobbydev_queue_join with the event ID)
You're queued — position #3, estimated 8-minute wait. I'll let you know when you match.

And on the recruiter side:

Recruiter:What's my billing status look like this month?
Claude: (calls jobbydev_billing_status)
You're on Pro: 32 of 40 hours used, ~8 hours left in the cycle (renews in 6 days). Want me to upgrade to Power Play, or add a one-time hour pack?
Recruiter: Upgrade me to Power Play.
Claude: (calls jobbydev_create_upgrade_charge_offsession)
Done — Power Play takes effect immediately, your card was charged $XX with proration credit for the unused Pro time. You now have ~200 hours/month and 25 seats.

These aren't mocked — they're the actual conversational shape from the integration. The REST API runs underneath; the agent just translates.

Limitations and what they mean

MCP isn't a no-cost wrapper over REST. Three real limitations to plan around:

No streamed tool output.Tools return a single response, not a stream. For long-running operations (resume parsing, AI candidate compare), the user sees nothing until the tool completes. Mitigation: cap long operations at ~30 seconds server-side and surface a "still working" status if longer.
Per-client surface differences. Claude Desktop renders tool results inline as text; ChatGPT (with the App) can render rich widgets; Cursor and Zed are text-only. Tools that benefit from rich rendering (interview room URL, embedded checkout) work everywhere but feel best in ChatGPT.
Notifications need explicit polling outside ChatGPT. MCP supports server-pushed JSON-RPC notifications, but only ChatGPT (via the OpenAI Apps SDK) and Claude Desktop currently surface them in-chat. Other clients require polling jobbydev_inbox_list (P1 follow-up; the SSE notification channel is upstream of this work). Until inbox_list ships, agents notify via the queue-status / matches endpoints on a 5-10 second polling cadence.

Tool catalog highlights

See tools reference for the full list with arguments, returns, and scopes. The most-frequently-used:

jobbydev_live_now — public, no-auth. The discovery tool every agent calls first.
jobbydev_queue_join / jobbydev_queue_status — the seeker workflow.
jobbydev_create_event / jobbydev_event_go_live — the recruiter workflow start.
jobbydev_billing_status / jobbydev_create_upgrade_charge_offsession — the agentic billing path. Off-session requires prior consent.
jobbydev_webhook_create — wire Jobby.dev events to any other system. Useful even from REST- first integrations.