Skip to main content
Glama
glebo309
by glebo309

chemdraw_grid_document

Create a native grid copy of a ChemDraw document, arranging molecules into uniform cells with compound IDs and yields while preserving chemistry and orientation.

Instructions

Create a native scope grid COPY. Analyze first for source_token and IDs. Cells in requested order: {compound_id:3a,fragment_ids:[ID],caption_id:ID|null,yield_percent:82|null}. Every fragment and existing page caption needs one owner. 0% remains visible; missing yield omitted. Multi-fragment compounds translate together after normalization. Native measured molecular+caption bounds determine uniform cells. Columns auto-fit if omitted; overflow fails, never shrinks individual molecules. Requires chemistry extra. No reactions/page graphics/nested groups/native symbol graphics. Preserves orientation and chemistry, adds caller-supplied compound IDs/yields, verifies native saved page fit and alignment. Yields are not experimentally validated. Visual review required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cellsYes
h_gapNo
v_gapNo
widthNo
heightNo
marginNo
pixelsNo
presetNohouse
columnsNo
label_gapNo
output_dirYes
document_idYes
expected_source_tokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

B3.1/5.0
Behavior4/5

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

Since annotations are all false (readOnlyHint=false, openWorldHint=false, destructiveHint=false), the description carries the full burden of behavioral disclosure. It reveals several important behaviors: '0% remains visible; missing yield omitted,' 'overflow fails, never shrinks individual molecules,' 'Columns auto-fit if omitted,' and 'Multi-fragment compounds translate together after normalization.' It also discloses that 'Yields are not experimentally validated' and that verification of native saved page fit occurs. These are substantive disclosures beyond the annotations, though some phrases (e.g., '0% remains visible') are ambiguous.

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

Conciseness2/5

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

The description is a dense, run-on paragraph with no paragraph breaks or bullet points. It front-loads the main purpose but then continues with a stream of clauses covering cells, ownership, translation, measurement, columns, exclusions, and verification, all in a single block. While every sentence contains information, the lack of structure makes it hard to parse, and it is unnecessarily verbose for what could be organized into clear sections.

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

Completeness2/5

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

Given the tool's complexity (13 parameters, no output schema, no parameter descriptions in the schema), the description is incomplete. It fails to explain the purpose of expected_source_token, output_dir, or the numeric gap/margin parameters, and it gives no indication of return values or error behavior. The description provides some insight into cells and columns but leaves many essential calling details unresolved, making it insufficient for an agent to correctly invoke the tool without additional knowledge.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains the structure of the 'cells' parameter ('Cells in requested order: {compound_id:3a,fragment_ids:[ID],caption_id:ID|null,yield_percent:82|null}') and mentions 'Columns auto-fit if omitted' for the columns parameter. However, it does not explain document_id, output_dir, expected_source_token, h_gap, v_gap, width, height, margin, pixels, preset, or label_gap. With 13 parameters and only two partially addressed, the description falls far short of covering parameter semantics.

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

Purpose4/5

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

The description opens with a clear action: 'Create a native scope grid COPY.' It specifies the resource (scope grid) and the operation (create a copy). It also mentions 'Preserves orientation and chemistry' and 'adds caller-supplied compound IDs/yields,' which further clarifies the function. However, it does not explicitly contrast with sibling tools like chemdraw_build_scope_job or chemdraw_plan_scope_job, so some ambiguity remains about when this specific grid-copy tool is preferred.

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

Usage Guidelines3/5

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

The description provides some usage context: it states 'Requires chemistry extra' and lists exclusions ('No reactions/page graphics/nested groups/native symbol graphics'), which imply when not to use it. It also mentions 'Visual review required' as a follow-up expectation. However, it never names alternative tools or gives explicit 'use this instead of X' guidance, leaving routing decisions to the agent.

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