Agent data plane — MCP server

Before you read further: The agent data plane is not yet open for self-serve signup. You need an issued API key and base URL before any live request on this page will work — see Agent data plane for how access is arranged today.

The Model Context Protocol is how an AI agent discovers and calls tools. The plane ships an MCP server, signalsapi-plane, that exposes the hiring-panel primitives as agent tools — the same data, the same metering, and the same key as the REST API.

Where a REST client has to know which URL to build, an MCP agent sees 9 tools with typed arguments and picks one at reasoning time.

Status: local by design, waiting on plane access

signalsapi-plane is a stdio server: your MCP client spawns it as a subprocess and talks to it over stdin and stdout, exactly as the connect snippet below shows. That is the ordinary shape for an MCP server, and it is not a temporary arrangement — there is no public MCP endpoint to connect to, and there will not be one. The server runs on your machine before the plane opens and after it.

What is missing is the same thing the REST API is waiting on: the plane is not yet open for self-serve signup and has no public base URL. The server is a thin proxy — every tool call becomes a REST request against PLANE_MCP_BASE_URL — so until a base URL and key are issued, point it at the local mock and the whole stack runs on your own machine with no key. The source is committed under mcp/ in this repository.

On the day access is issued, nothing about the setup below changes: set PLANE_MCP_BASE_URL to the issued base URL and pass the issued key as the plane_api_key argument.

Want to be first in line? Tell Support what you’re building — that is not a prerequisite for anything above, just a signal that moves it up the queue. In the meantime every tool below has an exact REST equivalent, runnable now against the fixture gallery or the local mock.

Run it yourself

Start the local mock (see Run the specification as a local mock):
```
npx @stoplight/prism-cli@5.16.0 mock openapi/plane-v1.yaml
```
Install the server’s dependencies, from the repository root:
```
cd mcp && npm install
```

Point your MCP client at it. For a client that reads a mcpServers block (for example, Claude Desktop’s config file):

{
  "mcpServers": {
    "signalsapi-plane": {
      "command": "node",
      "args": ["/absolute/path/to/mcp/server.js"],
      "env": {
        "PLANE_MCP_BASE_URL": "http://127.0.0.1:4010"
      }
    }
  }
}

Every tool call is forwarded as a REST request to PLANE_MCP_BASE_URL — point it at a real base URL and pass a real key as the plane_api_key argument once one is issued, and nothing else changes.

Authentication

MCP tool calls carry no HTTP headers, so the key that the REST surface passes as X-API-Key is instead a tool argument, plane_api_key, on every tool. It resolves to the same per-customer key and enforces the same tenant isolation; an unknown or revoked key fails the call.

Treat it like any other secret your agent holds: inject it from a secret manager at tool-call time, never inline it into a prompt.

The tools

This table is generated from openapi/plane-v1.yaml’s x-mcp-tool operations, not hand-typed — the mcp-tool-table-generated assertion fails the build if it ever drifts from the specification.

Tool	Arguments	REST equivalent
`get_changes`	`since`, `company_id?`, `event_type?`, `limit?`, `idempotency_key?`	`GET /v1/events`
`get_open_reqs`	`company_id`, `function?`, `country?`, `limit?`, `idempotency_key?`	`GET /v1/companies/{company_id}/open-reqs`
`hiring_pulse`	`company_id`, `max_age?`, `idempotency_key?`	`GET /v1/companies/{company_id}/hiring-pulse`
`is_hiring`	`company_id`, `idempotency_key?`	`GET /v1/companies/{company_id}/is-hiring`
`pre_action_brief`	`company_id`, `max_age?`, `idempotency_key?`	`GET /v1/companies/{company_id}/pre-action-brief`
`search_jobs`	`role?`, `geo?`, `since?`, `cursor?`, `limit?`, `idempotency_key?`	`GET /v1/jobs/search`
`watch_company`	`company_id`, `event_types`, `webhook_endpoint_id`, `idempotency_key?`	`POST /v1/watches`
`who_is_hiring_for`	`role?`, `geo?`, `since?`, `cursor?`, `limit?`, `idempotency_key?`	`GET /v1/reqs/search`
`write_outcome`	`company_id`, `outcome`, `observed_at`, `req_key?`	`POST /v1/companies/{company_id}/outcomes`

Every tool also takes plane_api_key. Arguments marked ? are optional and share the REST defaults.

Every metered tool additionally accepts an optional idempotency_key argument — the header-less transport’s equivalent of the REST Idempotency-Key header, with identical semantics: reuse the same value on a retry and the call bills exactly once within a fixed 24h window, namespaced per key and per tool. write_outcome is a write-back rather than a metered read, so it does not take one.

Each tool returns the same JSON shape its REST counterpart serializes — provenance envelopes and all. No business logic is reimplemented behind the MCP surface: every tool above proxies the identical REST operation, generated from the same x-mcp-tool set as the table above, not hand-counted:MCP exposes 9 of 21 operations; 12 are REST-only.

How an agent uses them

The tools are designed to be composed cheaply-first, expensively-last:

Qualify with is_hiring — one cheap call unit tells you whether the company is worth any further spend.
Understand with hiring_pulse, or skip straight to pre_action_brief when you are about to act and want the whole picture in one round-trip.
Prospect with who_is_hiring_for when you have a role and a geography but no company yet — or search_jobs for the same matches as a flat, one-row-per-role list instead of grouped by company.
Stay current with get_changes — replay the cursor rather than re-reading company endpoints on a timer. It bills per event returned, so an unchanged world costs nothing.
Close the loop with write_outcome so the plane learns what actually converted.

hiring_pulse and pre_action_brief accept max_age (seconds) and are billed accordingly. When the company is cold and you declared a max_age, they return {"job_id": …, "status": "crawling"} rather than blocking — queue it, do something else, ask again shortly.

See Tiers and metering for exactly how each call bills.

Where to go next

REST API reference — every tool above, callable over HTTP today
Agent data plane overview — the ledger, the tiers, getting access

Recent changes

2026-07-09 — Agent data plane MCP server published: the same primitives as agent tools – code-complete, not yet hosted at a public endpoint.