godot-omni

Overview Schema Source Related Servers Discussions Admin

camera_manage

Create, configure, and manage 2D/3D cameras in Godot: build follow cameras, set zoom/FOV/projection, bounds, damping, apply presets, and inspect active cameras.

Instructions

Camera2D / Camera3D authoring (zoom, FOV, projection, smoothing, follow).

Ops: • create(parent_path, name="Camera", type="2d", make_current=False) Create a Camera2D ("2d") or Camera3D ("3d"). When make_current=True, unmarks previously current cameras of the same class in one undo. • configure(camera_path, properties) Batch-set camera-specific properties (zoom, fov, projection, smoothing, drag, limits …). Class-aware. Enum-by-name (projection, keep_aspect, anchor_mode, doppler_tracking, process_callback). Vector2 dict coercion for zoom/offset. Transforms (position, rotation, scale, transform, global_*) live on the Node — set those via node_set_property, not here. • set_limits_2d(camera_path, left?, right?, top?, bottom?, smoothed?) Set Camera2D bounds. Pass only the edges to change. • set_damping_2d(camera_path, position_speed?, rotation_speed?, drag_margins?, drag_horizontal_enabled?, drag_vertical_enabled?) Smooth Camera2D motion (position/rotation smoothing speeds + drag deadzone). drag_margins: {left,top,right,bottom} fractions [0,1]. • follow_2d(camera_path, target_path, smoothing_speed=5.0, zero_transform=True) Reparent camera under target with smoothing — Godot-native follow. • scaffold_follow_2d(target_path="", parent_path="", name="FollowCamera2D", smoothing_speed=5.0, zoom=None, enable_shake=True, make_current=True, limits=None) Scaffold complete follow Camera2D with position smoothing and trauma-based screen shake (adds add_trauma() method to camera). • get(camera_path="") Inspect a camera (class, current flag, all properties). Empty path resolves to the currently-active camera, falling back to the first. • list() List every Camera2D/Camera3D in the scene. • apply_preset(parent_path, name, preset, type=None, make_current=True, overrides=None) Spawn with opinionated defaults. Presets: topdown_2d, platformer_2d, cinematic_3d, action_3d. overrides merge over preset values.

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.

Changed1 schema field changedv5.0.28Sep 23, 2026

changedInput schema / properties / op / enum

Previous value: -[
-  "apply_preset",
-  "configure",
-  "create",
-  "follow_2d",
-  "get",
-  "list",
-  "set_damping_2d",
-  "set_limits_2d"
-]New value: +[
+  "apply_preset",
+  "configure",
+  "create",
+  "follow_2d",
+  "get",
+  "list",
+  "scaffold_follow_2d",
+  "set_damping_2d",
+  "set_limits_2d"
+]

First observedv4.1.0Sep 17, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it discloses that make_current=True unmarks previously current cameras of the same class in one undo, that configure is class-aware, that scaffold_follow_2d adds an add_trauma() method to the camera, and that follow_2d reparents the camera under the target. It also notes the canonical call shape and compatibility alias. It doesn't disclose error behavior or permission requirements, but for a camera authoring tool the key side effects are well covered.

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

Conciseness4/5

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

The description is long but well-structured: a one-line summary followed by a bulleted op list with compact signatures and inline notes. Every op earns its place, and the canonical call shape note is useful. It is not maximally concise, but the density of information justifies the length.

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?

Given the tool's complexity (9 ops, many parameters, no annotations, no schema-level parameter docs), the description is remarkably complete. It covers all ops, parameter semantics, side effects, and the call shape. It doesn't describe return values in detail, but an output schema exists, so that burden is partially lifted. Minor gaps: no explicit error/edge-case behavior and no mention of what happens when a camera_path is invalid, but these are not critical for an agent selecting and invoking the tool.

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?

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It does so extensively: each op lists its parameters with types, defaults, and semantics (e.g., drag_margins: {left,top,right,bottom} fractions [0,1], limits with optional edges, overrides merge over preset values). The only gap is that the schema's params object is a free-form anyOf, so the description's per-op parameter lists are the sole documentation, and they are detailed enough to be actionable.

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 description opens with a specific verb and resource ('Camera2D / Camera3D authoring') and then enumerates nine distinct operations with concrete effects (create, configure, set_limits_2d, set_damping_2d, follow_2d, scaffold_follow_2d, get, list, apply_preset). This clearly distinguishes the tool from sibling tools like node_manage or viewport_manage by scoping it to camera-specific authoring.

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

Usage Guidelines5/5

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

The description gives explicit usage guidance: it states that transforms (position, rotation, scale, transform, global_*) live on the Node and should be set via node_set_property, not here. It also explains when to use get with an empty path (resolves to active camera) and when to use list. The op-by-op breakdown effectively tells an agent when to use each operation and what the alternatives are.

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

Deploy Server