Loading ToolBench
A chemistry toolkit MCP server that provides tools for converting between chemical names and SMILES notation, comparing molecules, and working with RDKit molecular objects. Exposes APIs for chemical informatics operations.
ChemDraw Server implements 5 chemistry-focused tools with generally clear naming and documented schemas. All tools follow a verb_noun pattern (name_to_smiles, smiles_to_name, etc.) and include input/output schemas. However, descriptions lack depth and actionability, most are 1-2 sentences and do not explain WHEN to use each tool or what the agent should do with results. Parameter descriptions are minimal. Error handling is not visible in the code. No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY operations. Batch tool (batch_mol_compare_api) is well-designed with array input and per-item error tolerance, but lacks clear guidance on expected output format for partial failures. Overall structure is sound but lacks the polish needed for A-grade production tools.
Batch comparison of multiple molecule pairs. Compares multiple pairs of molecules in a single request. Each pair can contain SMILES, chemical names, or other representations. Continues processing even if individual comparisons fail.
Compares two molecules for exact match and calculates Tanimoto similarity score.
Converts a chemical name to a SMILES string.
Converts a SMILES string to a chemical name.
Converts a SMILES string to an RDKit molecule object with conformer and 3D coordinates.
Descriptions are too brief and lack actionability. Most are 1-2 sentences ('Converts a chemical name to a SMILES string'). They do not explain WHEN to call the tool, what domain problem it solves, or what the agent should do with the output.
Parameter descriptions are missing or trivial. The 'name' parameter in name_to_smiles_api only says 'Chemical name to convert', no guidance on format (IUPAC name? Common name? Partial match?).
No tool annotations present. All 5 tools are READ_ONLY operations but do not declare readOnlyHint in their metadata. This prevents the MCP client from distinguishing safe tools from destructive ones, limiting safe retry strategies and agent planning.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 12 | - | v1 |
Error handling is not visible in the source code. No recovery guidance, error categorization (retryable vs. user-fixable), or actionable error messages. E.g., if an invalid SMILES is passed, what error is returned? Can the agent retry or should it ask the user?
batch_mol_compare_api returns 'pair_id' as optional but does not explain what happens if it is omitted, will results be ordered by input order? Will they be indexed by pair number? Lack of clarity forces the LLM to guess output structure.
Output schemas are not documented in the tool definitions. While FastAPI response_model hints at structure (SmilesResponse, MolCompareResponse, etc.), the actual field names, types, and nesting are not visible in the MCP tool registration. LLMs cannot infer what fields to expect from results.
mol_compare_api description says 'calculates Tanimoto similarity score' but does not explain the range (0 - 1?), interpretation (higher = more similar?), or when the agent should use this vs. batch_mol_compare_api. No guidance on tool selection.