Yellowhead Digital

Agent door

The agent door

A live Model Context Protocol (MCP) server that gives an authenticated agent an org-scoped, capability-bound, fully audited way into a workspace.

Yellowhead is built on a two-door architecture. Both doors read and write the same rows in the same database, under the same row-level security — there is no sync layer between them:

  • The human door — the dashboard at app.yellowhead.digital.
  • The agent door — a standards-based MCP server that lets someone else's agent (Cursor, Claude Desktop, a customer's LLM workflow) query and act on a workspace with cryptographically verifiable, org-scoped, capability-bound authority.

Status: live

The agent door is live in production. Its OAuth discovery documents are anonymously fetchable and its token and transport endpoints are serving. The base host is https://api.yellowhead.digital.

  • Protected-resource metadata: GET /.well-known/oauth-protected-resource
  • Authorization-server metadata: GET /.well-known/oauth-authorization-server
  • Token endpoint: POST /mcp/oauth/token
  • MCP transport: POST /mcp (with GET/DELETE for session management)

See Authentication for the full token and session flow, and the Tools reference for what the door exposes.

A client that wants the door's connection facts without reading this page can fetch https://yellowhead.digital/.well-known/mcp.json. It carries the server name and version, the streamable-HTTP endpoint, and links back to the two OAuth metadata documents above. Its shape is the MCP Registry server.json schema; the well-known path is a de-facto convention rather than a ratified one — no MCP well-known URI is registered with IANA yet, and the Server Card proposal is still open — so the document declares its own provisional status and the endpoint it names is the stable fact.

Access model: available by request

The agent door is available on every paid plan (Starter and above), in two forms. On Starter and Pro it is read-only: an agent can list and fetch your diagnostics, reports, published deliverables and — where your plan includes them — action items, and nothing else. On Enterprise and Agency the MCP Agent oversight console adds write access — updating action items, commenting, re-running a Diagnostic — with every write held for a human's approval, plus self-managed grants, trusted issuers and anomaly alerts.

Access is vendor-provisioned, not self-serve: there is no public sign-up that mints agent credentials. Access is granted by registering a trusted issuer (the identity provider whose assertions the workspace will accept) and issuing a capability grant that scopes exactly what an agent may do. On Starter and Pro we do that for you, read-only, on request; on Enterprise and Agency your workspace owner can do it in the console. This is the same provisioning shape many enterprise APIs use, and it is a deliberate control: the authority an agent carries is decided by a human, one capability at a time.

Writes are held by default. Even a grant that carries a write capability does not let an agent change anything on its own — every write is parked for a human to approve, unless the workspace has explicitly opted a grant into direct-apply (which itself requires the strongest form of client authentication). See Write approvals.

If you're on a paid plan, contact us to provision read-only access for your workspace.

What an agent can do today

  • Read diagnostics, forensic reports, action items, workspace usage, and published strategic-assessment and infrastructure-audit deliverables — each gated by a capability the grant must hold, and each scoped by row-level security to the grant's org.
  • Request a write to an action item's lifecycle fields — held for human approval by default.

The complete list is the Tools reference — generated from the server's tool registry and drift-checked in CI on every change, so it stays in lockstep with what the door actually serves.

Known limitations

  • Protocol sessions are dropped on a backend redeploy. The MCP transport keeps its per-connection protocol session in memory. When the backend redeploys, those in-memory sessions are cleared. The underlying bearer session is stored in the database and survives — a well-behaved MCP client simply re-runs the initialize handshake with the same token and continues. No re-authentication is required.
  • Read-only over JSON. The transport returns tool results as JSON in the POST response; there is no server-initiated event stream (the door is poll-based — an agent polls for the status of a held write). A standalone GET /mcp stream is intentionally not offered.
  • No token refresh. A session lives until it expires or is terminated; a new session needs a fresh identity assertion. See Authentication.