Skip to main content
Glama
glebo309
by glebo309

chemdraw_inspect_annotations

Read-only

Inspect annotations in a ChemDraw document by exporting a read-only snapshot that lists atom/bond IDs, label boxes, curves, and source tokens for electron-flow annotation.

Instructions

Export a read-only snapshot and list atom/bond IDs, measured label boxes, supported native curves and source_token for electron-flow annotation. Supports existing circled charge graphics. Ownership in an annotation recipe is not a native moving attachment guarantee.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A3.5/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description independently says 'read-only snapshot', so there is no contradiction. It adds useful extra context beyond the annotations by enumerating what is returned and warning that 'Ownership in an annotation recipe is not a native moving attachment guarantee.' This goes beyond the structured metadata without needing to restate safety flags.

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

Conciseness4/5

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

The description is compact: one core sentence listing the outputs plus one sentence for the ownership caveat. It front-loads the main purpose before the limitation. Some domain jargon like 'measured label boxes' and 'supported native curves' makes it dense, but every sentence contributes distinct information.

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

Completeness4/5

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

With no output schema, the description acts as the return contract by listing atom/bond IDs, measured label boxes, supported native curves, and source_token. It also covers supported graphics and the ownership limitation. Missing response format details and failure behavior are minor for a simple read-only tool with one required parameter.

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?

The input schema has no descriptions (0% coverage), and the description never mentions document_id or explains how the parameter selects the snapshot target. Since schema description coverage is low, the description needed to compensate, but it does not. The parameter name is self-explanatory, yet the description adds no semantic value beyond it.

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 opening phrase 'Export a read-only snapshot and list atom/bond IDs, measured label boxes, supported native curves and source_token' clearly states a specific verb, resource, and concrete outputs. It is obviously about annotation inspection rather than generic document inspection, though it does not explicitly differentiate itself from sibling tools such as chemdraw_inspect_document or chemdraw_inspect_symbols.

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 phrase 'for electron-flow annotation' implies when the tool is relevant, and the ownership caveat signals a limitation to keep in mind. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling tools are named. Usage context is implied rather than stated.

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