servers / forge-engine
Forge Engine MCP server
communitystreamable_httpremotedestructive capablehealthy
Design source-of-truth for AI coding agents to read a project's systems and propose changes back.
01Tools · 45
How to read this: tool names here are observed from a live tools/list handshake. The Risk label is a heuristic inferred from the tool name (write/destructive verbs), not from executing the tool — a conservative guess, not a verified capability. We never escalate risk from a description. Found one that's wrong? Tell us — we fix on report.
| Tool | Risk | Side effects | Approval |
|---|---|---|---|
| update_element Move / resize / relabel / retype an EXISTING element in place — applies DIRECTLY (live; safe & reversible — the content was already adopted; don't delete+re-propose). Identify by `element_id` (from get_screen; preferred) or `screen`+`label` (label must be unique on that screen). Passing x+y also pulls an unplaced ('to place') element onto the canvas. | write | true | unknown |
| withdraw_proposal Withdraw YOUR OWN still-pending Inbox item (a propose_* / delete_entity you made by mistake) — removes it before the owner adopts. Pass the `id` from the propose call's response or get_inbox. Only items you authored and only while pending. | unknown | unknown | unknown |
| delete_entity PROPOSE deleting ONE design entity → Forge Inbox; the OWNER adopts to perform it (nothing is deleted immediately). kind = system | context | screen | milestone | task | element | flow_edge. Identify by `id` (preferred — task/element/edge ids go here too) or exact `name`; a flow_edge may instead use `from`+`to` screen names. A system's response includes its blast radius. | destructive | true | true |
| dedupe Remove DUPLICATE entries, keeping the first of each — applies DIRECTLY (destructive). kind=milestones (duplicate-named milestones) or elements (duplicate-labelled elements on `screen`). | unknown | unknown | unknown |
| reorder Reorder milestones, a milestone's tasks, or a screen's elements — applies DIRECTLY (safe & reversible). `order` = ids in the new order (milestone names also work); omitted entries keep their relative order at the end. kind=tasks also needs milestone_id/milestone; kind=elements also needs screen. | unknown | unknown | unknown |
| list_milestones List the project's milestones COMPACTLY — id, name, week estimate, order, and task counts (done/total) only, no goals or task names. Tiny payload: use this to browse the plan or grab a milestone id WITHOUT pulling the whole project (get_project_context can be large). Drill into one with get_milestone. | read | false | unknown |
| get_milestone Get ONE milestone's full detail by id (preferred) or exact name — goal, week estimate, difficulty, the systems it builds, and every task (id / name / done, plus optional status & effort). Use after list_milestones to read a specific milestone without pulling the whole project. | read | false | unknown |
| list_activity The project's CHANGE HISTORY — compact rows {who, change, entity, kind, when}, newest first; filter by kind / who / query (keyword). Answers 'what changed recently / who touched X'. (For who's building what RIGHT NOW, read `claims` in get_project_meta.) | read | false | unknown |
| get_inbox List the project's PENDING Inbox items — the same triage queue the owner sees: proposals not yet adopted (discovered systems, new milestones, Intent updates, reported task progress, screen status, proposed UI elements / flow links). Call this BEFORE proposing so you don't duplicate something already waiting (proposing is write-only otherwise). Read-only — the owner adopts/flags in Forge; you cannot adopt. | read | false | unknown |
| search Keyword search across the project (case-insensitive) — find a milestone, task, system, screen, context section, or open question (and its id) without scanning the whole context. Returns compact hits {kind, id, name, …} with a snippet for body matches. Optionally limit with `kinds`. | read | false | unknown |
| propose_system Propose a NEW system spec → Inbox (non-destructive; the owner adopts). spec = ## Goal / ## Boundary (Owns · Doesn't own) / ## Acceptance, consistent with existing systems. Check list_systems/search first — if it already exists, use update_system instead. (Alias: create_proposal.) | read | false | unknown |
| propose_context Propose a new/updated Context (Idea) note → Inbox. Title-matches an existing section (shows as a diff) or adds a new note. Use when the build changes something the upstream idea should reflect — keeps the source-of-truth in sync. Send the complete revised text, not a delta. Non-destructive. | unknown | unknown | unknown |
| propose_dna Propose the Project DNA (north star: what it is · who it's for · pillars · non-goals) and/or Tech Notes (stack, key libraries, database, infra, constraints) → Inbox to Adopt. At least one of `dna` / `tech_notes` required. Non-destructive. | unknown | unknown | unknown |
| update_system Propose an UPDATE to an existing system → Inbox as a reviewable diff (owner adopts). Read get_system first, then send the FULL revised spec. `new_title` renames in the same card. If the upstream idea shifted too, pass `context_title`+`context` to bundle that update. Non-destructive. | write | true | unknown |
| get_balance Read the project's Balance Lab: stat-doc TABLES (schema = per-column stat definitions, rows = the entities), node BOARDS with EVALUATED values (sheets, loadouts, pools, process odds — same engine as the web), and saved scenarios. Use it to reason about game balance before proposing changes. | read | false | unknown |
| propose_balance_table Propose a Balance Lab stat-doc TABLE (an entity catalog: Weapons, Monsters, Skills…) → Inbox to Adopt. Pass `csv` (header row; `key%` marks a percent value column; first column doubles as name) OR `schema`+`rows` JSON. Generated/drafted stat docs land here for review — never a silent write. Adopting REPLACES a same-named table (re-propose = update). | unknown | unknown | unknown |
| propose_balance_board Propose a Balance Lab BOARD (a node canvas) → Inbox to Adopt. `nodes` = blocks {kind: const|formula|item|sheet|loadout|picker|pool|process|note|frame, name, …kind fields}; formulas reference other blocks by NAME (name-magic). Omit x/y and the server auto-layouts topologically. Adopting REPLACES a same-named board. | unknown | unknown | unknown |
| propose_milestone Propose a NEW milestone (with optional tasks) → Inbox to Adopt. Non-destructive. | unknown | unknown | unknown |
| report_milestone_progress Mark tasks of an EXISTING milestone as done (e.g. work already finished) → Inbox progress card to Adopt (ticks them). Use exact milestone + task names from get_project_context. Non-destructive. | unknown | unknown | unknown |
| update_milestone Edit a milestone's goal / weeks / difficulty / name IN PLACE — applies DIRECTLY (live). Use `new_name` to RENAME (never delete+recreate — that mints a new id). Identify by id (preferred) or exact unique name. | write | true | unknown |
| add_task Add a task to an existing milestone — applies DIRECTLY (in place, not a proposal). Identify the milestone by id (preferred) or unique name. Pass assignee:"me" to claim it as you create it. | write | true | unknown |
| update_task Edit a task (name / done / status / effort) or CLAIM it (assignee) by task id — applies DIRECTLY. CLAIM before you build: assignee:"me" + status:"in-progress" marks the task yours (listed in get_project_meta claims, so others don't collide); it ERRORS if someone else holds it — override a stale claim with force:true. done:true (or assignee:"") releases the claim. (To report progress for human review instead, use report_milestone_progress.) | write | true | unknown |
| post_log Append a build-log entry to the project's Activity feed — record what you built / a key decision / where you diverged (like a commit note), so the team + the design can see your work. Non-destructive, attributed to you. Use as you work (the milestone tick is report_milestone_progress; this is the narrative). | write | true | unknown |
| get_project_context FULL design dump — LARGE (often exceeds the token cap on a real project). NOT the entry point: orient with get_project_meta, browse with list_*, drill in with get_system / get_milestone / get_screen, or jump to a thing with search. Use only when you truly need everything at once. | read | false | unknown |
| list_projects List the Forge projects YOU can access (with an account key) — each with id, name, and your role. Use this to discover which project to work on, then pass its id as `project_id` to any tool to switch (no need to re-add the connector). A project-scoped key returns just its one project. | read | false | unknown |
| get_project_meta START HERE. Tiny project overview — id, name, version, last-updated, members, entity counts, current task `claims` (who is building what right now — check before you start), and forge_workflow_version. Then browse with list_* and drill in with get_* — far cheaper than get_project_context. | read | false | unknown |
| get_system Get ONE system's full spec by name (Goal / Boundary / Acceptance + the raw markdown + sources + status). Use after get_project_context to read a specific system in detail without pulling the whole project. | read | false | unknown |
| list_systems List the project's systems COMPACTLY — id, name, status, and a 1-line goal only (no full Goal/Boundary/Acceptance). Tiny payload: browse systems or grab an id WITHOUT pulling the whole project. Drill into one with get_system. | read | false | unknown |
| report_drift Flag CODE DRIFT on a system — its system→code map (from get_build_region) no longer matches the repo: mapped files deleted, moved, or rewritten away from the spec. Advisory only (blocks nothing): the flag shows on the owner's Dashboard and in get_build_region until someone re-maps the system with a fresh report_build_status (which clears it). Pass the stale paths in `missing_files` (+ optional `note` for drift that isn't a missing file). | unknown | unknown | unknown |
| get_history DESIGN MEMORY — the recorded WHY. Queries the project's accumulated history: build decisions (report_build_status `decisions`), activity/log entries, owner rejections, and spec changelogs — every entry carries source/who/when so answers can CITE real records. Call it BEFORE changing a system's direction ("why is it designed this way?"). An empty result means there IS no recorded decision — say so, never invent a rationale. Filter by `system` (id or exact name) and/or `query` keyword. | read | false | unknown |
| get_rejections The DECLINED list — check at session START. Each entry = your build diverged from the owner's design; follow its `guidance` (revert to the kept spec / drop the out-of-scope thing / don't delete what they kept), then call resolve_rejection(title). Resolved items drop off automatically. | read | false | unknown |
| get_help How to use Forge well (no project needed) — the propose→adopt flow, that proposals/deletes are PENDING until the owner adopts on the web, what counts as a System (vs code infra), token-efficient reading, and sign-in/billing. Call this when unsure how something works or when the user asks. | read | false | unknown |
| get_workflow Run this FIRST on a new repo/session (no project needed). Returns: (1) a first-connect greeting routine (read project status + Inbox, tell the user), and (2) the 'Forge working agreement' block for the repo's AGENTS.md / CLAUDE.md so EVERY future session keeps using Forge (read design before building, report progress, propose discoveries, log work). ADD the block for the user right away (create/replace; tell them in one line; remove it if they object) — don't wait to be asked. | read | false | unknown |
| import_from_code ONE-COMMAND import of an EXISTING codebase — run when the user wants Forge to reflect their code. Returns the full recipe + a batch id: you read the repo and propose one Context overview + one System per real module (all batch-tagged; the owner adopts the import in one click). Reflects only what EXISTS today; non-destructive. | read | false | unknown |
| design_ui_from_systems ONE-PASS recipe to design the UI from the spec'd Systems — run when the user asks to generate screens / flow / a prototype. Returns the full recipe + a batch id: confirm the canvas aspect FIRST, then propose screens + PLACED elements (x/y/w/h) + pop-ups + flow edges in one batch; the owner adopts the whole UI at once. Non-destructive. | read | false | unknown |
| get_build_region The system→code MAP: for each system that's been built, the files that implement it + its build status (todo | in-progress | implemented) — fed by report_build_status. Use it to find WHERE a system lives in the codebase before you edit it (so you change the right files), or to see what's already built. VERIFY as you use it: if mapped files no longer exist in the repo (deleted/moved), call report_drift on that system so the map can't rot. Includes any `drift` flag. Only returns systems with a status, files, or drift; empty if nothing has been reported yet. | read | false | unknown |
| resolve_rejection Tell the owner you've REVERTED a declined change (from get_rejections) — your build now matches the design again. Pass the rejection's `title`. This unlocks the owner's 'Clear' button for that item (they verify, then remove it); without it the item stays open. Call it right after you bring the build back in line. | unknown | unknown | unknown |
| list_screens List the project's screens COMPACTLY — id, name, 1-line purpose, and build status. Tiny payload: browse screens or grab an id without pulling the whole project. | read | false | unknown |
| get_screen ONE screen's full layout — kind (screen/popup + parent), purpose, canvas `resolution` (place coords on THIS, don't assume 1920×1080), reference-image flag, every element (id/label/type/x/y/w/h/placed), its flow links, and its popups. The ONLY compact way to read a layout (even get_project_context omits element positions). Read this before update_element or adding onto an existing screen. | read | false | unknown |
| report_build_status Report how far a SYSTEM is built — live badge (todo | in-progress | implemented), shows immediately (NOT an Inbox item). ALWAYS pass `files` = the paths that implement it (the system→code map; re-send the full list — it replaces): a non-todo system with no files shows done-but-EMPTY to the owner. `decisions` = prose notes (never in files). | read | false | unknown |
| propose_flow_edge SECONDARY (user-driven UI — not the core build loop; only when the USER wants to map screen flow). Propose a navigation link between two EXISTING screens (screen → screen) → Inbox to Adopt. Use screen names from get_project_context. Non-destructive (connection only, no layout). | unknown | unknown | unknown |
| propose_element SECONDARY (user-driven UI). Propose a UI element onto a screen → Inbox to Adopt. The screen may be adopted OR still pending from this batch (they adopt together). ALWAYS pass x/y/w/h — px on the SCREEN'S canvas (`resolution` from get_screen; for a new set confirm the aspect with the user, don't assume 1920×1080 landscape). Omitting coords dumps it in an unplaced pile the human must hand-arrange. `system` = the System it serves; `note` = designer note. Non-destructive. | unknown | unknown | unknown |
| propose_screen SECONDARY (user-driven UI). Propose a NEW screen (a HUD + its flow node) → Inbox to Adopt. `parent` makes it a POPUP overlaying that screen; `purpose` (one line) grounds later element suggestions. Generating a whole UI? Run design_ui_from_systems first — elements/edges may reference still-pending screens from the same batch and adopt together. Non-destructive. | unknown | unknown | unknown |
| report_screen_status Report a SCREEN's build status (todo | in-progress | implemented) → Inbox for the owner to Adopt onto the System Flow node. Use as you build out a screen. Identify the screen by name (from list_screens / get_project_context). Non-destructive — the owner adopts it. | read | false | unknown |
| rename_screen Rename an existing screen IN PLACE — applies DIRECTLY to the design (live; not a proposal; safe & reversible). Flow links + elements follow automatically (they reference the screen by id, not name). Identify it by its current name. Use names from list_screens / get_project_context. | write | true | unknown |
02Install & source
https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp
remote_url- repohttps://github.com/alongkornonline2019/forge-mcp
- homepagehttps://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp
- adoption0 stars · 0 forks
03Access granted
Manage tasks & tickets · write
The access this server can exercise, inferred from its verified tools — not a declared OAuth scope.
05Provenance & freshness
sourcesOfficial MCP Registry [p1]
last_checked2026-07-09 09:10Z
next_check2026-07-10 13:58Z
cadenceevery 29h
verifiedtools_list:passed handshake:passed metadata:passed
index_statusindex — 8 unique facts >= 5
06Badge
Add the “as seen on MCPExplorer” badge to your README. 
[](https://mcpexplorer.com/servers/forge-engine)
Next step
This is one server. A loadout combines the right servers, governance, and proven plays for a whole job — assembled deliberately, not tool-dumped.
Explore loadouts →