Skip to content

docs(mcp): make from_brief state how to bind a scene - #595

Merged
Aymericr merged 1 commit into
mainfrom
fix/from-brief-scene-binding-guidance
Aug 5, 2026
Merged

docs(mcp): make from_brief state how to bind a scene#595
Aymericr merged 1 commit into
mainfrom
fix/from-brief-scene-binding-guidance

Conversation

@Aymericr

@Aymericr Aymericr commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Salvages the prompt-text portion of #561 with attribution to @Srujanreddy1234, whose report is what surfaced this.

The gap

from_brief's only guidance about scene binding was conditional on the user's phrasing:

If the user asks for a new project, call create_project before building.

A brief that doesn't read as "new project" — "add a garage", "lay out the second floor" — leaves the model with no instruction to bind anything. packages/mcp then runs the mutations against an unbound scene, which is a no-op as far as the user can tell: nothing persists, nothing shows up in the browser, and no tool returns an error. The prompt never mentioned that consequence, so the model had no reason to treat binding as a precondition.

What changed

  • Names all three ways to bind, unconditionally and up front: create_project (new), list_scenes + load_scene (existing), create_house_from_brief (create and load a starter in one step). list_scenes/load_scene were never mentioned at all, which is the actual hole — there was no documented path to an existing project.
  • States the consequence: "mutations apply in memory only — they are not persisted and never appear in the browser." Rules are followed more reliably when the cost of skipping them is stated.
  • Splits the save/verify/return-editorUrl sequence into its own line. It was appended to the binding sentence, which made a four-clause instruction out of two unrelated ones.
  • Task section becomes bind / build / finish. It was a single 90-word line; ordering was there but not legible.
  • Fixes the registered tool description, which still advertised "produces a plan of apply_patch calls." The prompt has steered toward semantic tools for a while, so the description was describing an older version of itself — and it's the string an MCP client shows when picking a prompt.

Two tests pin the parts that carry the behavior, since prompt text has no other guard against silently regressing: every binding tool is named, and the consequence sentence is present.

Scope

Prompt strings and one tool description. No runtime change, no tool signature change, no new dependency.

bun run check clean (1601 files), check-types 9/9, packages/mcp tests 326 → 328, 0 fail.

Relationship to #561

#561 bundled this text with a runtime change to publishLiveSceneSnapshot(). That runtime change is worth doing but has four open blockers, the load-bearing one being that gating on hasStore breaks pascal-mcp --stdio — the README quick start fails on the first create_wall. I said in review I'd take the text as its own PR so it wouldn't sit behind that work, so here it is.

#561 stays open for the runtime fix, which stands on its own merits: publishLiveSceneSnapshot() returning silently when no scene is bound is a real defect. This PR makes the prompt stop causing the unbound state; it doesn't make the unbound state loud, which is what #561 is for.


Note

Low Risk
Prompt and description strings only; no runtime, tool signatures, or persistence behavior changes.

Overview
Updates the from_brief MCP prompt so models must bind an active scene before any mutations, instead of only mentioning create_project when the brief sounds like a “new project.”

The preamble now documents all three paths—create_project, list_scenes + load_scene, and create_house_from_brief—and spells out that without binding, edits stay in memory only and never show in the browser. Save/verify/editorUrl guidance is on its own line, and the ## Task section is reordered into bind → build → finish with semantic tools called out. The registered prompt description no longer claims the flow is mainly apply_patch.

Two tests lock in that every binding tool is named and the unbound-scene consequence text remains in buildFromBriefPrompt.

Reviewed by Cursor Bugbot for commit 2d3dbdf. Bugbot is set up for automated code reviews on this repo. Configure here.

`from_brief` told the model to "call `create_project` if the user asks for a
new project" and nothing else about scene binding, so a brief against an
existing project produced mutations with no bound scene. Those apply in
memory only — nothing persists and nothing appears in the browser, and the
prompt never said so.

Name all three ways to bind (`create_project`, `list_scenes` + `load_scene`,
`create_house_from_brief`), state the consequence of skipping it, and split
the overloaded save/verify sentence out of the binding instruction. The Task
section becomes bind / build / finish so the ordering is legible rather than
one run-on line.

The registered tool description still claimed the prompt "produces a plan of
apply_patch calls"; it has produced semantic tool calls for some time.

Prompt text only — no runtime behavior changes.

Co-authored-by: Srujan Reddy <srujanreddygangireddy@gmail.com>
@Aymericr
Aymericr merged commit 0ec0919 into main Aug 5, 2026
3 checks passed
@Aymericr
Aymericr deleted the fix/from-brief-scene-binding-guidance branch August 5, 2026 03:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant