New GeckoLib model

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's job is to add side-effect detail, which it does: a new tab is opened, the fallback to a Bedrock entity model occurs when the GeckoLib plugin is absent, and the reply carries a warning. It stops short of saying what happens on a duplicate name or whether an opened tab can be closed via close_tab.

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

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

Two tightly packed sentences: the deliverable comes first, then fallback behavior, then coordinate conventions. Only the parenthetical clause slightly interrupts reading flow; nothing is redundant.

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

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

For a creation tool with no output schema, the description covers the produced artifact, the degenerate fallback path, and the geometry conventions an agent needs before adding bones or cubes. Remaining gaps are collision handling and the fact that the new tab must later be closed, both minor.

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

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

Schema description coverage is 100%, so name, modid, texture_width, and texture_height are already documented including defaults. The description adds no parameter-level meaning (the unit/orientation notes are about the model, not the inputs), which is the expected baseline when the schema carries the load.

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

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

Names a specific verb and resource: opening a new tab containing an empty GeckoLib animated entity model. The GeckoLib-vs-Bedrock distinction and the 'empty/new' framing separate it from open_model and open_java_model in the sibling list without the agent needing to open a schema.

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

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

It implies creation of a fresh model and notes the plugin-missing fallback, which tells the agent what will actually be produced. However, it never says explicitly when to choose this over open_model, open_java_model, or new_java_item, leaving the create-vs-open routing to inference.

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