godot-omni

by bebabinlarsson-blip

Overview Schema Source Related Servers Discussions Admin

Local

curve_manage

Create, sample, and manage 1D/2D/3D curves, splines, gradients, and color ramp resources in Godot.

Instructions

Curve (1D, 2D, 3D), Splines, Gradients, and Color Ramps Management.

Ops:

create_curve_1d(points=[[0.0, 0.0], [1.0, 1.0]], min_value=0.0, max_value=1.0, save_path="") Create a 1D interpolation/easing Curve resource.
create_curve_2d(points=[[0.0, 0.0], [100.0, 100.0]], in_tangents=[], out_tangents=[], save_path="") Create a 2D bezier spline Curve2D resource for paths and animation.
create_curve_3d(points=[[0.0, 0.0, 0.0], [0.0, 5.0, 10.0]], in_tangents=[], out_tangents=[], save_path="") Create a 3D bezier spline Curve3D resource for 3D paths and rail movement.
create_gradient(offsets=[0.0, 1.0], colors=["#000000", "#ffffff"], save_path="") Create a multi-stop color ramp Gradient resource.
create_gradient_texture(gradient_path="", width=256, is_2d=False, height=256, save_path="") Create a GradientTexture1D or GradientTexture2D resource.
sample_curve(curve_path, offset=0.5) Sample value or baked position on a Curve resource.
sample_gradient(gradient_path, offset=0.5) Sample RGBA color on a Gradient resource.

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.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the behavioral burden. It discloses the canonical call shape and the flat-parameter compatibility alias, plus the create/sample semantics of each operation. However, it does not disclose side effects such as whether save_path persists files, overwrites existing resources, or whether creation requires a project context.

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 long but highly structured: the domain is front-loaded, operations are grouped under 'Ops', and each bullet follows a consistent pattern with signature, defaults, and purpose. The final canonical call shape is valuable and earns its place; there is no filler or repetition of schema-only information.

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?

For a multi-operation tool with seven sub-ops and no schema-level parameter documentation, the description is remarkably complete: every operation is documented with its parameters and intended use. The main gap is that save_path semantics and file-system behavior are left implicit, and return values are not described, though an output schema is indicated.

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

Parameters5/5

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

Schema description coverage is 0%, so the description fully compensates by documenting every operation's parameters with defaults and examples, such as points=[[0.0, 0.0], [1.0, 1.0]], in_tangents=[], colors=['#000000', '#ffffff'], and offset=0.5. It also clarifies the top-level params object structure and flat-parameter compatibility alias.

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

Purpose4/5

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

The description clearly identifies the tool's domain: curves, splines, gradients, and color ramps, and immediately enumerates concrete operations like create_curve_1d, create_curve_2d, and sample_gradient. It is specific about resources and verbs, though it does not explicitly differentiate itself from sibling management tools such as resource_manage or texture_manage.

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

Usage Guidelines4/5

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

Each operation gets a context and intended purpose: create_curve_2d is 'for paths and animation', create_curve_3d is 'for 3D paths and rail movement', and sample_gradient says it samples 'RGBA color'. This provides clear internal selection guidance, but the description does not state when to prefer this tool over a sibling tool or list exclusions.

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

Deploy Server