rmx_harmonize

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

With no annotations, the description carries the burden of explaining behavior, and it does explain the main transformations: modes include 'dekink', 'extract handles', and 'supersmooth all'. However, it never states that the glyph's paths are modified in place, whether the operation is reversible, or what the tool returns, which leaves safety-relevant behavior undisclosed.

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 description is well organized: one purpose sentence, a scannable mode list, and a short usage note. It is reasonably compact, but the final sentence about multi-master support could be integrated more tightly with parameter semantics, and the purpose sentence is slightly restated by the usage note.

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 mutating tool with no annotations, no output schema, and 0% schema coverage, the description should cover return values, side effects, and the meaning of master_id. It provides good mode detail but omits these essentials, so an agent cannot fully predict the consequences of invoking it.

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%, so the description must explain the parameters, but it only does so partially. The mode list gives possible values for the 'mode' property, though it never explicitly says these strings map to that parameter, and 'master_id' is never explained except indirectly by the no-multi-master note. 'glyph_name' is inferable from the purpose but not documented as an accepted value.

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 names a specific operation and resource: 'Optimize bezier curves on a glyph using RMX Harmonizer.' It is clear that this tool operates on glyph curve data, and the mode list adds precision. It does not explicitly distinguish itself from sibling tools like rmx_tune, so it misses the top score for sibling differentiation.

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?

The description states when to use it: 'Use after drawing or modifying paths to ensure clean curves.' It also gives a recommended default mode and notes that it works on any glyph without a multi-master requirement. It does not spell out when to prefer a sibling tool or when not to use this tool, so no exclusions are provided.

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