"Engine ships built-in McpTool source as readable C# — read it before writing your own"

You're writing a custom [McpTool] for your project and can't find the canonical pattern for getting the active editor scene, taking viewport screenshots, or moving the editor camera. Your existing project McpTool reference is a pure resource-lookup tool that never touches the scene, so it doesn't demonstrate any of these editor-interaction patterns.

The engine ships its own built-in McpTools as readable C# source files, not just compiled DLLs. They live under the engine's install directory at addons/tools/Code/Mcp/*.cs — files like Scene.cs, EditorTools.cs, AssetSystem.cs, Play.cs, Packages.cs, Log.cs, and Components.cs. These are ProjectReference'd (not just Reference'd) into every project's .editor.csproj, which is why they're on disk in full source form.

Most developers never look at this directory because they learned from a project-level McpTool example that only does asset lookups. The engine's own source files contain the real patterns.

Before writing any new [McpTool] that needs the scene, camera, or selection, read the engine's source at addons/tools/Code/Mcp/:

• Active editor scene: Scene.cs shows SceneEditorSession.Active?.Scene ?? Game.ActiveScene — use this pattern via the scene-tools helper to resolve the scene correctly in both edit and play mode.
• Viewport screenshots: Application.Editor?.Camera + camera.RenderToBitmap(bitmap, false) (also in Scene.cs).
• Moving the editor camera: go through SceneViewWidget.Current?.LastSelectedViewportWidget.
• Resolving GameObjects by GUID: iterate across every open SceneEditorSession.

Attribute forms: two syntax variants both compile. The longhand convention used in most project tools is [McpTool("name", Hints = McpToolHints.ReadOnly)]. The engine's own tools use the shorthand [McpTool.ReadOnly("name")].

The engine's McpTool source files are the most authoritative reference for editor-integration patterns because they're the implementations the engine team maintains. Unlike project-level examples (which tend to be simple resource-lookup tools), the built-in tools demonstrate the full range of editor session, camera, and scene interactions. Reading the actual source is faster and more reliable than guessing at APIs or reverse-engineering from documentation.