godot-omni

Overview Schema Source Related Servers Discussions Admin

viewport_manage

Create and configure SubViewports, scaffold splitscreen layouts, and route render textures to sprites, textures, or materials in Godot scenes.

Instructions

Godot Viewport and SubViewport Lifecycle, Splitscreen, and Render Texture Routing.

Ops:

create_subviewport(parent_path="", name="SubViewport", size=[512, 512], render_target_update_mode=3, transparent_bg=false, own_world_3d=false, as_container=false) Create a SubViewport or SubViewportContainer in the active scene.
scaffold_splitscreen(layout="2p_horizontal", is_3d=false, parent_path="") Scaffold a multi-player splitscreen layout (2p_horizontal, 2p_vertical, 4p_quad) with SubViewports, SubViewportContainers, and independent cameras.
wire_render_texture(viewport_path, target_node_path, target_property="") Route a SubViewport's ViewportTexture into a Sprite2D, TextureRect, or MeshInstance3D material albedo.
get_viewport_tree() Inspect all Viewports in the active scene, their sizes, update modes, and active cameras.
set_properties(viewport_path, size=..., transparent_bg=..., render_target_update_mode=..., own_world_3d=..., msaa_2d=..., msaa_3d=..., screen_space_aa=..., use_hdr_2d=...) Configure rendering fidelity and options for an existing Viewport.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv5.0.28Sep 23, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It does a good job by explaining the effect of each op and disclosing the compatibility alias for canonical call shape. It could add more about side effects or error conditions, but the verbs and details are largely transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear title, bulleted op signatures, and one-line explanations. The canonical call shape note is useful and placed at the end. There is no filler or redundant prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All five operations are documented with signatures and purpose, and an output schema exists so return-value details are not required. Minor gaps remain around the precise meaning of some optional rendering parameters and cross-tool guidance, but the description is otherwise complete for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is generic (op/params/session_id with 0% schema description coverage), so the description is the sole source of parameter meaning. It provides named signatures with defaults and some enums (e.g., layout='2p_horizontal', size=[512, 512]). Some values, such as render_target_update_mode=3, are left unexplained, but the level of compensation is strong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title immediately scopes the tool to Godot Viewport/SubViewport management, and the op list enumerates concrete actions with specific resources: create_subviewport, scaffold_splitscreen, wire_render_texture, get_viewport_tree, and set_properties. This is sufficiently distinct from sibling tools like camera_manage, texture_manage, and node_manage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each operation's one-line purpose gives clear functional context (e.g., "Scaffold a multi-player splitscreen layout..."), so an agent can infer when to use a given op. However, the description never explicitly contrasts alternatives or states when not to use this tool versus sibling tools such as camera_manage or rendering_manage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server