# Forge Engine (remote · mmvdabzadclebfxyzudg.supabase.co)

Design spec + milestones AI coding agents read before building; drift flagged, changes reviewed.

- Trust score: 80/100 (high trust)
- Change this week: +9
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mmvdabzadclebfxyzudg.supabase.co`: 80/100 (this document), [markdown](https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp.md), [page](https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp)

## Channel facts

- Endpoint: `https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.2.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 94/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 71/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 5539 tokens (~102/item across 54 items; 54 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 90/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 69% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http app-forgeengine-forge https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp
```

### Codex

```toml
[mcp_servers.app-forgeengine-forge]
url = "https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "app-forgeengine-forge": {
      "type": "remote",
      "url": "https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add app-forgeengine-forge --url https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  app-forgeengine-forge:
    url: "https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp"
```

### Other

```json
{
  "mcpServers": {
    "app-forgeengine-forge": {
      "type": "http",
      "url": "https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 78, +5)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 71, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 71)

First indexed and scored.

## MCP tools (54)

### `get_help` (~39 tokens)

Forge how-to on demand (no project needed): propose→adopt, what a System is, Balance Lab formats, sign-in. Call when unsure.

### `get_workflow` (~53 tokens)

Run FIRST in a new repo (no project): first-connect routine + the working-agreement block to ADD to AGENTS.md/CLAUDE.md now (tell the user in one line; remove if they object).

### `import_from_code` (~46 tokens)

One-command codebase import: recipe + batch id — propose one Context overview + one System per real module; the owner adopts all at once.

Input parameters:

- `project_id` (string)

### `design_ui_from_systems` (~53 tokens)

Recipe to design the UI from Systems (user request only): steps + batch id — confirm canvas aspect, then screens + PLACED elements + edges in one batch.

Input parameters:

- `project_id` (string)

### `post_log` (~83 tokens)

Append a build-log entry to Activity — what you built/decided (commit-note style).

Input parameters:

- `entity` (string): System/screen/milestone it's about
- `project_id` (string)
- `text` (string, required): What you did / decided (1–2 sentences)
- `version` (string): e.g. "0.379.0"

### `get_project_context` (~39 tokens)

FULL design dump — LARGE, last resort; prefer get_project_meta + list_*/get_*/search.

Input parameters:

- `project_id` (string)

### `list_projects` (~28 tokens)

Projects your key reaches (id, name, role); pass an id as project_id to switch.

### `get_project_meta` (~41 tokens)

START HERE. Tiny overview: counts, members, task claims + working_now (avoid collisions), forge_workflow_version.

Input parameters:

- `project_id` (string)

### `trace_ui_from_image` (~139 tokens)

SECONDARY (user-driven UI): turn a screen's REFERENCE IMAGE into placed elements. Returns the image itself plus the recipe — the canvas resolution, the fraction→pixel conversion that stops coordinates landing wrong, and what is already on the screen so a second pass updates instead of duplicating. You look at the picture and send back propose_element / update_element with x/y/w/h; it all lands in the owner's Inbox. Use when the user wants the wireframe to match a screenshot or mockup they uploaded.

Input parameters:

- `project_id` (string)
- `screen` (string, required): The screen whose reference image to trace (name or id)

### `get_stale` (~110 tokens)

What has drifted between the Idea lane and the System Specs — the design's own out-of-sync list, computed deterministically (no AI, no tokens). Three kinds: Idea notes edited since the systems were generated from them (with the systems each one touches), Idea notes whose prose the systems have moved past, and specs whose stamped source fingerprint no longer matches. Read this before assuming the design is coherent; fix the first kind with resync_from_idea.

Input parameters:

- `project_id` (string)

### `resync_from_idea` (~137 tokens)

The recipe for re-syncing ONE changed Idea note into the specs that depend on it — the same scoped job the app's "Re-sync N systems" button does, minus the button. Returns the note, the affected specs in full, and exactly how to send the result back. You do the writing; it lands in the owner's Inbox to ADOPT. CRUCIAL: send updates with `resync:true`, or the owner adopts your fix and the design still reports it as stale.

Input parameters:

- `note` (string, required): The Idea note's title or id (from get_stale)
- `project_id` (string)

### `get_design_document` (~205 tokens)

The WHOLE design as one readable document — Vision (+ Project DNA) → every System spec → reference notes, compiled deterministically from the current design. Read this to understand a project end-to-end instead of walking list_systems → get_system N times. Returns markdown plus the project `version` it was compiled from. Long designs come back PAGED — the header says 'part N of M', call again with `page: N+1` for the rest. Pass `for_summary: true` to get the condensed projection instead (every system's Goal + Boundary, tables stripped, one page) — that is what you should summarize from.

Input parameters:

- `for_summary` (boolean): Return the condensed summarization source (all system goals + boundaries, no tables) instead of the full document
- `page` (number): Which part of the full document to return (default 1). The header tells you how many parts there are.
- `project_id` (string)

### `set_design_overview` (~229 tokens)

Write the Design Document's Overview — the human-readable page a new team member reads first. WRITES DIRECTLY (no Inbox): it is a derived, clearly-labelled AI summary, not design truth, and the owner can clear or rewrite it in one click. HARD RULES, same as the in-app button: use ONLY facts stated in the design (call get_design_document with for_summary:true first); invent no mechanics, numbers or names; describe, never evaluate; write in the design's dominant language. Structure: `### What this is` · `### The core loop` · `### How the systems fit` (which system feeds which — the part a raw spec list cannot give) · `### Edges` (ONLY if the design states scope limits / open questions). 250-400 words, no top-level heading. Forge stamps the project version it was compiled from, so the owner is told when the design has moved past it.

Input parameters:

- `project_id` (string)
- `summary` (string, required): The Overview in markdown, starting at `### What this is`

### `get_briefing` (~167 tokens)

ONE-CALL orientation before you build: pass `files` you're about to edit (or a `task`) → the systems that own them, each with Goal + Acceptance + build status/files/last_commit/drift + coupled_systems (code neighbors an edit may break) + pending Inbox changes + recent decisions, plus open-rejection count, who's active, `recent_changes` (what happened since you were last here — a session handoff), and a task to claim. Replaces the get_project_meta→get_system→get_build_region dance.

Input parameters:

- `files` (array): Repo-relative paths you're about to touch — mapped to their systems
- `project_id` (string)
- `task` (string): A task id or name — briefs its milestone's systems instead

### `get_system` (~59 tokens)

ONE system's full spec (Goal/Boundary/Acceptance, markdown, sources, status) + pending Inbox changes touching it.

Input parameters:

- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)

### `list_systems` (~33 tokens)

All systems, compact: id, name, status, 1-line goal.

Input parameters:

- `project_id` (string)

### `get_build_region` (~163 tokens)

System→code map per built system: implementing files, status, drift flag, last_commit, and acceptance-evidence COUNTS. Mapped files gone from the repo? report_drift. Pass `system:"<name|id>"` for ONE system plus the full text of its acceptance criteria (omitted from the map — it is the bulk of the payload). Big projects come back paged: the body says 'page N of M', call again with `page: N+1`.

Input parameters:

- `page` (number): Which page of the map (default 1); the body tells you how many there are
- `project_id` (string)
- `system` (string): One system by name or id — returns its acceptance-criteria detail too

### `report_drift` (~83 tokens)

Flag CODE DRIFT — mapped files no longer match the repo. Advisory; a fresh report_build_status clears it.

Input parameters:

- `id` (string): Preferred
- `missing_files` (array): Paths that no longer exist
- `name` (string): If no id
- `note` (string): Optional — what drifted
- `project_id` (string)

### `get_history` (~83 tokens)

DESIGN MEMORY: recorded decisions/logs/rejections with who/when. Read BEFORE changing a system's direction; empty = no recorded WHY — don't invent one.

Input parameters:

- `limit` (number): Default 30, max 100
- `project_id` (string)
- `query` (string): Keyword filter
- `system` (string): System id or exact name

### `get_impact` (~77 tokens)

BLAST RADIUS of a system (deterministic): upstream context, siblings, dependent screens/milestones, files, code-coupled systems, pending Inbox, recent activity. Run BEFORE changing it.

Input parameters:

- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)

### `get_rejections` (~41 tokens)

Owner's DECLINED list — check at session start; follow each entry's guidance, then resolve_rejection(title).

Input parameters:

- `project_id` (string)

### `resolve_rejection` (~53 tokens)

Report you REVERTED a declined change (unlocks the owner's Clear). Call after realigning the build.

Input parameters:

- `project_id` (string)
- `title` (string, required): Exactly as get_rejections returned it

### `list_screens` (~30 tokens)

All screens, compact: id, name, purpose, status.

Input parameters:

- `project_id` (string)

### `get_screen` (~79 tokens)

ONE screen's layout: canvas `resolution` (use THESE px), elements x/y/w/h, links, popups. Read before editing a screen. has_reference_image:true → get_screen_image shows you the actual image.

Input parameters:

- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)

### `get_screen_image` (~67 tokens)

A screen's reference image (HUD background) as an actual IMAGE you can see — reads the stored file inline (signed-URL fallback past 4MB).

Input parameters:

- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)

### `update_element` (~163 tokens)

Move/resize/relabel an element — DIRECT, live. element_id (preferred) or screen+label; x+y also places an unplaced one.

Input parameters:

- `element_id` (string): From get_screen (preferred)
- `h` (number)
- `label` (string): Current label
- `new_label` (string): Rename (optional)
- `note` (string): "" clears
- `project_id` (string)
- `screen` (string): With label, if no element_id
- `system` (string): System it serves
- `type` (string): e.g. button/bar/panel (optional)
- `w` (number)
- `x` (number): px on the screen's canvas
- `y` (number)

### `withdraw_proposal` (~47 tokens)

Remove YOUR OWN still-pending Inbox item (id from the propose response / get_inbox).

Input parameters:

- `id` (string, required): The pending item's id
- `project_id` (string)

### `delete_entity` (~106 tokens)

PROPOSE a delete → Inbox (owner adopts; nothing deleted now). id preferred or exact name; flow_edge may use from+to.

Input parameters:

- `from` (string): flow_edge: source screen
- `id` (string): Entity/task/element/edge id
- `kind` (string, required): What to delete
- `name` (string): Exact name/title (if no id)
- `project_id` (string)
- `to` (string): flow_edge: destination screen

### `dedupe` (~52 tokens)

Remove duplicate-named entries (keep first) — DIRECT, destructive.

Input parameters:

- `kind` (string, required): What to dedupe
- `project_id` (string)
- `screen` (string): For kind=elements

### `reorder` (~96 tokens)

Reorder milestones / tasks / elements — DIRECT. order = ids in new order; omitted keep relative order.

Input parameters:

- `kind` (string, required): What to reorder
- `milestone` (string): For kind=tasks (name)
- `milestone_id` (string): For kind=tasks
- `order` (array, required): Ids in the new order
- `project_id` (string)
- `screen` (string): For kind=elements

### `list_milestones` (~35 tokens)

All milestones, compact: id, name, weeks, order, done/total.

Input parameters:

- `project_id` (string)

### `get_milestone` (~59 tokens)

ONE milestone: goal, weeks, difficulty, systems, every task (id/name/done/status/effort).

Input parameters:

- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)

### `list_activity` (~91 tokens)

Change history {who, change, entity, kind, when}, newest first; filter kind/who/query.

Input parameters:

- `kind` (string): system | context | milestone | screen (optional)
- `limit` (number): Default 30, max 200
- `project_id` (string)
- `query` (string): Keyword filter (optional)
- `who` (string): Author email substring (optional)

### `get_inbox` (~37 tokens)

PENDING Inbox (the owner's triage queue). Check BEFORE proposing — avoid duplicates. Read-only.

Input parameters:

- `project_id` (string)

### `search` (~61 tokens)

Keyword search — compact hits {kind, id, name} + snippet.

Input parameters:

- `kinds` (array): Optional: system | context | milestone | task | screen | proposal
- `project_id` (string)
- `query` (string, required): Text to search for

### `propose_system` (~158 tokens)

Propose a NEW system → Inbox. spec = ## Goal / ## Boundary (Owns · Doesn't own) / ## Acceptance. Exists? use update_system. (Alias: create_proposal.)

Input parameters:

- `acknowledge_rejection` (boolean): Only after a DECLINED bounce AND asking the user
- `batch` (string): import_from_code batch id
- `derives_from` (array): Context note title(s) this system derives from → wires provenance (upstream + siblings)
- `files` (array): Implementing paths, ONE file per entry
- `project_id` (string)
- `spec` (string, required): Markdown: ## Goal / ## Boundary / ## Acceptance
- `title` (string, required): System name (Title Case, English)

### `propose_context` (~176 tokens)

Propose a new/updated Idea note → Inbox. Title-match to update; send the COMPLETE revised text. Set resync:true ONLY when you rewrote the note FROM the current systems (get_stale lists notes the systems have moved past) — it stops the adopted note from immediately nagging to re-generate the systems it was just written from.

Input parameters:

- `acknowledge_rejection` (boolean): Only after a DECLINED bounce AND asking the user
- `batch` (string): import_from_code batch id
- `content` (string, required): Complete text, not a delta
- `project_id` (string)
- `resync` (boolean): This note was re-derived from the current systems — re-stamps both staleness signals on adopt
- `title` (string, required): Match existing to update, or new to add

### `propose_dna` (~69 tokens)

Propose Project DNA and/or Tech Notes → Inbox (at least one).

Input parameters:

- `batch` (string): import_from_code batch id
- `dna` (string): Omit to leave unchanged
- `project_id` (string)
- `tech_notes` (string): Omit to leave unchanged

### `update_system` (~204 tokens)

Propose a system UPDATE → Inbox diff. get_system first; send the FULL revised spec. new_title renames; context_title+context bundles the Idea update. Set resync:true ONLY when you rewrote this spec FROM its upstream Idea (see resync_from_idea) — it re-stamps the staleness signal on adopt.

Input parameters:

- `acknowledge_rejection` (boolean): Only after a DECLINED bounce AND asking the user
- `context` (string): Full revised Idea text
- `context_title` (string): Idea section to also update
- `id` (string): Preferred
- `name` (string): If no id
- `new_title` (string): Rename in the same card
- `project_id` (string)
- `resync` (boolean): This spec was re-derived from its upstream Idea — re-stamps sourceSig on adopt. Never set it on an ordinary edit.
- `spec` (string, required): Full revised spec markdown

### `get_balance` (~57 tokens)

Read Balance Lab: stat tables, boards with EVALUATED values, scenarios.

Input parameters:

- `board` (string): One board (omit = all)
- `include_rows` (boolean): false = schema only
- `project_id` (string)

### `propose_balance_table` (~136 tokens)

Propose a stat-doc TABLE → Inbox. csv (header; `key%` = percent; first column = name) OR schema+rows. Adopting REPLACES same-named.

Input parameters:

- `csv` (string): Header + rows; non-numeric = info
- `project_id` (string)
- `registry` (boolean): true = the shared Stats registry
- `rows` (array): [{name, atk: 350, …}]
- `schema` (array): [{key, mode: flat|pct|text, base, min, max, desc}]
- `title` (string, required): Table name

### `propose_balance_board` (~106 tokens)

Propose a node board → Inbox. Kinds const|formula|item|sheet|loadout|picker|pool|process|note|frame; formulas reference blocks by NAME; omit x/y = auto-layout. Adopting REPLACES same-named.

Input parameters:

- `name` (string, required): Board name
- `nodes` (array, required): e.g. {kind:"formula",name:"dmg",formula:"atk - mdef"}
- `project_id` (string)

### `propose_milestone` (~83 tokens)

Propose a NEW milestone (+ optional tasks) → Inbox.

Input parameters:

- `acknowledge_rejection` (boolean): Only after a DECLINED bounce AND asking the user
- `goal` (string): One-line goal (optional)
- `name` (string, required): Milestone name
- `project_id` (string)
- `tasks` (array): Task names (optional)

### `report_milestone_progress` (~71 tokens)

Mark existing-milestone tasks done → Inbox progress card (owner adopts the ticks).

Input parameters:

- `done_tasks` (array, required): Task names that are done
- `id` (string): Preferred
- `milestone` (string): Milestone name (if no id)
- `project_id` (string)

### `report_build_status` (~313 tokens)

Report a SYSTEM's status (todo|in-progress|implemented) — DIRECT, live. ALWAYS pass files (full list — it REPLACES); non-todo with no files shows done-but-EMPTY. 'implemented' counts as VERIFIED only when every UNIT-TESTABLE ## Acceptance bullet is backed via evidence[{criterion,proof}]; a bullet tagged [manual]/[e2e]/[ui]/[wip] is EXEMPT (verified by manual/e2e). Otherwise it's a CLAIM (verified:false) and the response names the unbacked criteria. TWO tiers: VERIFIED = a test is NAMED; GREEN (guarantee) = you RAN the test and reported `passed:true` on the evidence — green goes stale after 21 days, so re-run to keep it.

Input parameters:

- `decisions` (array): Decisions/divergences (prose)
- `evidence` (array): Map ## Acceptance bullets to a test/file: [{criterion, proof, passed?, at?}]. Re-send full set (replaces). proof-only = backed (claimed); passed:true = test-green (guarantee).
- `files` (array): ONE file per entry (optional ' — function'); prose → decisions
- `id` (string): Preferred
- `name` (string): If no id
- `project_id` (string)
- `status` (string, required): todo | in-progress | implemented
- `version` (string): e.g. "0.379.0"

### `propose_flow_edge` (~65 tokens)

SECONDARY (user-driven UI): propose a link between two existing screens → Inbox.

Input parameters:

- `from` (string, required): Source screen name
- `label` (string): Transition label (optional)
- `project_id` (string)
- `to` (string, required): Destination screen name

### `propose_element` (~154 tokens)

SECONDARY (user-driven UI): propose an element onto a screen → Inbox. ALWAYS pass x/y/w/h (px on the screen's `resolution` from get_screen); no coords = unplaced pile.

Input parameters:

- `h` (number): Default 40
- `label` (string, required): Element label, e.g. 'HP bar'
- `note` (string)
- `project_id` (string)
- `screen` (string, required): Existing screen name
- `system` (string): System it serves
- `type` (string): button/bar/panel/text (default box)
- `w` (number): Default 120
- `x` (number): Left px
- `y` (number): Top px

### `propose_screen` (~93 tokens)

SECONDARY (user-driven UI): propose a NEW screen → Inbox. parent = popup over that screen; purpose grounds AI suggestions. Whole UI? design_ui_from_systems first.

Input parameters:

- `name` (string, required): Screen name (Title Case, English)
- `parent` (string): Make it a POPUP over this screen
- `project_id` (string)
- `purpose` (string): What this screen is for

### `report_screen_status` (~55 tokens)

Report a SCREEN's status (todo|in-progress|implemented) → Inbox.

Input parameters:

- `project_id` (string)
- `screen` (string, required): Screen name
- `status` (string, required): todo | in-progress | implemented

### `rename_screen` (~57 tokens)

Rename a screen IN PLACE — DIRECT; links/elements follow (id-referenced).

Input parameters:

- `name` (string, required): Exact CURRENT name
- `new_name` (string, required): New name (must not collide)
- `project_id` (string)

### `update_milestone` (~93 tokens)

Edit milestone goal/weeks/difficulty/name — DIRECT. new_name renames (never delete+recreate).

Input parameters:

- `difficulty` (string): "" clears
- `goal` (string)
- `id` (string): Preferred
- `name` (string): Current name (if no id)
- `new_name` (string): Rename
- `project_id` (string)
- `weeks` (number)

### `add_task` (~124 tokens)

Add a task to a milestone — DIRECT. assignee:"me" claims on creation.

Input parameters:

- `assignee` (string): "me" claims it
- `done` (boolean)
- `effort` (string)
- `human` (boolean): Human-only (GTM/validation/people work) — next_task & get_briefing skip it
- `milestone` (string): If no id
- `milestone_id` (string): Preferred
- `name` (string, required): Task name
- `project_id` (string)
- `status` (string)

### `next_task` (~105 tokens)

DISPATCHER (multi-agent): atomically pick + claim the next task to build — walks milestones in order, skips human-only tasks and any task whose systems share code files with a task another agent already holds or is actively touching, so parallel agents spread out instead of colliding. Returns the claimed task + systems, or why none is free. dry_run:true peeks without claiming.

Input parameters:

- `dry_run` (boolean): Peek without claiming
- `project_id` (string)

### `update_task` (~156 tokens)

Edit a task or CLAIM it — DIRECT. assignee:"me"+status:"in-progress" claims (errors if held; force:true for stale); done:true or assignee:"" releases.

Input parameters:

- `assignee` (string): "me" claims; "" releases
- `done` (boolean): true releases the claim
- `effort` (string): "" clears
- `force` (boolean): Take over a STALE claim only
- `human` (boolean): true = human-only (next_task/get_briefing skip it); false clears
- `name` (string)
- `project_id` (string)
- `status` (string): "" clears
- `task_id` (string, required): From get_milestone

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp#diagnostics

## Score history

- 2026-08-03: 80
- 2026-08-02: 79
- 2026-08-01: 79
- 2026-07-31: 78
- 2026-07-30: 73
- 2026-07-29: 73
- 2026-07-28: 72
- 2026-07-27: 71
- 2026-07-26: 71

## Links

- Remote endpoint: https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp
- Repository: https://github.com/alongkornonline2019/forge-mcp
- Website: https://forgeengine.app/
- Changelog RSS feed: https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/app-forgeengine-forge/functions-v1-forge-mcp