chemdraw_import_file

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

Annotations provide readOnlyHint=false and destructiveHint=false, so the tool is expected to be non-destructive. The description adds useful context by stating the original is never opened for editing and that a private working copy is used. However, it does not disclose the working-copy lifecycle, such as whether a handle is returned, whether the copy persists, or whether it must be closed explicitly.

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 short sentences with no wasted words. The core action and supported file formats are front-loaded, and the safety guarantee is placed in the second sentence. Every sentence contributes essential information.

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 tool with one parameter and no output schema, the description conveys the main purpose and safety boundary. However, it leaves out what happens after the import: what is returned, how to reference the working copy in subsequent calls, and whether there are sequencing constraints with sibling tools like chemdraw_close_working_document. This is a real gap for an agent planning a workflow.

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?

The schema has a single 'path' parameter with 0% description coverage, so the description must define its meaning. The description does this by clarifying that the path refers to a local CDXML, CDX, MOL, or SDF file. It stops short of specifying path syntax or file-existence requirements, but the core parameter semantics are meaningfully supplied.

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 states a specific verb ('Open'), a precise resource ('private working copy of a local CDXML, CDX, MOL or SDF'), and adds an important distinguishing behavior ('Never opens the original for editing'). This clearly separates it from document-creation, style-import, and editing tools in the sibling list.

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 usage: use this to open a local chemistry file in a safe private working copy. However, it never explicitly says when to use this tool versus alternatives, nor does it rule out cases like importing styles or creating new documents, especially given the large sibling set.

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