Loading ToolBench
MCP server that turns molecule names or SMILES into publication-style 2D structure drawings (PNG/SVG via RDKit) — reaction schemes, mechanisms, spectra. Unofficial, not affiliated with Revvity.
ChemDraw MCP exhibits uneven definition quality across 19 tools. Strengths: all tools have non-empty descriptions (10-200 chars), input schemas are well-formed with explicit type constraints and enums. Weaknesses: parameter descriptions are sparse (many lack explanatory text beyond type), output schemas are not documented in code, error handling is minimal, and response field naming is not evident. The toolkit is domain-specialized (chemistry visualization & calculation) and successfully partitions responsibilities (separate tools for 2D structures, reactions, spectra, calculations), but LLM guidance is inconsistent. Tools like `generate_molecule`, `generate_reaction`, and `calculate_ph` have clear semantic purpose but sparse parameter documentation. Batch operations (`batch_generate`, `compare_molecules`) show good composition patterns. The `lookup` and `predict_spectrum` tools accept broad enum-based topics, reducing per-tool proliferation but potentially obscuring parameter dependencies.
Generate 2D structure drawings for multiple molecules at once
Calculate pharmaceutical content (titration, photometry, acid value, saponification value, iodine value, Karl Fischer water content)
Calculate pH for weak/strong acids and bases, buffer solutions, and buffer recipes
Calculate pharmaceutical solution parameters (weigh-in, concentration, dilution, mixing, molar mass)
Generate side-by-side structure drawings for comparing multiple molecules
Export learning cards as an Anki deck (.apkg file)
Generate a 3D molecular structure visualization
Parameter descriptions are minimal or missing. Many parameters lack explanatory text beyond their type constraint. Example: 'format' in `generate_molecule` states only the enum values but does not explain what PNG vs SVG vs CDXML means for the user's use case.
Output schemas are not documented. No evidence in the source code of documented return types, field names, or structure. LLMs cannot infer what a tool returns; they need explicit schema documentation to plan downstream calls and extract relevant data.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Generate a calibration curve with regression line and R² value
Generate an electron-flow mechanism diagram showing reaction steps
Generate a 2D structure drawing from a molecule name or SMILES string
Generate a reaction scheme showing reactants, products, and conditions
Generate a reaction scope table showing yields and conditions
Generate an alpha plot showing pH-dependent species distribution
Generate a spectrum plot (IR, NMR, or mass spectrum)
Generate a titration curve plot from pH and volume data
Generate a TLC (thin-layer chromatography) plate visualization
Look up chemical data (properties, safety, biochemistry, pathways)
Retrieve comprehensive molecular data from databases
Predict spectroscopic data (IR bands, NMR signals, wavenumber assignment)
Parameter dependencies are undocumented. Tools like `calculate_solution` and `calculate_content` accept a 'topic' enum that determines which parameters in 'parameters' object are valid, but this dependency is not explained in descriptions.
No error handling guidance. Tool descriptions do not explain what errors can occur, whether operations are idempotent, or how to recover from failures. LLMs cannot determine retry strategy or next steps on failure.
Overlapping tool responsibilities. `lookup` and `lookup_molecule_data` both retrieve compound information but differ in interface and return scope. LLMs will struggle to decide between them. Consolidate or clearly distinguish when to use each.
No result limits documented. Tools returning lists (e.g., `lookup_molecule_data`) do not specify maximum result counts or pagination behavior. Without explicit limits, LLMs risk exhausting context or hitting timeouts.
Destructive operation (`export_anki_deck`) does not mention confirmation or dry-run. This tool writes files to persistent storage. No mention of what happens if the deck already exists, whether it overwrites, or whether there is a chance to preview before commit.