Dora NodaYour CI server already takes orders from robots. JetBrains ships an official plugin that turns TeamCity into a Model Context Protocol server, so an agent in Claude Code can read build state, page through logs, and manage pipelines without touching the dashboard. Dooor OS goes further: its MCP server exposes apps, deploys, databases, and monitoring as tools, with a deploy-readiness contract that grades every release READY, WARN, or BLOCKED before anything ships. And if your platform offers agents nothing at all, that no longer stops them — Frigade recently gave Jira, Spotify, and Hacker News agents with over 100 built-in Skills without touching a line of their code.
That is the pattern this post is about. Agents will operate your platform whether or not you design for it. The only question is whether their traffic arrives through an interface you can version, scope, and audit — or through a scraped dashboard session you cannot. Below is a concrete look at what the two most instructive precedents actually expose, what the scrape-around costs, and a checklist for what a PaaS API must offer agents: deploys, logs, and service state as first-class machine-readable resources.
TeamCity: the CI precedent
The JetBrains teamcity-mcp plugin is the official answer to "what should CI expose to agents," and its design is worth studying because it is conservative in exactly the right places. Installing the plugin adds a streamable-http MCP endpoint at https://<your-teamcity>/app/mcp on the TeamCity server itself (TeamCity 2026.1 or later, JDK 17+), speaking MCP protocol version 2025-11-25. Any compliant client connects with one command:
claude mcp add --transport http teamcity \
https://teamcity.example.com/app/mcp \
--header "Authorization: Bearer <your-token>"The tool surface is small and deliberate:
| Tool | What the agent gets |
|---|---|
teamcity_rest_get / post / put / delete | The full TeamCity REST API — builds, tests, agents, VCS roots, infra settings — wrapped as four tools |
teamcity_build_log | Build logs with pagination, so a 40,000-line failure log arrives in digestible pages instead of one context-blowing dump |
| Pipeline tools | Read, create, and delete pipelines |
Two design choices stand out. First, operation modes: Safe mode is the default and stays read-only except for curated, safe-by-default write paths; Brave mode (teamcity.ai.mcp.braveMode.enabled) unlocks full read/write including DELETE and arbitrary POST. An agent that can delete your release pipeline has to be opted into, explicitly, by the server admin — not by the prompt. Second, auth-awareness: the endpoint takes TeamCity Bearer tokens and works with 2FA-equipped accounts, so agent access inherits the same identity and permission model as human access instead of a parallel shadow credential.
Note what JetBrains did not do: it did not build a bespoke agent API. It wrapped the REST API it already had, added the one agent-shaped affordance that REST lacks (paginated log retrieval), and gated writes behind a mode flag. That is the cheapest credible version of this work, and it sets the floor: if your platform already has a REST API, the distance to an agent interface is a thin MCP translation layer plus a write policy.
The community had already proven the demand. Third-party TeamCity MCP servers — one advertises 87 tools for builds, tests, agents, and pipeline management across Claude Code, Cursor, and Windsurf — existed before the official plugin. When your users build the unofficial version first, the official version is overdue.
Dooor OS: the deploy precedent
If TeamCity shows the floor, Dooor OS's MCP server shows what a fuller PaaS-shaped surface looks like. It exposes the workspace's apps, deploys, git repos, env vars, databases, agents, and monitoring as MCP tools, every tool scoped to a single workspace resolved from the API key. Its README reads like a checklist of production concerns most first-draft MCP servers skip:
- Capability discovery with fail-closed behavior. Clients start with a
capabilitiestool returning the workspace, key scopes, and tool families. The server exposes only the product tools advertised for that workspace and fails closed when discovery is unavailable, so one client's tools never leak into another client's session. - Read-only by family. All
data_*andlake_*tools (business questions over operational sources, analytical SQL over the lake) are read-only. Writes live in the platform families and require write scopes likeapps:write. - A deploy-readiness contract. Readiness review and deployment are separate operations: requests to inspect, review, or fix an app never authorize a deploy. Before deploying, the agent must review the exact revision, verify the build and runtime contract, classify the result as READY, WARN, or BLOCKED, and report its evidence. BLOCKED must not ship; WARN needs explicit risk acknowledgement. This is the deploy equivalent of TeamCity's Safe mode, but expressed as a workflow contract instead of a flag.
- Stateless transport.
GET/DELETE /mcpreturn405— no long-lived sessions or server-initiated streams, one JSON-RPC request per call, keyed byX-Api-Keyor Bearer token. Statelessness is what lets the server run behind ordinary HTTP infrastructure without sticky sessions. - Bounded rate limiting and error hygiene. A best-effort 120 requests/minute per hashed API key (explicitly not IP-based, since proxies make IPs unreliable), no stack traces or internal identifiers in error bodies, and server-generated correlation IDs on every public failure.
Two details deserve emphasis for PaaS builders. First, Dooor keeps MCP for the operator path and REST for the workload path: "a running app does not embed an MCP client" — app backends call the Dooor REST API with a dedicated, minimally-scoped key. MCP is the agent-operates-platform interface, not a runtime dependency. Second, even platform conveniences like managed aliases (finance-copilot.apps.dooor.ai on wildcard DNS with cert-manager TLS) are tool-shaped: read, reserve, and release are separate tools with separate scopes.
The demand signal: agents route around you
TeamCity and Dooor OS are the designed path. The undesigned path is already running at scale, and Frigade's September 2026 Assist API launch is the clearest evidence of it. Frigade learns a product the way a user does: a browser agent signs in with real user permissions, works through the actual workflows, and builds a model of what the product does — no docs, no partnership, no code changes on the target side. The company's own framing is blunt: it gave Jira, Spotify, and Hacker News an AI agent with over 100 built-in Skills "without touching a line of their code." Retell AI, a company that builds agents for a living, is building on the Assist API rather than building product-learning itself.
Read that from the platform side and it is a demand signal, not a product announcement. Your dashboard is already an agent interface — just an accidental one, driven through browser sessions with user credentials. The community playbook confirms the direction: the agent-mcp-integrations project exists solely to wire Claude Code, Codex CLI, and Gemini CLI to browsers, clouds, databases, infrastructure, and domain APIs through MCP. Agents are being pointed at infrastructure as a category, and they will reach your platform through whatever opening exists.
The scrape-around has concrete costs that compound:
- It breaks on every UI change. A redesigned settings page is a breaking API change for every agent driving it, with no version, no changelog, and no deprecation window.
- It has no scopes. A browser session carries the user's full permissions. There is no equivalent of
apps:readversusapps:write, no read-only family, no Safe mode. - It has no audit story. Agent clicks are indistinguishable from user clicks in most audit logs — same session, same credential, no tool-call record with parameters.
- It inherits your rate limits badly. Interactive sessions were tuned for humans; an agent polling deploy status through page loads is the most expensive possible client.
None of this is hypothetical. It is the normal outcome when machine traffic meets a human-only interface: the machines come anyway, through the worst available door.
The PaaS checklist: deploys, logs, and state as first-class tools
So what should a PaaS expose? Combining the TeamCity floor, the Dooor OS ceiling, and the scrape-around costs, the minimum credible surface is five resources, each available as versioned REST or GraphQL and as purpose-built MCP tools (the REST layer is the contract; the MCP layer is the ergonomic shape for agents):
| Resource | REST/GraphQL shape | MCP tool shape | Notes borrowed from the precedents |
|---|---|---|---|
| Deploys | POST /apps/{id}/deploys, GET status | deploy_app + deploy_status, split like Dooor's review/deploy separation | Readiness gate (READY/WARN/BLOCKED) before any mutating call; WARN needs explicit acknowledgement |
| Build and deploy logs | GET with cursor pagination | app_logs with pagination, TeamCity's teamcity_build_log model | Paginate by default — unbounded log reads are how agents blow their context and your bandwidth |
| Service state | GET /apps/{id}: status, revision, replicas, health, domains | app_status returning the same object | Single source of truth agents can poll cheaply instead of scraping the dashboard |
| Env vars and config | Scoped read/write endpoints | Separate config_read / config_write tools | Reads and writes split so a monitoring agent never holds write scope |
| Domains and TLS | Alias reserve/release endpoints | Dooor's get/set/remove_app_platform_domain model | Read vs. mutate split; async states like TLS_ISSUING surfaced, not hidden |
And three cross-cutting requirements, all visible in the precedents:
- Version it. TeamCity pins an MCP protocol version; your REST contract needs the same. Agents pin to versions far more aggressively than frontend code because their prompts bake in expected shapes.
- Scope it. Workspace-scoped keys, per-family read/write scopes, Safe-by-default with an explicit Brave (or BLOCKED/WARN) escalation for destructive operations. The principle from both precedents: the dangerous capability must be unreachable by accident.
- Audit it. Every tool call logged with identity, parameters, and result. This is the single largest upgrade over the scraped session, and it is free once traffic flows through your tools.
Start with read-only tools plus a gated deploy path — that covers the overwhelmingly common agent workflows (check status, read logs, ship a fix) while keeping the blast radius small. The community 87-tool servers show where unscoped enthusiasm ends; the official plugins show where to begin.
Agents are the new API consumer
The numbers say this is not early anymore. MCP crossed 10,000 active public servers in March 2026, with roughly 97 million monthly SDK downloads; the official registry held 9,652 server records by late May; the protocol sits under Linux Foundation governance since December 2025. CI and deploy platforms are joining that graph now — TeamCity with the conservative official plugin, Dooor OS with the fuller PaaS surface — and the Frigade episode proves the alternative to joining it is being operated through your own UI by someone else's agent.
For teams self-hosting a PaaS, the implication is practical rather than philosophical. You own the machines, the control plane, and the API — which means the agent interface is yours to design instead of yours to discover in the access logs. Expose deploys, logs, and service state as versioned, scoped, auditable tools, default to Safe, and agent traffic becomes your best-behaved client instead of your least visible one.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.
