cherry_pick_feature_modification

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

With no annotations, the description carries the full burden, and it does disclose real behavior: it opens an interactive 3D stage, decimates oversized meshes for display, and the PNG preview is only a floor. However, it never says whether this mutates the target feature version or merely previews the projected fingerprint, and it says nothing about conflict handling or reversibility — a serious gap for a cherry-pick operation.

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?

The genuine tool behavior is buried under a subscription pitch paragraph and a duplicated, verbose INLINE 3D STAGE block that repeats the stage concept three times. Front-loading the scope sentence is good, but several sentences do not earn their place.

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?

The description covers the viewer side-effect well, which is useful given there is no output schema. It is not complete for the operation itself: no parameter guidance, no mutation semantics, no conflict or failure modes, so an agent could call it with the right argument names but the wrong mental model.

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 coverage is 0% across five parameters, four of them required, and the description explains none of them. It never clarifies the ancestor/source/target three-way relationship, what feature_field selects, or when source_branch_id is needed, leaving an agent to guess at the most consequential inputs.

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?

The opening sentence gives a verb and resource (isolate one modification, apply it, project the target fingerprint), which is more than a restatement of the name. But 'modification' is never tied to 'feature' versus decoration, so it is hard to distinguish from sibling cherry_pick_modification and cherry_pick_decoration_modification without reading the tool name twice. A large share of the text is plan/upsell material rather than purpose.

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?

There is no statement of when to use this over cherry_pick_modification, cherry_pick_decoration_modification, or the list_*_cherry_pick_candidates tools that presumably feed it. The only gating information is 'Requires Kiln Pro', which is a licensing prerequisite rather than a usage rule, and no preconditions about conflicts or candidate resolution are given.

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