EPIC Goal

Implement additional Model Context Protocol (MCP) Server actions for the Backstage Scaffolder. By exposing additional Scaffolder capabilities—such as action discovery, template validation (dry-run), execution, and log retrieval—as standardized MCP Tools, we enable agentic IDEs (e.g., Cursor, Claude Code) to interact directly with the Scaffolder backend. This allows developers to author, test, and run templates securely "on behalf of" their user identity, directly from their coding environment.

Requirements (aka. Acceptance Criteria)
1. Tool: List Registered Scaffolder Actions

Given an MCP client requests available capabilities, When the tool scaffolder_list_actions is invoked, Then return a comprehensive list of all installed Scaffolder actions. And include the input schema for each action so the AI client understands required parameters and types.

2. Tool: Browse Custom Template Fields

Given a user is configuring a template and needs to know available UI options, When the tool scaffolder_list_custom_fields is invoked, Then return the list of fields available (equivalent to the /create/custom-fields endpoint) and their YAML specifications.

3. Tool: Verify / Dry-Run A Template

Given a user has written a template definition in their IDE, When they invoke the scaffolder_validate tool with the YAML content, Then the backend must process the template logic (without side effects) to verify structure and syntax. And return a success message or specific validation errors.

4. Tool: Execute Template (Secure OBOU)

Given a user wishes to run a template from their IDE, When the tool scaffolder_execute is invoked with a template ref and parameters, Then the execution must occur using the user's specific Bearer token (passed via the MCP session or headers). And the system must return a taskId for tracking.

5. Tool: List and Monitor Execution Tasks

Given a user has triggered a run, When the tool scaffolder_list_runs is invoked,
Then return a list of recent tasks performed by that specific user. When the tool scaffolder_get_task is invoked with a taskId, Then return the simplified list of milestones/steps reached (e.g., "Step 1: Fetching code - Completed").

6. Tool: View Template Logs

Given a task has completed (or failed), When the tool scaffolder_get_logs is invoked with a taskId, Then return the log stream for that execution to assist with debugging.

Background/Feature Origin

upstream issue: https://github.com/backstage/backstage/issues/31755

Why is this important?

User Scenarios

Platform Engineers: This feature is critical for the "Inner Loop" of template development. They are the primary persona for the "Dry Run" and "Action Discovery" tools.

Security: Ensure that the MCP server implementation enforces the same permissions model as the web UI. If a user cannot run a template in RHDH, they must not be able to run it via MCP.

Dependencies (internal and external)

Acceptance Criteria

See requirements in goals

Release Enablement/Demo - Provide necessary release enablement details
and documents

DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
Issue>

DEV - Upstream documentation merged: <link to meaningful PR or GitHub
Issue>

DEV - Downstream build attached to advisory: <link to errata>

QE - Test plans in Playwright: <link or reference to playwright>

QE - Automated tests merged: <link or reference to automated tests>

DOC - Downstream documentation merged: <link to meaningful PR>