01
Overview
The same idea, a new engine
SB-Bridge is a Claude Code MCP server for s&box, Facepunch's Source 2 game engine. It is the same idea as my UE-Bridge aimed at a different engine: give Claude real reach inside the editor so it can read the scene, find assets, and build and debug gameplay directly, instead of guessing from the outside.
02
Challenge
Does the bridge pattern travel?
s&box released on April 28, 2026. My first commit on sb-bridge was two days later. I wanted to find out whether the bridge pattern generalized, so I ran a parity study against UE-Bridge first, locked the decisions, and started from a known shape rather than a blank page.
Building that early meant there was almost nothing to copy from. Two community projects existed, and I treated both as catalogs of what was possible rather than as code to read. One of them carries a GPL-3.0 license, which made a clean-room build mandatory rather than a preference.
03
Build
Across a WebSocket, onto the frame loop
There are two halves. A TypeScript MCP server talks to Claude over stdio, and a C# addon lives inside the s&box editor. They speak to each other across a single WebSocket connection, with every request and response correlated by id.
The interesting constraint is that s&box's editor is single-threaded, so I cannot just mutate the scene from a background handler. Every change is queued onto the editor's frame loop through a main-thread dispatcher, while slower work like profiling runs on worker threads and marshals its results back. It is a careful boundary between sync and async, and getting it right is what makes mutations safe.
A knowledge cache rides alongside the tools: a growing set of validated s&box patterns Claude can read before it builds. That came out of a hard rule I set after a couple of incidents: never build what Facepunch already ships. Check for a stock component first, and only hand-roll when there genuinely is not one.
When the documentation isn't there
s&box's official documentation is a single-page app that returns nothing useful to a plain HTTP fetch, so the first workaround was pulling raw files from GitHub instead. That wasn't enough on its own, so a type schema stood in for docs: 1,876 types with full method signatures, file and line references, and summaries, which was richer than the rendered site anyway. When the schema ran out, I cloned the engine source, both the gamemode and the managed engine, and read that. When the source ran out, there was one occasion where the answer only came from decompiling.
Nothing learned that way got learned twice. That is the whole reason there's a knowledge cache in the project: the engine's documentation wasn't sufficient, so the work built its own as it went. Dead ends are in there too, written up as findings rather than deleted, because knowing which four approaches failed is worth as much as knowing the one that worked.
Two pillars: read, then write
Like UE-Bridge, the work split into pillars. Pillar 1 was introspection and diagnostics, the safe read-only surface: walk the scene graph, inspect objects and components, find assets, sample performance, tail the editor log, even trigger a profiling capture. Building reading first meant I could iterate quickly without risk.
Pillar 2 was authoring: creating and deleting objects, setting transforms and properties, parenting, duplicating, saving prefabs and materials, plus helpers for multiplayer scaffolding and navmesh baking, all wrapped in undo groups. Mutations are the dangerous part, so they came once introspection was solid and the dispatcher was hardened.
04
Capabilities
The toolset
The bridge exposes 42 tools across introspection, mutation, asset authoring, gameplay helpers, and knowledge. A sample:
Introspection & diagnostics
bridge_statusget_scene_hierarchyinspect_game_objectget_component_propertiesfind_objects_by_namefind_assetsget_perf_statsforce_gctail_editor_logstart_profile_capture
Scene & component authoring
create_game_objectdelete_game_objectset_transformset_parentadd_componentremove_componentset_component_propertyduplicate_game_objectbulk_applybegin_undo_group
Assets & gameplay
save_as_prefabinstantiate_prefabcreate_materialdescribe_shadersetup_multiplayer_scaffoldvalidate_multiplayer_wiringbake_navmesh
Knowledge
list_docsread_docrun_bridge_command
05
Outcome
Validated against live play
What I am happiest with is the discipline. Every phase shipped with a validation pass: I did not mark a pattern or tool trustworthy until it had carried real weight in a live editor session, building actual scenes. A pattern only gets promoted from foundation to validated once it proves itself under load, and more than a hundred and fifty of those validation runs are written down.
The shape of the effort: 695 commits over six weeks, 682 of them in May alone, across 19 tagged releases.
SB-Bridge is alpha and personal for now, but its surface is treated as semi-stable, and it confirmed the thing I set out to test: the bridge pattern travels. The same shape that put Claude inside Unreal puts it inside s&box.

