chemdraw-mcp

Overview Schema Source Related Servers Discussions Admin

generate_tlc

Generate print-ready TLC plate sketches from Rf values, lane spots, solvent and detection details, exporting PNG or SVG for lab reports.

Instructions

Draw a TLC plate sketch from Rf values as print-ready PNG/SVG files.

Use this whenever the user reports a thin-layer chromatography result ("TLC of my esterification: educt at 0.3, product at 0.65, the co-spot shows both") or asks for the plate sketch a lab report requires. The tool draws exactly the Rf values it is given — it predicts nothing.

The plate is read from the bottom: start line at Rf 0, solvent front at Rf 1, so a spot at Rf 0.8 sits near the top. One lane = one application point with its own caption; a lane can carry several spots, so a co-spot lane showing educt AND product is simply two spots on one lane. Every spot is annotated with its Rf value so the sketch can be read off.

Not this tool for: the reaction scheme of the reaction being monitored (generate_reaction), or a spectrum (generate_spectrum).

Args: lanes: The lanes from left to right, e.g. [{"name": "Edukt", "spots": [{"rf": 0.30, "label": "Säure"}]}, {"name": "Reaktion", "spots": [{"rf": 0.65, "label": "Ester"}]}, {"name": "Co-Spot", "spots": [{"rf": 0.30}, {"rf": 0.65}]}] rf must lie between 0 and 1 — it is a ratio (distance travelled by the substance / distance travelled by the front), so values outside that range are rejected instead of silently clipped. label (optional) names the substance at that spot; intensity (optional, 0…1, default 1) draws a faint spot fainter. title: Shown in the plot title and used for the filename, e.g. "Veresterung Ansatz 2" (free text, can be localized). solvent: Mobile phase / eluent as it goes into the report, e.g. "Toluol/Ethylacetat 8:2" — printed as a caption on the sketch. detection: How the spots were visualized, e.g. "UV 254 nm", "Iod", "Ninhydrin" — printed next to the mobile phase. formats: Output file formats, any of "png", "svg" (default: both). CDXML is not available for plates.

Input Schema

Name	Required	Description	Default
`lanes`	Yes
`title`	No
`formats`	No
`solvent`	No
`detection`	No

Output Schema

Name	Required	Default
`svg`	No
`name`	No
`type`	No	tlc
`files`	No
`lanes`	No
`solvent`	No
`detection`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Nov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it states the tool predicts nothing, rejects out-of-range rf instead of silently clipping, defines plate orientation (start line at 0, front at 1), and notes CDXML is unavailable for plates. These are non-obvious behavioral constraints an agent could not infer elsewhere.

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?

Front-loaded purpose sentence, then geometry, then exclusions, then Args — a clear structure with section labels. It is on the long side and the co-spot explanation is stated twice (narrative and the Not-this-tool block area), but almost every sentence adds information.

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

Completeness5/5

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

For a 5-parameter generation tool with an output schema (so return values need not be described) and no annotations, the definition covers geometry, validation rules, param meanings, and sibling boundaries. Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, yet the Args section explains every parameter: the nested lane/spot structure with a worked JSON example, rf as a ratio with its valid range and rejection behavior, optional label and intensity (with the faint-spot effect), title's dual role as plot title and filename, and formats' allowed values and default. This fully compensates for the empty schema.

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

Purpose5/5

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

Opens with a specific verb+resource+output ('Draw a TLC plate sketch from Rf values as print-ready PNG/SVG files'), and explicitly distinguishes itself from generate_reaction and generate_spectrum. An agent can route this without opening the schema.

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

Usage Guidelines5/5

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

Gives a concrete trigger (user reports a TLC result, with a verbatim example utterance) and a separate 'Not this tool for' block naming the sibling tools to use instead. Both when-to-use and when-not-to-use are covered.

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

Deploy Server