Skip to content

Add optional MCP bridge for level-design tooling - #41

Open
Joyxt wants to merge 1 commit into
vimontgames:masterfrom
Joyxt:vgframework_MCP
Open

Joyxt wants to merge 1 commit into
vimontgames:masterfrom
Joyxt:vgframework_MCP

Conversation

@Joyxt

@Joyxt Joyxt commented Sep 20, 2026

Copy link
Copy Markdown
Contributor

Additive module exposing the active scene to an external MCP server, so a level can be inspected and built programmatically: list objects, get/set transforms, spawn and delete, create groups, scenes and worlds, generate prefabs from FBX folders, instantiate prefabs, assign materials.

Nothing changes on a normal run. The plugin is only loaded when the VG_MCP_BRIDGE environment variable is set, so g_mcpBridge stays nullptr and every added call site is a dead branch. The engine does not link against the module either: it only sees the pure-virtual IMCPBridge.h, and the DLL is resolved at runtime through the existing Plugin::create mechanism, exactly like renderer, physics, audio or editor.

Transport is file-based (mcp/commands.jsonl in, mcp/state.json out), polled once per frame from Engine::RunOneFrame. No socket, no thread and no network dependency is introduced in the engine. The module depends on Core only.

Changes to existing files are one line each, plus five guarded blocks:

  • vg.solution.sharpmake.cs adds the project to the solution
  • vg.engine.sharpmake.cs defines VG_ENABLE_MCPBRIDGE (the kill switch:
    remove this line and the bridge is gone)
  • vg.data.sharpmake.cs keeps src/mcpbridge headers out of the
    Version data project
  • .gitignore ignores the mcp/ transport directory
  • src/engine/Engine.cpp load, tick and unload, all under
    #if VG_ENABLE_MCPBRIDGE

See docs/architecture.md for the design and docs/data-contract.md for the wire format.

Additive module exposing the active scene to an external MCP server, so a
level can be inspected and built programmatically: list objects, get/set
transforms, spawn and delete, create groups, scenes and worlds, generate
prefabs from FBX folders, instantiate prefabs, assign materials.

Nothing changes on a normal run. The plugin is only loaded when the
VG_MCP_BRIDGE environment variable is set, so g_mcpBridge stays nullptr
and every added call site is a dead branch. The engine does not link
against the module either: it only sees the pure-virtual IMCPBridge.h,
and the DLL is resolved at runtime through the existing Plugin::create
mechanism, exactly like renderer, physics, audio or editor.

Transport is file-based (mcp/commands.jsonl in, mcp/state.json out),
polled once per frame from Engine::RunOneFrame. No socket, no thread and
no network dependency is introduced in the engine. The module depends on
Core only.

Changes to existing files are one line each, plus five guarded blocks:
- vg.solution.sharpmake.cs  adds the project to the solution
- vg.engine.sharpmake.cs    defines VG_ENABLE_MCPBRIDGE (the kill switch:
                            remove this line and the bridge is gone)
- vg.data.sharpmake.cs      keeps src/mcpbridge headers out of the
                            Version data project
- .gitignore                ignores the mcp/ transport directory
- src/engine/Engine.cpp     load, tick and unload, all under
                            #if VG_ENABLE_MCPBRIDGE

See docs/architecture.md for the design and docs/data-contract.md for the
wire format.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@kdridi

kdridi commented Sep 24, 2026

Copy link
Copy Markdown
Contributor

Don't tell me @Benualdo is going to let this slide by allowing the AI ​​to get in with that PR! 🫢

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.

2 participants