The ForgeBridge MCP server: one tool surface over stdio and streamable HTTP, speaking the daemon's /v1 REST surface.
ForgeBridge MCP server demonstrates strong naming conventions (verb_noun pattern: list_projects, read_tree, start_run, apply_changeset) and exceptionally detailed descriptions (200-400+ chars each) that explain WHAT, WHEN, and WHY. All 12 tools have clear, non-trivial descriptions addressing prerequisites, state changes, and approval workflows. However, critical gaps exist: NO visible input schemas in the provided source code (packages/mcp/src/tools.ts referenced but not shown), NO parameter descriptions for any tool, and NO documented output schemas. The descriptions are LLM-optimized and address safety concerns (e.g., 'No tool on this server can approve a ChangeSet'), but without schemas and parameter docs, agents cannot validate inputs or plan downstream calls. Tool composition is excellent (single responsibility, clear chains: list_projects → start_run → apply_changeset), and naming disambiguates similar operations (propose_changeset vs start_run, apply_changeset vs rollback). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present but not formalized as tool annotations in the visible code.
Apply a ChangeSet to a project: queue it for the paired Studio session to execute. This is the only tool that changes the place. It refuses if the ChangeSet is not approved. Approval is a human action. No tool on this server can approve a ChangeSet, and this server never calls the daemon's approve endpoint (ADR-012). After this call, the ChangeSet is in flight: the Studio session will execute it, and the result will be recorded in the journal. Poll forge.tail_output or wait for a webhook to learn when it completes.
Read a ChangeSet's diff: the operations it would perform, rendered as a human-readable summary. Use this to help the user review a ChangeSet before they approve it. The diff is computed by the daemon and cached; this call does not recompute it.
List the Roblox projects this ForgeBridge daemon knows about, which project it treats as the default, and whether a Roblox Studio session is paired with each. Start here: every other tool needs a project id, and nothing can be applied to a project with no paired Studio session.
Propose a ChangeSet you have written yourself, and get back the daemon's validation verdict. This VALIDATES and RECORDS a proposal. It does NOT change the place, it does not queue anything for Studio, and the ChangeSet it returns is in status "validated" — never approved. Approval is a human action. No tool on this server can approve a ChangeSet, and this server never calls the daemon's approve endpoint (ADR-012). After this call, report the changeset id, the summary and the validation verdict to the user, and ask them to review and approve it. forge.apply_changeset will refuse until they have.
NO input schemas visible in source code. All 12 tools reference Input: {} but actual schema definitions not provided. Cannot verify parameter types, constraints, or descriptions.
NO parameter descriptions documented. Tools like start_run, propose_changeset, apply_changeset, and rollback accept parameters (project_id, changeset_id, etc. inferred from descriptions) but no parameter-level documentation visible. LLMs cannot infer parameter meaning from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Read a ChangeSet: its operations, its status, and its validation verdict. Use this to inspect a ChangeSet before you apply it, or to understand why the daemon refused it.
Read the journal of a project: the history of every ChangeSet applied and every rollback executed. Use this to understand what has happened to a place, and to find the id of a ChangeSet you want to roll back.
Read the current source of one script instance. NOT AVAILABLE over the local daemon transport, for the same reason as forge.read_tree: there is no tree snapshot behind /v1 yet (M09/M31). Every call returns not_found. Ask the user to paste the source you need to modify — do not guess at it and do not propose a writeScript that assumes what is already there.
Read the instance tree of a project. NOT AVAILABLE over the local daemon transport: the daemon holds no tree snapshot, and no /v1 endpoint serves one yet (M09 gives the snapshot to @forgebridge/core; M31 agrees the endpoint). Every call returns not_found and says so. Ask the user for the paths you need, or infer them from a diff.
Reverse a ChangeSet that was already applied. This is the only tool that undoes work. It refuses if the rollback is not cleared by a human. Clearing a rollback is a human action. No tool on this server can clear one, and a clearance covers one journal entry only — the user approving a ChangeSet is not the user agreeing to reverse a different apply (ADR-012). After this call, the rollback is in flight: the Studio session will execute it, and the result will be recorded in the journal. Poll forge.tail_output or wait for a webhook to learn when it completes.
Run the test suite of a project and stream the results. This is a long-poll: the call blocks until output arrives or the timeout expires. Use this to validate that a ChangeSet did not break anything.
Hand a prompt to the model this ForgeBridge daemon routes to, and get back a ChangeSet it proposed, already validated by the daemon. Use this when the user wants something built and you would rather the daemon's own model write the operations; use forge.propose_changeset instead when you have written the operations yourself. This VALIDATES and RECORDS a proposal. It does NOT change the place, it does not queue anything for Studio, and the ChangeSet it returns is in status "validated" — never approved. Approval is a human action. No tool on this server can approve a ChangeSet, and this server never calls the daemon's approve endpoint (ADR-012). The result carries `run.attempts`: every model the router tried, in order, with why it moved on. Report that list to the user as it stands. The code in the ChangeSet was written by the model named in the last ok attempt, which may not be the one anybody asked for, and describing it as your own work or as the first model's would be a false statement about who wrote it. After this call, report the changeset id, the summary and the attempt list to the user, and ask them to review and approve it. forge.apply_changeset will refuse until they have.
Stream the console output of a ChangeSet or rollback as it executes. This is a long-poll: the call blocks until output arrives or the timeout expires. Use this to show the user what is happening in Studio as their work runs.
NO output schemas documented. Descriptions mention return values (ChangeSet, validation verdict, diff, journal entries) but no structured schema for response fields. Agents cannot plan downstream calls or extract required IDs.
Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) present in metadata but not formalized as MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot programmatically detect which tools are safe to retry or have side effects.
Error handling guidance missing. Descriptions mention 'refuses if' conditions (e.g., apply_changeset refuses if ChangeSet not approved) but no documented error responses, error codes, or recovery guidance. Agents cannot self-correct on failure.