Backstage v1.54.0 Adds MCP Support and Agent-Friendly APIs, Becoming an Operational Control Plane

Backstage has grown from a Spotify internal tool to the de facto standard for developer portals in large engineering organizations. The platform catalogs services, APIs, and infrastructure; surfaces documentation through TechDocs; and provides scaffolder templates for standardized service creation. For the past few years, the primary interaction model has been human-driven: an engineer opens Backstage, searches for a service, reads documentation, or runs a template.

Backstage v1.54.0, released August 19, changes that assumption. The release introduces native MCP (Model Context Protocol) action support, an agent-friendly catalog refresh API, audit logging for Kubernetes and MCP operations, and a stable system metadata service. Together, these features signal that Backstage is positioning itself as the control plane not just for human developers but for the agents that increasingly operate alongside them.

Here is what changed, why it matters for platform teams, and what to watch when enabling agent access to your developer portal.

MCP Actions Backend: Agents Can Now Execute Backstage Operations

The most significant addition in v1.54.0 is the new @backstage/plugin-mcp-actions-backend. MCP is Anthropic’s open protocol for connecting AI assistants to external data sources and tools. By implementing an MCP actions backend, Backstage now exposes its operational capabilities—catalog lookups, scaffolder runs, entity updates—as structured tools that compatible agents can discover and invoke.

This is a shift in how developer portals are consumed. Instead of requiring a human to log into Backstage, navigate to a template, and fill out parameters, the portal becomes an API surface for agent-driven workflows. An agent can query the catalog to understand service ownership, trigger a scaffolder template to provision a new service, and read back the result through the same interface.

The MCP actions backend emits audit events for MCP server connection, tool discovery, and tool execution. Administrators can log which agents connected, which tools they discovered, and which operations they executed. This is not optional for most organizations. If you are giving an LLM agent the ability to create services, modify catalog entries, or inspect Kubernetes clusters through Backstage, you need an audit trail. v1.54.0 provides it out of the box.

MCP servers can also be configured with instructions for both default and named servers, which means platform teams can scope what different agents are allowed to see and do. A coding assistant in an IDE might get read-only catalog access, while an infrastructure automation agent might get scaffolder execution rights. The configuration granularity lets teams adopt agent integration incrementally rather than opening the entire portal at once.

Agent-Friendly Catalog Refresh: No More Waiting for Polling Loops

Before v1.54.0, if a scaffolder run created or updated a catalog entity, the only way to read back the fresh data was to wait for the catalog’s scheduled processing loop. That loop might run every few minutes. For a human waiting in the browser, that is acceptable. For an agent that needs to verify a service was created successfully before moving on to the next step in a multi-step workflow, it is a bottleneck.

The new refresh-catalog-entity action in @backstage/plugin-catalog-backend solves this. After creating or updating an entity, an agent can re-queue it for immediate processing and then read back the fresh catalog data without waiting for the next scheduled loop. This makes Backstage viable for programmatic workflows that previously required awkward polling or optimistic assumptions.

For platform teams building internal agents that orchestrate service lifecycles—create the repo, register it in Backstage, provision infrastructure, and notify the owning team—this action removes a common source of race conditions and timeout logic.

Catalog Reliability: Diffs, Deadlocks, and Resilience

Behind the MCP and agent features, the catalog backend received a set of under-the-hood improvements that matter at scale. The biggest is relation sync by diff. Previously, when an entity’s relations changed, the catalog backend deleted all existing relation rows and reinserted them. On a busy catalog with thousands of entities, this generated unnecessary writes, dead tuples, WAL traffic, and downstream stitching work for entities whose relations had not actually changed.

v1.54.0 now applies only the diff of changed rows. In steady state, most entities see no relation changes between processing cycles, so the backend skips the write entirely. For large Backstage deployments—Spotify runs tens of thousands of entities—the reduction in database churn is meaningful.

The release also adds automatic retry on PostgreSQL deadlocks for entity provider mutations and on MySQL for concurrent entity processing. SCM location.moved events are now ignored for files that are not actively tracked, preventing spurious catalog entries from being created when repositories are reorganized. These are production-hardening fixes that keep Backstage stable as the catalog grows.

Kubernetes Audit Logging and API Proxy Improvements

The Kubernetes plugin backend now emits auditor events for cluster list, cluster proxy, entity workload, custom resource, and deprecated services endpoint requests. Administrators can filter by event IDs like cluster-fetch and resource-fetch, as well as by query type metadata. This gives teams visibility into who—and now what—is accessing cluster data through Backstage.

The Kubernetes API proxy also gained cache refresh logic that triggers when cluster details change, after a configurable TTL, or when the cache reaches its size limit. It warns at startup for clusters configured with skipTLSVerify: true, which is a nudge toward proper certificate management. These improvements make the Kubernetes plugin more operationally sound for production clusters.

Stable System Metadata and Configuration Validation

coreServices.rootSystemMetadata graduated from experimental to stable. This service exposes metadata about the running Backstage system, including installed plugins, which enables the internal OpenAPI documentation provider to discover plugins automatically. For teams building dynamic Backstage experiences or plugin registries, this removes the need to manually enumerate what is installed.

Configuration schema validation also got stricter. Package preparation now validates TypeScript configuration schemas before publishing, and the --strict flag for backstage-cli config:check treats schema errors as fatal. The config loader adds an onSchemaError callback so callers can report errors and continue loading where appropriate. For large Backstage instances with dozens of plugins, stricter validation catches misconfigurations earlier and with clearer error messages.

Authentication Hardening

Not every change in v1.54.0 is additive. The OAuth redirect URI allowlist matching in @backstage/plugin-auth-backend became stricter. Patterns now match URL components separately instead of against the full string. Wildcards no longer cross host and path boundaries, and redirect URIs with embedded credentials are always rejected. A pattern like http://localhost:* now only matches the root path; you need http://localhost:*/* for any path. This closes a class of misconfiguration vulnerabilities where overly broad patterns allowed unintended redirects.

The deprecated config.schema option for extensions was also removed. Extensions must now use the top-level configSchema option with Standard Schema-compatible values like Zod v4. For teams upgrading from older Backstage versions, this is a breaking change that requires migration.

What to Watch When Enabling Agents

Adding MCP support to Backstage is straightforward from a technical perspective: install the plugin, configure the servers, and expose the tools. The harder part is operational. Every tool an agent can invoke is a potential automated action at scale. A human running a scaffolder template twice in five minutes is unusual. An agent doing it a hundred times is a Tuesday afternoon.

Platform teams should start with read-only catalog access and gradually expand agent permissions. Use the audit logging to understand agent behavior before granting write access. Define clear scope boundaries for different agent types—coding assistants, infrastructure automation, compliance scanners—and configure MCP server instructions to match. Monitor the Kubernetes audit events to ensure agents are not hammering cluster APIs.

The agent-friendly catalog refresh is a powerful primitive, but it increases catalog processing load if used heavily. Teams should monitor catalog queue depth and database performance after enabling it for programmatic workflows.

The Larger Shift

Developer portals have always been about centralizing knowledge and standardizing workflows. Backstage v1.54.0 extends that mission to agents. The implications are significant: the same catalog that tells a human engineer which team owns a service can now inform an AI agent that needs to route an incident or suggest a remediation. The same scaffolder that creates a new microservice for a human can now provision infrastructure in response to an automated trigger.

For platform engineering teams, this means Backstage is becoming more than a portal. It is becoming an operational API for the entire engineering platform. The question is no longer whether to adopt Backstage for human developers. It is whether your agent infrastructure can afford not to have a Backstage-shaped control plane.