Backstage Hits CNCF 'Adopt': What Pairing a Software Catalog With an MCP Server Actually Takes

Backstage is now officially boring technology — in the best sense. In March 2026, CNCF and SlashData surveyed more than 400 professional developers and placed Backstage in the "Adopt" tier of the application-delivery Technology Radar, alongside Helm and kro. Four months later, CNCF published the other half of the story: in the agentic enterprise, AI agents become platform consumers alongside humans, and the platform "must provide interfaces designed for both humans and AI agents." So here is the question every platform team inherits from those two announcements: what does it actually take to run Backstage as the catalog a human browses, next to an MCP server as the interface an agent calls, without the two drifting into contradictory inventories?

The answer up front, in one rule: one catalog, two interfaces. The software catalog stays the single source of truth for what services exist and who owns them; the MCP server is a read-through window onto that truth, not a second inventory. Everything below is the concrete cost of honoring that rule:

The rest of this post substantiates each row: why the pairing is now the default bet, what the official agent interface actually exposes, why read-through beats re-inventory, and the four hard parts — auth, writes, refresh, drift — that separate a demo from a production agent surface.

Why this pairing is now the default bet​

Start with the human half. The CNCF–SlashData platform engineering report of March 24, 2026 found platform tooling maturing just as organizations brace for AI-driven infrastructure, and its application-delivery radar put exactly three technologies in "Adopt": Helm, Backstage, and kro. That is not a hype ranking — it is 400-plus practitioners saying these are the reliable choices. Backstage's project health backs it up: eighth in velocity among 100-plus CNCF projects when Spotify contributed it in 2020, sixth of more than 230 by 2025, with CNCF's March 2026 documentary calling it the "global open source standard for platform engineering."

Then comes the machine half. CNCF's July 21, 2026 essay on platform engineering for the agentic enterprise argues that agents will provision resources, deploy applications, inspect operational state, and invoke workflows "on behalf of their human collaborators" — and that the platform can no longer assume every interaction originates from a human. CNCF's September 1 follow-up on platform maturity sharpens the point: "The self-service interface you built for your developers is not the same thing as a machine-consumable interface for agents." A portal page a human clicks is not an API an agent can reliably call.

The bridge between the two halves is structure. As CNCF CTO Chris Aniszczyk put it at KubeCon EU in March 2026: agents "need to feed off generally structured information," and "an IDP like Backstage structures services, who owns what — it provides the information that agents need to be actually super effective." The catalog already contains the answers agents need — service names, owners, dependencies, docs, templates. The pairing question is purely mechanical: how does an agent read that structure without forking it?

What the official agent interface looks like today​

A year ago the answer was "build your own bridge." In 2026 it is a supported plugin: @backstage/plugin-mcp-actions-backend, which serves an MCP endpoint — by default at /api/mcp-actions/v1 — exposing Backstage's own Actions Registry as MCP tools. The catalog and the scaffolder become callable: catalog.query-catalog-entities for structured catalog reads with predicate filters, logical operators, field selection, sorting, and pagination; scaffolder.dry-run-template and scaffolder.execute-template for template runs. Downstream distributions confirm the shape — TIBCO's Developer Hub 1.19 documents eleven MCP tools on exactly this endpoint.

Three 2026 additions show the surface maturing past its first draft. First, the plugin now supports splitting actions into multiple servers via mcpActions.servers configuration, each with its own endpoint and include/exclude filter rules — so a read-only catalog server and a scaffolder-capable server can be genuinely different servers with different credentials, not one server with polite documentation. Second, Backstage 1.54 added a refresh-catalog-entity action that re-queues a single entity for processing, so an agent can read back fresh catalog data immediately after a scaffolder run instead of waiting for the next scheduled processing loop. Third, the catalog model itself gained an McpServer entity kind (now an opt-in backend module), meaning MCP servers can be first-class catalog citizens — discoverable, owned, lifecycle-managed — rather than sidecar infrastructure the catalog cannot see.

Teams are already converging on the official path. Giant Swarm removed a third-party catalog-MCP plugin in favor of the built-in query action, whose filter expressiveness covered every use case. Open edX's Backstage deployment added the MCP feature set from the 1.53 template to expose its catalog to agents read-only, fronted by OIDC consent. For teams not ready to upgrade, community bridges fill the gap: backctl exposes catalogs, TechDocs, and dependency graphs as both a scriptable CLI and an MCP server, and bsctl offers a client-side MCP for catalog operations without requiring Backstage changes. The ecosystem agrees on the direction even where it differs on the vehicle.

The sync architecture: read-through, not re-inventory​

With the tooling mapped, the architecture decision is binary. Either the MCP server reads live catalog state on every call (read-through), or some job periodically exports catalog data into a store the agent reads (re-inventory). Only the first honors the one-catalog rule, and the reasons are operational, not aesthetic.

A re-inventory introduces a second source of truth with its own lag, schema, and failure modes. Every export job is a promise that the agent's world matches the human's world "as of" some timestamp — and every incident review involving an agent will start by questioning that timestamp. Ownership metadata rots first: the team that owned a service in last night's export may have been renamed in this morning's catalog. Dependency edges rot second. By the time the agent acts on a week-old export, the human looking at the portal sees a different platform.

Read-through inverts the failure mode. When the agent queries catalog.query-catalog-entities against the live catalog, a stale answer is impossible by construction — the query hits the same backend the portal renders. The costs move somewhere honest: query latency against the catalog backend, load on the catalog API under agent fan-out, and the need for predicate filtering so agents fetch ten entities instead of ten thousand. Those are capacity problems with known solutions (field selection, pagination, caching at the transport layer), not correctness problems with unknown blast radii.

There is one legitimate exception: deliberately snapshotted context for audit or eval. If you need to prove what an agent saw when it made a decision, log the query and response — do not pre-emptively export the catalog "for the agent" and let the snapshot become the de facto interface. Snapshots are evidence; the catalog is truth.

The four hard parts nobody can skip​

Tooling plus architecture gets you a demo. These four get you a production agent surface.

1. Auth scoping: the agent is a new principal, not a new user. The portal authenticates humans; the MCP endpoint must authenticate agents as distinct principals with their own least-privilege grants. The Open edX pattern — OIDC consent in front of a read-only endpoint — is the right starting posture: the agent proves who it is and gets catalog reads, nothing more. From there, scope down, not up: separate MCP servers for read versus scaffolder actions (the mcpActions.servers split exists precisely for this), short-lived tokens per agent session, and ownership-aware filtering so an agent acting for team A cannot enumerate team B's services. A static, long-lived, admin-scoped token in an agent's environment is how a prompt injection becomes a catalog rewrite.

2. Write governance: scaffolder execution is deployment authority. Read tools are safe to open early; scaffolder.execute-template creates repositories, files, and sometimes infrastructure. Every write-capable action needs the same treatment as a CI pipeline with deploy keys: dry-run by default (scaffolder.dry-run-template exists for exactly this), human approval for production templates, full audit logging of who-or-what executed which template with which parameters, and rollback or teardown paths for what the template created. If your golden-path templates assume a human reviewed the inputs, they are not agent-ready until that assumption is replaced by validation the template itself enforces.

3. Refresh latency: writes must be readable before the agent's next step. An agent that scaffolds a service and immediately queries for it will outrun any scheduled catalog processing loop. Backstage 1.54's refresh-catalog-entity action is the targeted fix: re-queue the entity the agent just created and read back fresh state in the same workflow. Design agent runbooks to call refresh-then-read after every mutation rather than sleeping and retrying — sleeps encode guesses about loop timing that break under load, while refresh-then-read encodes the actual dependency.

4. Drift visibility: prove the agent and the human see the same platform. Even with read-through, drift can hide in filters: an agent querying with stale predicates, a cached transport layer, or ownership rules that changed after the agent's session started. Make agreement checkable: every agent-facing response should carry enough provenance (entity UID, catalog revision or refresh timestamp, owning team) that a human can reproduce the agent's view in the portal. When the portal and the agent disagree, that provenance turns a mystery into a diff. Periodically run the same query through both surfaces in CI — the portal's catalog client and the MCP tool — and fail loudly on divergence.

A self-hosted team's starting checklist​

For a team running its own Backstage on its own machines, the adoption order matters more than the tool choice. Do it in this sequence:

1. Enable the official MCP plugin read-only first, replicating the Open edX posture: catalog queries over MCP, OIDC consent, no scaffolder execution.
2. Split servers early with mcpActions.servers so reads and future writes never share credentials, even before any write tool is enabled.
3. Scope tokens per agent and per session; verify an agent for one team cannot read another team's entities.
4. Add refresh-then-read to every agent runbook that mutates anything, using the 1.54 refresh action.
5. Gate scaffolder.execute-template behind dry-run-by-default, human approval for production templates, and audit logging.
6. Register every MCP server you run — including community bridges — as catalog entities, so the machine surface is itself owned and discoverable.
7. Add a CI check that runs identical queries through the portal client and the MCP tool and fails on divergence.

None of these steps requires a managed platform or a second inventory. They require treating the agent as what CNCF says it is: a platform consumer with the same right to accurate state as the developer clicking through the portal — and the same obligation to authenticate, stay scoped, and leave an audit trail.

Backstage earned "Adopt" by being the place humans go to learn what exists and who owns it. The teams that win the agentic half will be the ones that keep it the only such place — with the MCP server as its machine-readable shadow, reading the same truth the portal renders, refreshed the moment it changes, and never allowed to become a second truth of its own.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent-operated deploys need machine-readable infrastructure state; that is what we build toward. Star the repo on GitHub or deploy your first app today.