Skip to main content
Glama

create_curve_asset

Create reusable curve assets for value-over-time or value-over-input ramps to replace hard-coded numbers in damage falloff, stat growth, fade timing, or colour gradients.

Instructions

Create a curve asset (CurveFloat, CurveVector or CurveLinearColor) -- a reusable value-over-time or value-over-input ramp for damage falloff, stat growth, fade timing or colour gradients, referenced by assets instead of hard-coded numbers. Channel count follows the type (1 / 3 / 4), and add_curve_key fills it. Different thing from a CurveTable (create_curve_table), which holds many named curves as rows.

Returns: { name, package_path, curve_type, asset_path, curve_class, num_channels, created, already_exists, saved, success, message }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAsset name to create
curve_typeNoCurve type to create (read the body for the allowed values)
package_pathNoTarget content package path where the asset is created (check the body for the default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare this is a non-read, non-destructive, non-idempotent creation. The description adds some value by listing created/already_exists/saved in the return, hinting that it handles pre-existing assets and saving. However it never states overwrite/collision behavior or permissions, so it does not add rich behavioral context beyond the annotations.

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 purpose and type enumeration are front-loaded, and the CurveTable distinction is placed after the core definition. It is somewhat dense across three sentences, but each sentence carries useful information for creation and follow-up.

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?

There is no output schema, but the description embeds a Returns field list, so the agent knows what it gets back. Combined with the type mapping and sibling differentiation, it is complete enough to call correctly, with only minor gaps around collision/overwrite behavior.

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 coverage is 100%, so baseline is 3, but the description adds real meaning: it supplies the concrete allowed curve_type values that the schema defers ('read the body for the allowed values') and explains that channel count follows the type (1/3/4). This compensates for the schema's vagueness on the key parameter.

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?

States a specific verb and resource ('Create a curve asset') and enumerates the concrete types (CurveFloat, CurveVector, CurveLinearColor). It explicitly distinguishes itself from the sibling create_curve_table, so an agent can route correctly without opening other schemas.

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?

Names the alternative (create_curve_table) and the condition that selects it ('holds many named curves as rows'), giving clear routing context. It also points to add_curve_key as the follow-up for populating the curve. It stops short of explicit when-not-to-use or prerequisite guidance, so it is not a full 5.

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

Deploy Server

Other Tools