Loading ToolBench
Tools for manipulating SMILES strings and applying SMARTS patterns
SmileyMCP is a specialized chemistry toolkit with 7 tools for SMILES/SMARTS manipulation. Tool naming is clear and verb-based (all start with 'SMILES_' + action), and all tools have descriptions (10-60 chars each). However, descriptions are quite brief and lack context about when to use each tool or dependencies between tools. Parameter descriptions exist but are minimal (15-35 chars). Input schemas are properly defined with correct types (string, array) and parameter descriptions, but output schemas are not documented, callers cannot predict what fields to expect from responses. Error handling is implicit (rdkit exceptions bubble up) with no guidance for recovery. Security is reasonable (read-only and write operations properly marked) but no explicit input validation or error messaging is visible. Tool composition is sound, each tool has a single clear responsibility. Overall, this is a competent but minimal implementation that follows basic conventions without depth.
Add SMILES together (dot-separated SMILES)
Return descriptors for a SMILES
Find maximum common substructure between SMILES
Apply a reaction SMARTS to a SMILES
Remove SMARTS pattern from a SMILES
Replace SMARTS pattern in a SMILES
Check if SMILES contains SMARTS pattern substructure
Output schemas undocumented. Response formats are implicit, LLMs cannot predict what fields/types to expect. For example, SMILES_Info returns CalcMolDescriptors (dict[str, float]) and SMILES_MaxCommonSubstructure returns dict with 'success' and 'smarts' keys, but this structure is not declared in tool metadata.
Tool descriptions are too brief (40-60 chars). They state WHAT the tool does but not WHEN to use it or how it differs from similar tools. E.g., 'Check if SMILES contains SMARTS pattern substructure' lacks context about what substructure matching means or when this is useful vs SMILES_MaxCommonSubstructure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Parameter descriptions are minimal (15-35 chars). 'SMILES string to get descriptors for' and 'SMARTS pattern to search for' lack format hints, constraints, or examples. LLMs cannot infer whether to pass, e.g., a SMILES string with or without stereochemistry markers.
No error handling or recovery guidance. rdkit exceptions (e.g., 'Parsing of smiles=... failed') are raised but not caught or translated into actionable guidance for the LLM. An invalid SMILES string will crash with an unstructured exception rather than a structured error with suggestions.
SMILES_MaxCommonSubstructure naming is unclear. 'MaxCommonSubstructure' does not clearly convey that this is a find/compute operation. Consider 'SMILES_FindMaxCommonSubstructure' or 'SMILES_ComputeMaxCommonSubstructure' to match action-verb conventions.
Tool composition clarity: SMILES_Add and SMILES_Remove modify molecules in place (e.g., self.mol.extend(other.mol)), but the tool functions return strings. The relationship between in-place mutations in the library and stateless HTTP-like tool invocations is unclear. If tools are meant to be stateless, library mutations could be confusing.