Chat → chemische Struktur. Ein MCP-Server für Claude Desktop: Sie beschreiben ein Molekül, eine Reaktion oder ein Laborergebnis in einfachen Worten, und er zeichnet die Abbildung — ein druckfertiges PNG/SVG, lokal mit RDKit gerendert, plus eine interaktive Vorschau im Chat. „Zeichne Aspirin" ist bereits ein vollständiger Befehl.
Gebaut für Pharmazie- und Chemiestudierende, die zu viel Zeit damit verbringen, auf Hexagone zu klicken. 20 Tools decken ab, was ein Bericht oder eine Folie tatsächlich braucht: Strukturen, Reaktionsschemata, schrittweise Mechanismen, Substratbreiten-Abbildungen, DC-Platten, Titrationskurven, schematische Spektren, Substanzdatenblätter, Ph.-Eur.-Gehaltsbestimmungen und Anki-Decks.
Was es Sie kostet: ein Installationsbefehl. Apache-2.0, kein API-Schlüssel, keine Anmeldung für den Server, keine ChemDraw-Lizenz — Sie brauchen Claude Desktop und uv, alles andere wird einmalig geholt. Das Rendering läuft vollständig auf Ihrem Rechner; nur die Namensauflösung und die Datenbankabfragen erreichen das Internet. ChemDraw-CDXML ist ein optionales Zusatzformat für Leute, die dort weiterbearbeiten möchten, niemals eine Voraussetzung.
„Zeichne Koffein" — druckfertiges PNG, erzeugt von generate_molecule:
„Zeige die Fischer-Veresterung von Ethanol mit Essigsäure" —
generate_reaction rendert das Schema mit den Bedingungen über dem Pfeil,
live im Chat-Panel:
„Zeige den Mechanismus der Fischer-Veresterung Schritt für Schritt" —
generate_mechanism rendert gebogene Elektronenfluss-Pfeile im interaktiven
Panel:
„Erstelle eine Substratbreiten-Abbildung meiner Suzuki-Kupplungen: 3a 92 %, 3b 88 % nach 12 h,
3c 64 % mit ee 94 % und dr 10:1, 3d 71 %" — generate_scope_table setzt die
allgemeine Gleichung mit ihren Bedingungen oben und die Produkte darunter, auf
einer gemeinsamen Bindungslänge und einer gemeinsamen Beschriftungs-Baseline:
„Skizziere das IR-Spektrum von Ethylacetat" — generate_spectrum (zeichnet die
Peaks, die ihm übergeben werden, mit achsen-Konventionen pro Typ):
„DC meiner Veresterung: Edukt bei 0,30, Produkt bei 0,65, der Co-Spot zeigt
beides, etwas Edukt ist übrig" — generate_tlc zeichnet die Platte, die der
Laborbericht verlangt, mit Fließmittel und Detektion als Beschriftung:
„Zeige Koffein in 3D" — generate_3d bettet das Molekül ein (ETKDG + Kraftfeld)
und öffnet einen per Ziehen drehbaren Kugel-Stab-Viewer im Chat-Panel:
„Was unterscheidet Ibuprofen von Naproxen und Ketoprofen?" —
compare_molecules hält das gemeinsame Grundgerüst (MCS) neutral und hebt
alles hervor, was sich unterscheidet:
„Titrationskurve von Phosphorsäure mit NaOH, Phenolphthalein als
Indikator" — generate_titration_curve berechnet den pH-Wert aus der exakten
Ladungsbilanz, mit Äquivalenzpunkten, Pufferpunkten (pH = pKa) und der
Indikatorbande; sein Geschwister generate_species_distribution zeigt, welche
Protonierungsspezies bei jedem pH-Wert dominiert:
„Erstelle ein Anki-Deck mit wichtigen Molekülen und öffne es in Anki" —
export_anki_deck baut ein importfertiges .apkg
mit eingebetteten gerenderten Strukturen; mit dem optionalen AnkiConnect-Add-on
landen die Karten direkt im laufenden Anki, ohne Klicks:
Related MCP server: ChemMCP
Alle 20 Tools, die der Server bereitstellt. Dateien werden nach ~/ChemDraw-Output/
geschrieben; jedes Zeichen-Tool liefert außerdem eine Live-Vorschau für das
In-Chat-Panel.
Strukturen und Schemata
generate_molecule — Name/SMILES → 2D-Struktur als PNG + SVG
(optional CDXML), mit Eigenschaften, funktionelle-Gruppen-Erkennung und
Lipinski-Regel-der-Fünf-Prüfung
batch_generate — eine ganze Liste von Strukturen in einem Aufruf
generate_reaction — Edukte + Produkte + Bedingungen → Reaktionsschema
mit den Bedingungen über dem Pfeil
generate_mechanism — Mechanismen mit gebogenen Pfeilen (SN1, SN2,
Fischer-Veresterung) Schritt für Schritt
generate_scope_table — die Substratbreiten-Abbildung der
Methodenliteratur: die allgemeine Gleichung mit ihren Bedingungen oben,
darunter ein Raster von Produkten, jedes mit Kennung („1a") und Ausbeute
(„78 %") plus optional ee/dr/Zeit. Alle Strukturen teilen eine Bindungslänge,
alle Beschriftungen eine Baseline; ein Eintrag, der nicht aufgelöst werden
kann, wird gemeldet, nicht fatal
compare_molecules — 2–4 Strukturen nebeneinander, Unterschiede
hervorgehoben, gemeinsames Grundgerüst (MCS) neutral
generate_3d — drehbares 3D-Kugel-Stab-Konformer im Chat-Panel
(ETKDGv3 + Kraftfeld) plus SDF-Export
Laborergebnisse und Analytik
generate_spectrum — schematische Spektren aus Peaklisten (IR, NIR,
Raman, UV/Vis, Fluoreszenz, ORD, CD, ¹H/¹³C-NMR, MS) mit achsen-Konventionen
pro Typ — zeichnet vorgegebene Peaks, sagt keine Spektren voraus
generate_tlc — DC-Platten-Skizze aus Rf-Werten: Startlinie unten,
Lösungsmittelfront oben, eine beschriftete Bahn pro Auftragungspunkt
(Edukt / Reaktion / Co-Spot), Rf an jedem Fleck annotiert, Fließmittel
und Detektion als Beschriftung gedruckt — die Skizze, die ein Laborbericht
verlangt
generate_titration_curve — pH-Wert vs. Titrantvolumen aus der exakten
Ladungsbilanz, mit Äquivalenzpunkten, Pufferpunkten (pH = pKa) und
Indikator-Umschlagsbande
generate_species_distribution — Anteile der Protonierungsspezies
über den pH-Wert (Henderson–Hasselbalch) mit markierten pKa-Übergängen
generate_calibration_curve — Ausgleichsgerade durch Ihre
Standards, und die Unbekannten werden davon abgelesen, so wie Sie es mit
einem Lineal tun würden. Eine Probe außerhalb des kalibrierten Bereichs wird
als extrapoliert gekennzeichnet, statt stillschweigend berichtet zu werden;
Nachweis- und Bestimmungsgrenzen (DIN 32645) kommen für die
Validierungsfrage mit
Bänkerrechnen (die Zahl und der Rechenweg — ein Laborbericht verlangt beides)
calculate_solution — was man einwiegt (m = c · V · M), was man
tatsächlich erhalten hat, Verdünnungen (C₁V₁ = C₂V₂ mit ausgeschriebenem
Lösungsmittelvolumen), das Mischungskreuz und molare Massen einschließlich
Hydraten wie CuSO₄·5H₂O.
Warnt, wenn die berechnete Einwaage unter das fällt, was eine
Analysenwaage auflöst — dann ist das Verdünnen einer größeren Einwaage der
richtige Schritt
calculate_content — eine Gehaltsbestimmung, wie das Protokoll sie
will: ein Gehalt pro Messung → Grubbs-Ausreißertest → Mittelwert, s, RSD
→ t-Test gegen den deklarierten Gehalt. Titration (mit Titerbestimmung
aus Referenztitrationen) und Photometrie, plus die Fettkennzahlen
(Säure-, Verseifungs-, Ester- und Iodzahl) und der Karl-Fischer-Wassergehalt
als weitere methods
calculate_ph — schwache und starke Säuren und Basen, Puffer und
Pufferrezepturen bis hin zu einwiegbaren Massen. Gelöst über die exakte
Ladungsbilanz mit der Lehrbuch-Näherung daneben gedruckt: Wo die beiden
abweichen, hat die Näherung ihre Annahmen verloren und sagt das auch.
10⁻⁸ M HCl ergibt pH 6,98, nicht 8
Substanzdaten (Online-Abfragen)
lookup — die Fakten als Text, ein topic pro Frage:
properties (Summenformel, Masse, CAS, InChIKey — die Voreinstellung),
safety (GHS-Gefahrenhinweise, Piktogramme, Signalwort), physical
(Schmelz-/Siedepunkt, Löslichkeit, Dichte), biochem (ChEBI-Klassifikation
plus zugehörige UniProt-Einträge), pathway (Stoffwechselwege aus KEGG)
lookup_molecule_data — PubChem + GHS kombiniert zu einem Datenblatt
für das In-Chat-Panel, Struktur inklusive
predict_spectrum — welche IR-Banden eine Struktur zeigen sollte (mit
Intensität und Bandenform), wozu eine gemessene Wellenzahl gehören könnte,
und wie viele ¹H-Signale mit welchem Integralverhältnis zu erwarten sind.
Deterministisch, also sagt es, was es nicht kann: keine chemischen
Verschiebungen in ppm, und diastereotope Protonen werden als ein Signal
gezählt
Prüfungsvorbereitung
export_anki_deck — Karteikarten als importfertiges Anki-.apkg:
Struktur↔Name-Übungen (optional umgekehrt: eine Notiz, beide Richtungen),
Lückentext-Karten, Identitäts-/Nachweisreaktionen, Spektrum-Bandenzuordnung —
mit eingebetteten gerenderten Bildern, Tags pro Karte,
Parent::Child-Unterdecks; der erneute Export eines Decks aktualisiert
Karten, statt sie zu duplizieren. Optionale Zustellung direkt ins laufende
Anki über das AnkiConnect-Add-on. Übergeben Sie curated_deck_id statt
eigener Karten für ein kleines, formelverifiziertes Starter-Deck (klassische
Analgetika, Ph.-Eur.-Identitätsreaktionen)
Jedes Tool gehört zu einem von fünf Bereichen — zeichnen, Laborgrafik,
nachschlagen, rechnen, Anki — und jedes sagt, wofür es nicht gedacht ist, in
beide Richtungen, sodass „Zeichne Aspirin" nicht in einem
Substratbreiten-Raster landen kann und „Welchen pH-Wert hat mein Puffer?"
nicht in einem Plot-Tool. Ein Tool steht außerhalb: save_png ist die
Serverhälfte des Export-Buttons des Panels, wird aufgerufen, wenn Sie ihn
klicken, niemals allein.
Zwei optionale Vault-Tools (search_vault, read_vault_entry) erscheinen nur,
wenn CHEMDRAW_VAULT_PATH gesetzt ist; ohne es stellt der Server genau die
20 Tools oben bereit.
formats — standardmäßig ["png","svg"]; zusätzlich "cdxml" für
generate_molecule, generate_reaction und batch_generate. Die
Abbildungs-Werkzeuge (generate_scope_table, generate_tlc,
generate_spectrum) lehnen CDXML mit einer klaren Fehlermeldung ab,
statt etwas Bedeutungsloses zu schreiben.
abbreviate_groups=True — zeichnet häufige Substituenten als die
Beschriftungen, die Chemiker tatsächlich schreiben: Ph, Bn, OMe, OAc, tBu,
CO₂H, Boc, Ts, TBS. Lohnt sich immer dann, wenn Zellen klein werden — eine
Scope-Abbildung bleibt lesbar, weil nur das ausgeschrieben wird, was sich
zwischen den Substraten unterscheidet. Verfügbar bei generate_molecule,
generate_reaction, generate_scope_table, batch_generate.
render_style — ein benannter Look statt eines Haufens von
Render-Parametern, bei denselben vier Werkzeugen. "compact" (dünne
Bindungen, begrenzte Beschriftungsgröße, enge Ränder) für eine kleine
Abbildung in einem zweispaltigen Layout, "presentation" (doppelte
Bindungsbreite, minimale Schriftgröße, mehr Innenabstand) für eine
Vorlesungsfolie, "grayscale" für den Schwarzweißdruck, wo Rot und Blau
sonst zu zwei ununterscheidbaren Grautönen würden. Leer bedeutet den
Standard-Look, unverändert.
annotate_stereo=True — druckt CIP-Deskriptoren (R/S, E/Z) auf die
2D-Zeichnung (generate_molecule, batch_generate).
Drei Wege hinein; wähle einen. Option 1 und 2 gehen idempotent in die Konfiguration ein — sichere sie zuerst und lasse jeden anderen MCP-Server, den du konfiguriert hast, unangetastet. Starte danach Claude Desktop neu und frage: „Koffein zeichnen".
Option 1 — Repository klonen (empfohlen, wenn du den Code lesen oder ändern willst; installiert uv, falls fehlend, synchronisiert Abhängigkeiten, registriert den Server):
git clone https://github.com/jurimaxam-dotcom/chemdraw-mcp.git
cd chemdraw-mcp && ./install.shOption 2 — von PyPI, ohne Klon (benötigt uv):
uv tool install chemdraw-mcp
chemdraw-installchemdraw-install schreibt den Claude-Desktop-Eintrag für dich, unter
Verwendung des absoluten Pfads des installierten Launchers, und gibt den
Startbefehl aus, den es registriert hat.
Option 3 — Konfiguration von Hand bearbeiten. Füge dies zu
claude_desktop_config.json unter mcpServers hinzu (macOS:
~/Library/Application Support/Claude/claude_desktop_config.json):
"chemdraw-tool": {
"command": "/opt/homebrew/bin/uvx",
"args": ["chemdraw-mcp"]
}Die eine Falle, die jede manuelle Installation scheitern lässt: Claude Desktop startet MCP-Server nicht aus einer Login-Shell — es verwendet den minimalen GUI-PATH. Ein nacktes
"uvx"oder"uv"kann dort nicht aufgelöst werden, und der Server startet nicht, ohne dies zu sagen. Setze immer den absoluten Pfad, denwhich uvxauf deiner Maschine ausgibt, incommandein. Option 1 und 2 erledigen das für dich.
Eine Java-Laufzeit (z. B. brew install openjdk) ermöglicht es
OPSIN, systematische IUPAC-Namen
offline zu parsen — auch solche, die keine Datenbank indexiert. Ohne Java
fährt der Resolver einfach mit der Online-Suche über PubChem/NCI fort.
Das AnkiConnect-Add-on ermöglicht es export_anki_deck, Karten direkt
in ein laufendes Anki zu schieben. Ohne es bekommst du die .apkg-Datei
und importierst sie selbst.
ChemDraw (macOS) ist nie erforderlich: Fordere formats=["cdxml"] an
und öffne die Datei selbst, wenn du dort weiterbearbeiten willst.
chemdraw-doctor # after "uv tool install chemdraw-mcp"
uv run chemdraw-doctor # in the cloned repo
uvx --from chemdraw-mcp chemdraw-doctor # without installing anythingDas ist das Erste, was man versuchen sollte — es verwandelt „der Server tut
nichts" in eine benannte Ursache. Er prüft die sechs Dinge, die den Server
im Chat tot aussehen lassen (RDKit-Rendering, die Java/OPSIN-Laufzeit, den
uv-Pfad, den Claude-Desktop-Eintrag, die Namensdatenbanken, das
Ausgabeverzeichnis) und druckt für jedes Problem den genauen Befehl, der es
behebt. Drei Stufen werden unterschieden: [OK], [LIMITED] (funktioniert,
aber eingeschränkt) und [FAIL] (defekt); [NOTE] markiert Prüfungen, die
einfach nicht zutreffen, etwa wenn Claude Desktop nicht installiert ist. Der
Exit-Code bleibt 0, solange der Server nutzbar ist, sodass er in Skripten
laufen kann. (Bei einer PyPI-Installation melden die uv- und
Claude-Desktop-Prüfungen [NOTE] — sie betreffen den
Repository-Installer.)
Vorab genannt, damit dich in einem Bericht nichts überrascht:
Java ist optional, und das hat seinen Preis. Ohne JRE wird OPSIN übersprungen und Namen werden online über PubChem/NCI aufgelöst — die Namenssuche benötigt also eine Internetverbindung und funktioniert nur für Namen, die diese Datenbanken indexieren. SMILES-Eingabe berührt das Netzwerk nie.
Spektren sind schematisch. generate_spectrum zeichnet die Peaks,
die ihm übergeben werden, mit den richtigen Achsenkonventionen für den
Spektrentyp. Es misst nichts und sagt nichts voraus — wenn die
Peak-Werte aus dem Chat stammen und nicht von deinem Instrument,
verifiziere sie, bevor sie in einen Bericht gelangen.
TLC-Intensität ist ein Zeichenhinweis. Die optionale intensity
(0…1) macht einen Fleck auf der Skizze blasser. Sie ist keine
Densitometrie und hat keine quantitative Bedeutung.
CDXML ist ein Nebenpfad. Es wird aus dem RDKit-Molekül geschrieben und im Round-Trip validiert, aber PNG/SVG sind die primären Ausgaben und diejenigen, die die Pixeltests abdecken. CDXML ist standardmäßig deaktiviert und auf Strukturen und Reaktionsschemata beschränkt — TLC-Platten, Scope-Abbildungen und Spektren lehnen es ab.
3D ist ein Konformer. generate_3d bettet mit ETKDGv3 ein und
optimiert mit MMFF (UFF als Fallback). Das ist eine plausible Geometrie
zum Anschauen, keine Konformationssuche und keine Energieaussage.
Die ChemDraw-Brücke ist nur für macOS und benötigt ein lokal installiertes ChemDraw. Alles andere funktioniert ohne es.
name / SMILES
│
▼
resolver ──► OPSIN (systematic IUPAC names, offline) ──► PubChem / NCI (names) · direct parse (SMILES)
│
▼
RDKit 2D coordinates ──► validation (sanity, round-trip)
│
├──► image_export → PNG + SVG files (primary, offline)
├──► svg_renderer → interactive chat preview (MCP App resource)
└──► cdxml_writer → ChemDraw CDXML (optional, on request)Python 3.11+, Paketmanager uv.
uv sync # backend deps
cd chemdraw_tool/ui && npm install && npx playwright install chromium # frontend, once
./test.sh # the gate: pytest + JS unit + headless-Chromium e2eÜber 600 Tests, test-first geschrieben. Der E2E-Test rastet ein echtes RDKit-SVG in headless Chromium ein und vergleicht es mit einem exakten Pixel-Schnappschuss — der Exportpfad und die Vorschau im Chat werden an denselben Zeichenkonstanten gemessen.
Apache-2.0 — siehe LICENSE. Copyright 2026 jurimaxam-dotcom.
Haftungsausschluss: Dies ist ein inoffizielles, unabhängiges Projekt, das weder mit Revvity verbunden ist noch von Revvity unterstützt wird. ChemDraw ist eine Marke von Revvity Signals Software, Inc. Dieses Tool enthält ChemDraw nicht und benötigt es nicht; es kann optional Dateien im offenen CDXML-Format exportieren.
Draw several individual compounds as separate PNG/SVG files and panels.
Failed names are reported in failed while successful structures are returned. Pass English or IUPAC names, or SMILES.
Not this tool for: one compound (use generate_molecule), structural differences (use compare_molecules), or a reaction scheme (use generate_reaction).
Args: molecules: List of English/IUPAC compound names or SMILES strings. formats: Output file formats, any of "png", "svg", "cdxml" (default: ["png", "svg"]). Include "cdxml" ONLY when the user wants to edit the structures in ChemDraw. abbreviate_groups: Set True to draw common substituents as short labels (Ph, Bn, OAc, OMe, CO2H, tBu, Boc, Ts …) instead of full skeletons. Applies to every molecule in the batch, so a series of structures stays visually consistent. render_style: Named look applied to every molecule in the batch. Empty = standard style. "compact" for small printed figures, "presentation" for slides, "grayscale" for grayscale printing.
| Name | Required | Description | Default |
|---|---|---|---|
| formats | No | ||
| molecules | Yes | ||
| render_style | No | ||
| annotate_stereo | No | ||
| abbreviate_groups | No |
| Name | Required | Description |
|---|---|---|
| type | No | |
| failed | No | |
| molecules | No | |
| cdxml_paths | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden and performs well. It explicitly details a key behavioral trait: failed names are reported while successful structures are returned. It also explains the conditional use of 'cdxml' for ChemDraw editing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool definition is structured logically, starting with the core function, then providing limitations, and finally detailing parameters. Every section is tightly written and efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of handling batch processing, multiple formats, and custom rendering, the description is remarkably complete. It provides all the necessary context and constraints for an agent to invoke the tool correctly despite the sparse structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite having 0% schema description coverage, the description provides high-value semantic context for every parameter. For instance, it explains the functional difference between 'abbreviate_groups' (consistency) and 'render_style' (use case for printing/slides), adding meaning far beyond the schema data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The purpose is highly specific: drawing multiple individual compounds as PNG/SVG files and panels. It clearly distinguishes itself from sibling tools by stating it is not suitable for single compounds (use generate_molecule), reaction schemes, or structural comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool explicitly forbids certain use cases, detailing that it should not be used for single molecules, structural differences, or reaction schemes. It provides direct redirection to the correct alternative sibling tool for each specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-4 molecules side by side with their DIFFERENCES highlighted.
Computes the maximum common substructure (MCS): the shared scaffold stays neutral, everything outside it is highlighted — ideal for teaching drug classes ("what distinguishes ibuprofen from naproxen?"), homologous series or derivatives.
Use this when the user wants to compare structures, see differences between compounds, or study a drug class.
Reach for it in conversation too, not only on request: the word "difference" in a question about two substances is the trigger. Answering "what distinguishes ibuprofen from naproxen?" in prose leaves the reader to find the difference in two separate pictures — this figure marks it.
Not this tool for: a single structure (generate_molecule), or several structures that are merely to be drawn rather than contrasted (batch_generate).
Args: structures: 2-4 English/IUPAC names or SMILES strings. labels: Optional display names under each panel (localizable). title: Optional heading for the comparison (localizable).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| labels | No | ||
| structures | Yes |
| Name | Required | Description |
|---|---|---|
| svg | No | |
| name | Yes | |
| type | No | |
| files | No | |
| notes | No | |
| subtitle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full load — it discloses the algorithmic behavior (MCS computed, shared scaffold kept neutral for contrast) and that the result is a figure rather than prose, which is meaningful behavioral context. It stops short of stating failure behavior for unresolvable names or whether a file is written, which are the remaining gaps for an annotation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core definition, then usage, then exclusions, then args — a rational order with clear sectioning. The conversational-trigger paragraph is slightly padded and repeats the ibuprofen/naproxen example already used earlier, costing a point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description covers scope, exclusions, and all three parameters. The only thin spot is edge-case behavior — what happens with fewer than 2 structures, more than 4, or an unresolvable name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: structures accepts 2-4 English/IUPAC names or SMILES, labels are per-panel display names that are localizable, and title is an optional localizable heading. This adds real meaning beyond the bare schema types and closes the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compare 2-4 molecules side by side') and explains the mechanism (maximum common substructure with non-shared parts highlighted), which tells the agent exactly what the output depicts. It also names the siblings it is not (generate_molecule, batch_generate), so it is distinguishable without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers ('user wants to compare structures', 'study a drug class'), an explicit not-for clause with named alternatives for both exclusions, and even a conversational trigger word ('difference'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an Anki flashcard deck (.apkg) with rendered chemistry images.
Use this whenever the user wants flashcards, Anki cards or a study deck for molecules, reactions (e.g. pharmacopoeia identity tests) or spectra. A stated intention to learn or an exam coming up is the same request: offer a deck and write the cards yourself.
Two ways to fill the deck. Either pass cards you wrote yourself, or
pass curated_deck_id for a ready-made, formula-verified starter deck:
"analgesics-structures": structure → name drills for 8 classic analgesics (NSAIDs, paracetamol, morphine, celecoxib).
"pheur-identity-basics": classic Ph.Eur. identity tests — reagent, observation and reaction scheme where it helps.
The tool renders the images — YOU supply the card content from your knowledge. Each card side carries text plus at most ONE visual: structure (name or SMILES), reaction ({reactants, products, conditions}) or spectrum ({spectrum_type, peaks, title}). Proven types: structure↔name, identity reactions (question front, scheme back), functional-group recognition, band assignment, name drills.
Re-exporting under the SAME deck name updates existing cards instead of duplicating them — the front identifies the card.
Options: reversed=true drills both directions (one note, two cards); cloze=true makes fill-in-the-blank cards (front.text carries {{c1::...}}, back.text becomes the extra note). "Parent::Child" nests subdecks.
IMPORTANT: structures take English/IUPAC names or SMILES; card TEXTS may be localized. Never deliver via AnkiConnect unless asked.
Args: deck_name: Deck name, also the filename; re-use it to update a deck. Ignored when curated_deck_id is set. cards: The flashcards. Fronts unambiguous, explanations on the back. default_tags: Tags added to every card. deliver: "apkg" (file only), "open" (also opens it in Anki, macOS) or "ankiconnect" (imports via the AnkiConnect add-on). curated_deck_id: "analgesics-structures" or "pheur-identity-basics".
| Name | Required | Description | Default |
|---|---|---|---|
| cards | No | ||
| deliver | No | apkg | |
| deck_name | No | ||
| default_tags | No | ||
| curated_deck_id | No |
| Name | Required | Description |
|---|---|---|
| file | No | |
| name | Yes | |
| type | No | |
| cards | Yes | |
| media | Yes | |
| fronts | No | |
| delivery | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: same deck name updates rather than duplicates (front is the key), `deck_name` is ignored when `curated_deck_id` is set, `deliver` has three concrete modes, `reversed` produces one note/two cards, `cloze` changes what front/back mean, and 'Parent::Child' nests subdecks. These are non-obvious side effects an agent could not infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded and segmented: purpose first, then triggers, then the two fill paths, then card anatomy, then options, then per-argument notes. Every paragraph answers a distinct question an agent would otherwise have to guess at.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested-card export tool with 5 params, the description covers card construction, proven card types, update semantics and delivery modes; the output schema relieves it of explaining return values. Minor gap: it doesn't say what happens if neither `cards` nor `curated_deck_id` is supplied, nor where the .apkg file is written.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% at the top level, but the Args block documents all five parameters, including the enum-like values for `deliver` and `curated_deck_id` that the schema does not constrain. The card-side constraint (text plus at most ONE visual, with the shapes of structure/reaction/spectrum) supplies the nesting semantics the schema leaves implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact: 'Export an Anki flashcard deck (.apkg) with rendered chemistry images.' It also clarifies the division of labour (tool renders images, the agent supplies card content), which no sibling tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the triggering situations (flashcards, study deck, exam coming up, intent to learn) and routes between the two fill modes: own `cards` vs `curated_deck_id`. It also states an exclusion ('Never deliver via AnkiConnect unless asked') and names both curated deck IDs with their contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw one compound as a 2D structure — the default for a single substance.
Writes PNG/SVG files and returns an interactive panel with the structure, properties and functional groups. A bare compound name ("caffeine") also means this tool, and so does a question about why one compound behaves as it does (acidity, solubility) — the answer is in its structure. No ChemDraw required. A Fischer or Haworth projection of a sugar or amino acid, or a drawing with all H atoms, is this tool too: set view to "fischer", "haworth" or "all_h".
Not this tool for: several individual structures (use batch_generate), structural differences (use compare_molecules), a reaction scheme (use generate_reaction), or a data sheet (use lookup_molecule_data).
Pass English or IUPAC names, or SMILES; use label for a localized display name.
Args: name_or_smiles: English/IUPAC compound name or SMILES string. label: Display name shown below the structure (may be localized). formats: Any of "png", "svg", "cdxml" (default: png + svg). Add "cdxml" only when the structure is to be edited in ChemDraw. annotate_stereo: True prints CIP descriptors (R/S, E/Z) at each stereocenter. abbreviate_groups: True draws common substituents as the short labels chemists write by hand (Ph, Bn, OAc, OMe, CO2H, NO2, tBu, Boc, Ts, TMS). The chemistry is unchanged; no hover tooltips in the panel. render_style: "" standard · "compact" thin bonds for small print · "presentation" thick bonds for slides · "grayscale" b/w palette. stereo_variants: True returns every stereoisomer of the open centers (max 3) as a pick list instead of a drawing; only on request. view: "fischer"/"haworth"/"all_h" opens on that drawing, only if the user names it.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | ||
| label | No | ||
| formats | No | ||
| render_style | No | ||
| name_or_smiles | Yes | ||
| annotate_stereo | No | ||
| stereo_variants | No | ||
| abbreviate_groups | No |
| Name | Required | Description |
|---|---|---|
| svg | No | |
| name | No | |
| type | No | |
| atoms | No | |
| files | No | |
| views | No | |
| message | No | |
| viewSvg | No | |
| lipinski | No | |
| subtitle | No | |
| viewAtoms | No | |
| candidates | No | |
| cdxml_path | No | |
| properties | No | |
| stereoNote | No | |
| initialView | No | |
| viewRequest | No | |
| projectionNote | No | |
| stereoWarnings | No | |
| functionalGroups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the file side effects (writes PNG/SVG), the return artifact (interactive panel with structure, properties, functional groups), and non-obvious behavioral consequences per flag (abbreviate_groups kills hover tooltips; stereo_variants returns a pick list instead of a drawing). It stops short of error behavior for invalid names/SMILES or whether existing files are overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Roughly front-loaded: purpose first, then routing, then args. Minor redundancy — the fischer/haworth/all_h options are stated once in prose and again under view — and 'No ChemDraw required' is filler, but no sentence is genuinely wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Eight parameters, no annotations, and an output schema. The description covers routing, all parameter semantics, side effects, and the return artifact, so an agent can call it correctly without reading anything else.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply all meaning, and it does: formats lists allowed values and the default, view names its three accepted values, render_style enumerates all four modes with intent, and the boolean flags each explain their effect (CIP R/S and E/Z labels; abbreviation set Ph/Bn/OAc/...; max 3 stereoisomer pick list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource ('draw one compound as a 2D structure') plus its scope ('the default for a single substance'). It then enumerates non-obvious inputs that also route here (bare compound name, a behavior question like acidity/solubility, Fischer/Haworth projections) and names each sibling that handles the other cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
An explicit 'Not this tool for:' block routes to batch_generate (several structures), compare_molecules (differences), generate_reaction (reaction schemes) and lookup_molecule_data (data sheets). Positive triggers are also given, including indirect ones like a question about why a compound behaves as it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a reaction scheme from reactants, products and conditions.
Writes PNG/SVG files and returns a panel with conditions above and below the arrow. arrow: "forward" (→), "equilibrium" (⇌, reversible) or "retro" (⇒). Use it when explaining a reaction as well as for explicit drawing requests. This draws the net reaction, without step-by-step electron-flow mechanisms. Pass English or IUPAC compound names, or SMILES.
Not this tool for: one compound or a property of one compound such as its acidity (use generate_molecule), independent structures (use batch_generate), or structural differences (use compare_molecules).
Args: reactants: List of English/IUPAC reactant names or SMILES strings. products: List of English/IUPAC product names or SMILES strings. conditions: Text above the arrow (e.g. 'H2SO4, 0-5 °C'); formula digits are subscripted, a line break starts a new line. conditions_below: Text under the arrow (e.g. 'reflux, 2 h'). arrow: "forward" (→), "equilibrium" (⇌, reversible reaction) or "retro" (⇒, retrosynthesis: target as reactants, precursors as products). name: Display name for the reaction step (can be localized). formats: Any of "png", "svg", "cdxml" (default: png + svg). Add "cdxml" only when the scheme is to be edited in ChemDraw. abbreviate_groups: True draws common substituents as short labels (Ph, OAc, OMe, CO2H, tBu, Boc …); the CDXML keeps full structures. render_style: "" standard · "compact" small print · "presentation" slides · "grayscale" b/w palette. coefficients: One integer per species, reactants then products ([2, 1, 2] draws 2 H2 + O2 → 2 H2O). Set only when the user asks for a balanced equation; otherwise draw as given — the panel's "Apply coefficients" button sets them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| arrow | No | forward | |
| formats | No | ||
| products | Yes | ||
| reactants | Yes | ||
| conditions | No | ||
| coefficients | No | ||
| render_style | No | ||
| conditions_below | No | ||
| abbreviate_groups | No |
| Name | Required | Description |
|---|---|---|
| name | No | |
| type | No | |
| arrow | No | |
| files | No | |
| balance | No | |
| request | No | |
| products | No | |
| reactants | No | |
| cdxml_path | No | |
| conditions | No | |
| coefficients | No | |
| conditions_below | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does the heavy lifting: it discloses side effects (writes PNG/SVG/CDXML files), the return artifact (a panel with conditions above/below the arrow), and a limitation (no electron-flow mechanisms). It also warns that coefficients are only applied on request and that the CDXML keeps full structures under abbreviation. Missing only concrete file locations or overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then exclusions, then a per-argument list — easy to scan. It loses a point for duplicating the arrow enum definition verbatim in both the opening paragraph and the Args block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter generative tool with an output schema, everything an agent needs is present: triggers, exclusions, input formats, output formats and defaults. Return value explanation is correctly omitted since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates: it defines every non-obvious parameter, gives the enum meanings for arrow with glyphs and the retro semantics, enumerates formats with a default, explains render_style values, and specifies coefficients ordering ('reactants then products') with a worked example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Draw a reaction scheme from reactants, products and conditions') and immediately scopes it as the net reaction rather than a mechanism. Explicitly names each sibling it is not for and what to use instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both a positive trigger ('Use it when explaining a reaction as well as for explicit drawing requests') and an explicit exclusion block listing generate_molecule, batch_generate and compare_molecules with the condition that selects each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a compound's data sheet: structure, PubChem properties and GHS safety.
Use it for a data sheet or facts available from those sources. The molecule panel also calls this tool when the user clicks Data. Internet access is required. Missing values are not evidence that a property or hazard is absent.
Not this tool for: a bare compound name with no data requested — use generate_molecule. Pass English or IUPAC names, or SMILES.
Args: name: English/IUPAC compound name or SMILES (e.g. 'Aspirin').
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| name | No | |
| type | No | |
| atoms | No | |
| smiles | No | |
| sources | No | |
| stereoNote | No | |
| molecule_svg | No | |
| stereoWarnings | No | |
| functionalGroups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations were provided, the description carries the full burden of transparency. It explicitly states that 'Missing values are not evidence that a property or hazard is absent,' which is a critical behavioral caveat for a lookup tool pulling external data. It also notes the dependency on internet access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient. Every sentence adds value, moving from primary function to operational requirements, exclusions, and finally, parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the critical nature of distinguishing it from `generate_molecule` and specifying input formats (SMILES/IUPAC/English), the description is maximally complete for an AI agent attempting correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is extremely sparse (just 'name': 'string'). The description significantly enhances the schema by detailing that 'name' can be an English/IUPAC compound name or a SMILES string, providing concrete examples like 'Aspirin' to guide usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The purpose is immediately clear: to show a compound's data sheet including structure, PubChem properties, and GHS safety. It successfully differentiates itself from sibling tools by specifying its function as data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool provides explicit instructions on when to use it and when *not* to use it, referring the agent to `generate_molecule` for bare compound names. It also adds the necessary operational constraint: internet access is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Internal helper for the panel UI — never call this directly.
The panel's export button calls it when the image clipboard is blocked by the sandbox; saving a picture is the user's click, not yours. The generate_* tools already write their PNG and SVG files themselves.
Expects a base64 PNG (with or without a data:image/png;base64,
prefix) and returns the path it was written to.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | ||
| png_base64 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does disclose the invocation context, the clipboard/sandbox condition, accepted input format, and that it returns the written path. It does not mention overwrite behavior, permissions, or error handling for file writes, which are relevant gaps for a save operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The warning not to call the tool is front-loaded, and the remaining sentences are short and purposeful. Every sentence adds either usage context or a relevant input/output detail without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values in detail, and it already states that a path is returned. For a two-parameter internal helper it is largely complete, though filename semantics remain underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by explaining that png_base64 is a base64 PNG with an optional data:image/png;base64, prefix, but it says nothing about the filename parameter's expected path, directory, extension, or overwrite semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (save a PNG), the expected input (base64 PNG), and the result (returns the written path). It also explicitly distinguishes this from the generate_* tools, which already write their own PNG and SVG files, so an agent can tell this is not the normal image-generation path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an unusually explicit usage rule: never call this directly, because the panel's export button invokes it when sandbox clipboard access is blocked. It also names the relevant alternative behavior by noting that generate_* tools already write their files themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.6.0batch_generate12 fields changedOutput schema / $defs / IsomerCandidateAdded value: +{
+ "description": "One structure a family name (\"xylene\", \"Glucose\") can mean.",
+ "properties": {
+ "label": {
+ "title": "Label",
+ "type": "string"
+ },
+ "name": {
+ "default": "",
+ "title": "Name",
+ "type": "string"
+ },
+ "smiles": {
+ "title": "Smiles",
+ "type": "string"
+ },
+ "svg": {
+ "default": "",
+ "title": "Svg",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "smiles"
+ ],
+ "title": "IsomerCandidate",
+ "type": "object"
+}Output schema / $defs / MoleculePayload / properties / candidatesAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/IsomerCandidate"
+ },
+ "title": "Candidates",
+ "type": "array"
+}Output schema / $defs / MoleculePayload / properties / initialViewAdded value: +{
+ "default": "",
+ "title": "Initialview",
+ "type": "string"
+}Output schema / $defs / MoleculePayload / properties / messageAdded value: +{
+ "default": "",
+ "title": "Message",
+ "type": "string"
+}Output schema / $defs / MoleculePayload / properties / projectionNoteAdded value: +{
+ "default": "",
+ "title": "Projectionnote",
+ "type": "string"
+}Output schema / $defs / MoleculePayload / properties / stereoNoteAdded value: +{
+ "default": "",
+ "title": "Stereonote",
+ "type": "string"
+}Output schema / $defs / MoleculePayload / properties / stereoWarningsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/StereoWarning"
+ },
+ "title": "Stereowarnings",
+ "type": "array"
+}Output schema / $defs / MoleculePayload / properties / viewAtomsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/AtomData"
+ },
+ "title": "Viewatoms",
+ "type": "array"
+}Output schema / $defs / MoleculePayload / properties / viewRequestAdded value: +{
+ "additionalProperties": true,
+ "default": {},
+ "title": "Viewrequest",
+ "type": "object"
+}Output schema / $defs / MoleculePayload / properties / viewSvgAdded value: +{
+ "default": "",
+ "title": "Viewsvg",
+ "type": "string"
+}Output schema / $defs / MoleculePayload / properties / viewsAdded value: +{
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "title": "Views",
+ "type": "array"
+}Output schema / $defs / StereoWarningAdded value: +{
+ "description": "Ein Stereoelement, dessen Konfiguration die Eingabe offen lässt.",
+ "properties": {
+ "atoms": {
+ "default": [],
+ "items": {
+ "type": "integer"
+ },
+ "title": "Atoms",
+ "type": "array"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "label": {
+ "default": "",
+ "title": "Label",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "title": "StereoWarning",
+ "type": "object"
+}generate_molecule14 fields changedInput schema / properties / stereo_variantsAdded value: +{
+ "default": false,
+ "title": "Stereo Variants",
+ "type": "boolean"
+}Input schema / properties / viewAdded value: +{
+ "default": "",
+ "title": "View",
+ "type": "string"
+}Output schema / $defs / IsomerCandidateAdded value: +{
+ "description": "One structure a family name (\"xylene\", \"Glucose\") can mean.",
+ "properties": {
+ "label": {
+ "title": "Label",
+ "type": "string"
+ },
+ "name": {
+ "default": "",
+ "title": "Name",
+ "type": "string"
+ },
+ "smiles": {
+ "title": "Smiles",
+ "type": "string"
+ },
+ "svg": {
+ "default": "",
+ "title": "Svg",
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "smiles"
+ ],
+ "title": "IsomerCandidate",
+ "type": "object"
+}Output schema / $defs / StereoWarningAdded value: +{
+ "description": "Ein Stereoelement, dessen Konfiguration die Eingabe offen lässt.",
+ "properties": {
+ "atoms": {
+ "default": [],
+ "items": {
+ "type": "integer"
+ },
+ "title": "Atoms",
+ "type": "array"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "label": {
+ "default": "",
+ "title": "Label",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "title": "StereoWarning",
+ "type": "object"
+}Output schema / properties / candidatesAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/IsomerCandidate"
+ },
+ "title": "Candidates",
+ "type": "array"
+}Output schema / properties / initialViewAdded value: +{
+ "default": "",
+ "title": "Initialview",
+ "type": "string"
+}Output schema / properties / messageAdded value: +{
+ "default": "",
+ "title": "Message",
+ "type": "string"
+}Output schema / properties / projectionNoteAdded value: +{
+ "default": "",
+ "title": "Projectionnote",
+ "type": "string"
+}Output schema / properties / stereoNoteAdded value: +{
+ "default": "",
+ "title": "Stereonote",
+ "type": "string"
+}Output schema / properties / stereoWarningsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/StereoWarning"
+ },
+ "title": "Stereowarnings",
+ "type": "array"
+}Output schema / properties / viewAtomsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/AtomData"
+ },
+ "title": "Viewatoms",
+ "type": "array"
+}Output schema / properties / viewRequestAdded value: +{
+ "additionalProperties": true,
+ "default": {},
+ "title": "Viewrequest",
+ "type": "object"
+}Output schema / properties / viewSvgAdded value: +{
+ "default": "",
+ "title": "Viewsvg",
+ "type": "string"
+}Output schema / properties / viewsAdded value: +{
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "title": "Views",
+ "type": "array"
+}generate_reaction10 fields changedInput schema / properties / arrowAdded value: +{
+ "default": "forward",
+ "enum": [
+ "forward",
+ "equilibrium",
+ "retro"
+ ],
+ "title": "Arrow",
+ "type": "string"
+}Input schema / properties / coefficientsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Coefficients"
+}Input schema / properties / conditions_belowAdded value: +{
+ "default": "",
+ "title": "Conditions Below",
+ "type": "string"
+}Output schema / $defs / MolEntry / properties / coefficientAdded value: +{
+ "default": 1,
+ "title": "Coefficient",
+ "type": "integer"
+}Output schema / $defs / ReactionBalanceAdded value: +{
+ "description": "Atom and charge balance of the equation as drawn (all coefficients 1).",
+ "properties": {
+ "balanced": {
+ "title": "Balanced",
+ "type": "boolean"
+ },
+ "chargeDifference": {
+ "default": 0,
+ "title": "Chargedifference",
+ "type": "integer"
+ },
+ "difference": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "default": {},
+ "title": "Difference",
+ "type": "object"
+ },
+ "formulas": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "title": "Formulas",
+ "type": "array"
+ },
+ "note": {
+ "default": "",
+ "title": "Note",
+ "type": "string"
+ },
+ "suggestedCoefficients": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "integer"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Suggestedcoefficients"
+ },
+ "suggestedEquation": {
+ "default": "",
+ "title": "Suggestedequation",
+ "type": "string"
+ },
+ "summary": {
+ "default": "",
+ "title": "Summary",
+ "type": "string"
+ }
+ },
+ "required": [
+ "balanced"
+ ],
+ "title": "ReactionBalance",
+ "type": "object"
+}Output schema / properties / arrowAdded value: +{
+ "default": "forward",
+ "title": "Arrow",
+ "type": "string"
+}Output schema / properties / balanceAdded value: +{
+ "anyOf": [
+ {
+ "$ref": "#/$defs/ReactionBalance"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / coefficientsAdded value: +{
+ "default": [],
+ "items": {
+ "type": "integer"
+ },
+ "title": "Coefficients",
+ "type": "array"
+}Output schema / properties / conditions_belowAdded value: +{
+ "default": "",
+ "title": "Conditions Below",
+ "type": "string"
+}Output schema / properties / requestAdded value: +{
+ "additionalProperties": true,
+ "default": {},
+ "title": "Request",
+ "type": "object"
+}lookup_molecule_data9 fields changedOutput schema / $defs / DatabaseSource / properties / groupsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/GhsGroup"
+ },
+ "title": "Groups",
+ "type": "array"
+}Output schema / $defs / DatabaseSource / properties / noteAdded value: +{
+ "default": "",
+ "title": "Note",
+ "type": "string"
+}Output schema / $defs / DatabaseSource / properties / statusAdded value: +{
+ "default": "",
+ "title": "Status",
+ "type": "string"
+}Output schema / $defs / GhsGroupAdded value: +{
+ "description": "Die Einstufung EINER Quelle (PubChem ReferenceNumber).",
+ "properties": {
+ "hazards": {
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/GhsHazard"
+ },
+ "title": "Hazards",
+ "type": "array"
+ },
+ "id": {
+ "title": "Id",
+ "type": "string"
+ },
+ "lead": {
+ "default": false,
+ "title": "Lead",
+ "type": "boolean"
+ },
+ "not_classified": {
+ "anyOf": [
+ {
+ "$ref": "#/$defs/GhsNotClassified"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+ },
+ "note": {
+ "default": "",
+ "title": "Note",
+ "type": "string"
+ },
+ "p_codes": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "title": "P Codes",
+ "type": "array"
+ },
+ "pictograms": {
+ "default": [],
+ "items": {
+ "type": "string"
+ },
+ "title": "Pictograms",
+ "type": "array"
+ },
+ "record_name": {
+ "default": "",
+ "title": "Record Name",
+ "type": "string"
+ },
+ "reports_total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Reports Total"
+ },
+ "signal": {
+ "default": "",
+ "title": "Signal",
+ "type": "string"
+ },
+ "source": {
+ "title": "Source",
+ "type": "string"
+ },
+ "url": {
+ "default": "",
+ "title": "Url",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "source"
+ ],
+ "title": "GhsGroup",
+ "type": "object"
+}Output schema / $defs / GhsHazardAdded value: +{
+ "properties": {
+ "code": {
+ "title": "Code",
+ "type": "string"
+ },
+ "percent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Percent"
+ },
+ "text": {
+ "default": "",
+ "title": "Text",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code"
+ ],
+ "title": "GhsHazard",
+ "type": "object"
+}Output schema / $defs / GhsNotClassifiedAdded value: +{
+ "description": "Eine Quelle meldet ausdruecklich \"erfuellt die GHS-Kriterien nicht\".",
+ "properties": {
+ "percent": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Percent"
+ },
+ "reports": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Reports"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Total"
+ }
+ },
+ "title": "GhsNotClassified",
+ "type": "object"
+}Output schema / $defs / StereoWarningAdded value: +{
+ "description": "Ein Stereoelement, dessen Konfiguration die Eingabe offen lässt.",
+ "properties": {
+ "atoms": {
+ "default": [],
+ "items": {
+ "type": "integer"
+ },
+ "title": "Atoms",
+ "type": "array"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "label": {
+ "default": "",
+ "title": "Label",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "title": "StereoWarning",
+ "type": "object"
+}Output schema / properties / stereoNoteAdded value: +{
+ "default": "",
+ "title": "Stereonote",
+ "type": "string"
+}Output schema / properties / stereoWarningsAdded value: +{
+ "default": [],
+ "items": {
+ "$ref": "#/$defs/StereoWarning"
+ },
+ "title": "Stereowarnings",
+ "type": "array"
+}v0.1.0batch_generatecompare_moleculesexport_anki_deckgenerate_moleculegenerate_reactionlookup_molecule_datasave_pngScored across 7 tools
Each tool has a clearly distinct purpose, and the descriptions explicitly cross-reference when to use another tool (single vs. batch, compare vs. draw, reaction vs. molecule, data sheet vs. bare name). The only internal helper, save_png, is explicitly marked as never called directly, so it does not create ambiguity.
All names use snake_case and are mostly verb-first (generate_molecule, lookup_molecule_data, generate_reaction, compare_molecules, export_anki_deck, save_png). The only minor deviation is batch_generate, where the verb is not first, but the convention remains readable and predictable overall.
Seven tools is well within the appropriate range and each tool covers a distinct workflow: single drawing, batch drawing, reaction drawing, comparison, data lookup, Anki export, and an internal save helper. The set feels scoped rather than bloated or thin.
The surface covers the core chemical drawing lifecycle: single structures, batches, reactions, side-by-side comparison, external data lookup, and flashcard export. Minor gaps exist, such as no dedicated spectrum-generation tool despite spectra being supported in Anki card visuals, and no mechanism/electron-flow tool, though that appears intentionally out of scope.
Chemistry, pharma and biotech tools for AI assistants: NMR, MS, IR and UV analysis, ADMET and ICH M7, stability (ICH Q1), HPLC methods, DoE, docking, retrosynthesis, biologics. Deterministic results you can check. Built in Leipzig, Germany.
Turn any LLM into your lab assistant: search samples, track experiments, analyze data with AI.
Build study flashcards and exam-prep decks from your AI chat, all stored locally.
Free: turn your AI chats into spaced-repetition vocabulary. 13 tools, reads and writes.
