Skip to main content
Glama
genart-dev

genart-mcp

by genart-dev

design_set_plant_tropism

Configure gravity and susceptibility on a plant layer to control upward growth, drooping, and wind-induced lateral bias.

Instructions

Configure tropism forces on a plant layer. Positive gravity = upward growth (phototropism), negative = drooping (gravitropism). Wind adds lateral bias.

Input Schema

NameRequiredDescriptionDefault
gravityNoGravity force (-1 to 1). Positive = upward, negative = drooping.
layerIdYesTarget plant layer ID.
susceptibilityNoHow strongly the plant responds to tropism (0-1).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does explain the directional semantics of gravity and mentions lateral wind bias, but it omits mutation behavior such as whether existing tropism settings are overwritten, whether the layer must exist, and how susceptibility interacts with the forces.

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 short and front-loads the core action. The final sentence about wind is concise but slightly confusing because wind is not a parameter and may overlap with another sibling tool.

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

Completeness3/5

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

For a simple three-parameter setter with full schema coverage and no output schema, the description provides enough to understand the basic effect. However, it lacks mutation/reversibility context and introduces wind without a corresponding parameter, leaving some ambiguity for an agent invoking the tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already defines all three parameters. The description restates gravity semantics already present in the schema and mentions wind even though no wind parameter exists, adding limited parameter-level value beyond the schema.

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 uses a specific verb and resource: configuring tropism forces on a plant layer. It is clear what the tool does, but it does not explicitly differentiate itself from sibling plant-control tools such as design_set_plant_wind or design_set_plant_growth.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, no prerequisites such as requiring an existing plant layer, and no mention of whether tropism and wind should be configured together or separately. The wind sentence may even blur the boundary with design_set_plant_wind.

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