chemdraw_create_lab_style

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

Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. The description aligns by stating it 'writes' and 'does not publish or install anything'. It adds constraints about no embedded fonts, proprietary artwork, code, or local paths, and mentions content hashing, which goes beyond the annotations. However, it does not clarify overwrite behavior or error conditions.

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 three sentences, front-loading the core action and then adding constraints. It is efficient with no wasted words, and the key purpose is stated first. The structure is easy to scan and understand.

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 create operation with 6 parameters, nested objects, and no output schema, the description lacks crucial details. It does not explain what 'preset' contains, how 'version' is used, what 'output_path' should point to, or how settings and references interplay. It partially covers settings and references but leaves major gaps for an agent to correctly invoke the tool.

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?

With 0% schema description coverage, the description must compensate for parameter meaning. It does explain 'settings' sections (grid/reaction/symbols) and 'references' format (names/hashes/descriptions), but completely omits name, version, preset, and output_path semantics. This leaves most parameters underspecified for an agent.

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 description clearly states a specific verb ('write') and resource ('new portable versioned numerical style JSON with content hash'). It also lists key aspects like settings sections and reference format, and explicitly distinguishes from publishing/installing. This differentiates it from siblings like import_style or apply_style, though it doesn't name a specific sibling.

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 implies it is for creating a new style file but does not provide explicit when-to-use guidance or name alternatives. It only notes what it does NOT do (publish/install), which hints at usage boundaries but doesn't give clear direction on when to choose this tool over others like chemdraw_import_style or chemdraw_apply_style.

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