🔎 Search Terms

ActionsRegistry, MCP, Distributed Actions, Scaffolder, ModelContextProtocol

🔖 Need

Model Context Protocol (MCP) is a fast moving space right now, and there’s a need to enable different MCP tools that provide access to different information and data which is surfaced through plugins in Backstage.

While MCP tools are useful on their own, there is also an opportunity to align this work with the broader Backstage framework rather than having MCP be bolted on. In many cases we expect Software Template Actions to be more or less identical to their MCP tool counterparts. Consider examples like registering a new component in the Software Catalog, paging the owner of an Entity, or opening a Pull Request; these all have potential to provide value both as actions in a Software Template, and as MCP tools.

Another related area is the opportunity to simplify the installation of Scaffolder actions. Today each action needs to be installed as a module for the scaffolder, meaning that they need to be published in their own package separately from what might be the main plugin backend package. There is room for improvement here, where we instead only need to install a single package to both provide the base functionality of the plugin and actions related to the plugin.

📝 Proposal

We propose the ability for plugins to define actions without the need to install a module for the Scaffolder. This means that we need to provide APIs for plugins to use to define actions that would then later be able to be invoked from other plugins.

Actions Registry

For this, we’ve started iteration on an ActionsRegistryService and ActionsService, which would be part of the Core Services that are shipped out the box in Backstage. These allow plugins to define actions with a very similar API to the Scaffolder actions, but effectively these become distributed and installed with the plugins themselves.
The ActionsService is a client on top of all these actions that are defined in the ActionsRegistry, allowing a plugin author to list the available actions and invoke them.

MCP Integration

We will provide an MCP server on top of the ActionsRegistryService and ActionsService in order to map the available actions as tools for a server, and invoke them. This will be the first step in bringing MCP integration to Backstage, with a focus on simplicity and a lightweight integration.

In order to allow for flexibility in the MCP servers available to end users, it will be configurable to allow for creation of multiple MCP servers, each with their own list of integrated actions. This makes it possible to configure what exact actions an integrator wants to expose as MCP tools. The goal of this is to be able to provide different servers for specific context to end users, in order to let the user steer execution and avoid confusion between similar servers by only enabling the ones that are relevant for a specific task.

This MCP server would implement both the Streamable specification, with sessions stored in the DatabaseService, and the legacy SSE variant for backwards compatibility with older clients. We expect the SSE implementation to be deprecated from the initial implementation, and should be avoided if possible.

We expect actions registered in the ActionsRegistry to have sufficient descriptions and metadata for them to be usable as MCP tools directly. This means that we will recommend excessively verbose descriptions compared to what you might expect for only human consumption. In practice we’ve found that this is more often a benefit to the humans rather than the other way around, as the more verbose descriptions will help them too.

As a starting point, we aim to ship a few actions from the catalog-backend plugin that will give clients the ability to interact with the Software Catalog. This will allow LLMs to be able to parse data out of the Software Catalog, leading to other tools built on top of this data pretty easily.

In the future it’s possible that we will ship an mcp-node package, with frameworks and APIs there to help you create MCP servers and not have to worry about implementing things like Authentication and the Transport protocols, just the implementation of what is surfaced by the MCP server itself. We expect organizations to have a myriad of MCP servers both within and outside of Backstage, along with the tooling necessary to manage these servers in a scalable way. We therefore don’t expect a potential sprawl of MCP servers from individual plugins to add significant friction compared to if we aimed to manage them through the framework.

Authentication for MCP Servers and therefore tools is very much a moving target right now. Our intention is to ship the MCP backend initially with the default Backstage Token Authentication, with Device Authentication for Backstage becoming very much a priority in order to make authentication with Backstage MCP Servers as smooth as possible.

This integration focuses on simplicity and the implementation of small single purpose tools. We still see that there might be a need for a more advanced MCP server in the Backstage Ecosystem, utilizing things such as Resources and Prompts, but will hold off on building those types of integrations while we wait for the MCP space to mature.

🔄 Alternatives

We could skip the ActionsRegistry and the distributed actions concept as a whole. But this would lead to tools being defined in MCP servers not being available for use by the broader Backstage plugin ecosystem such as the Scaffolder. We do also see distributed actions as a big benefit to the Scaffolder alone as it makes it much easier for plugins to provide their own actions. We think it would be a mistake to not at the same time also make these actions available as MCP tools.

We could also look at just focusing on immediately making it easier from a framework level to make your own individual MCP Servers, i.e. implementing mcp-node much sooner. The thinking here is that the MCP spec is moving very fast, and we’d rather wait for the dust to settle around authentication and some of the other features of MCP, and just focus on the tool parts for now which benefits more of the Backstage plugin ecosystem.