One URL. Compatible clients.
Verifiable receipts.

MCP Endpoint

Use with a compatible server-side MCP client. OAuth begins on the first protected call.

Two tool locations. Two different jobs.

How it works — out-of-path

The four checkpoints

27-tool surface

Selected tools are shown below. Named profiles narrow the executable surface for governance, finance, read-only and enrollment use cases; the full profile contains 27 tools.

Wire format — read this before writing a bare HTTP client

Transport is MCP Streamable HTTP: one JSON-RPC request per POST to the endpoint above — not a separate long-lived SSE GET channel. Successful tool and protocol responses are framed as Server-Sent Events (content-type: text/event-stream), not bare JSON. Each response body contains event: and data: lines — the JSON-RPC payload is on the data: line. Naive JSON.parse(body) fails. Reference parser:

// Parse an MCP Streamable-HTTP SSE response body (Node 18+, no deps)
function parseSse(body) {
  const events = []
  for (const chunk of body.split('\n\n')) {
    const data = chunk.split('\n')
      .filter(l => l.startsWith('data:'))
      .map(l => l.slice(5).trim()).join('')
    if (data) events.push(JSON.parse(data))
  }
  return events // JSON-RPC messages; the tool result is in result.content[0].text
}

Requests are plain JSON-RPC over POST with Authorization: Bearer. Registration (CHK-1) returns a top-level agent_id. Outcome (CHK-3) returns the canonical receipt_id, its stored hash, and a ready-to-open verify_url — the same bytes the public verifier serves.

Or skip the plumbing entirely — the public reference runner is one dependency-free Node file that completes the full governed handshake with one enrollment token: PROMPTKING_ENROLLMENT_TOKEN="..." node promptking-governed-run.cjs (pass the token via environment or stdin — never on the command line). The enrollment token is one opaque string — paste it whole, exactly as the dashboard gives it to you; do not split it or interpret any part of it. You do not need a seat id: omit --seat — identity derives from your token binding, server-side, every call. --seat asserts which seat you expect to be operating as. The server independently derives your identity from your token binding and rejects the call on mismatch (PRINCIPAL_BINDING_VIOLATION). --seat never selects or switches identity. It demonstrates the protocol, reads the public verification record back, and prints your receipt's verify URL — it contains no governance logic and needs no PromptKing account beyond the token.

Static example — illustration only · not live evidence

Static example for illustration only — not live evidence. Every governed run produces a receipt, independently verifiable — the hash is recomputed in your browser, not by our server. The link below is one fixed historical receipt (issued 2026-07-16) kept so you can see what verification looks like. It is not proof that you (or any other agent) completed a handshake. Every valid PromptKing receipt carries an issuance timestamp and verifies at /verify/[id]. A receipt without a verifiable timestamp is not evidence.

Protocol stats (live)

Loading live stats...

Numbers are live production counts — early-stage, honest, not inflated.

What we never touch

PromptKing processes metadata only — agent identity, cost declarations, policy verdicts, and governance signals. We never see your prompts, your model responses, your files, or your users' content. We never sit between your agent and the vendor API. Decisions travel. PromptKing does not.