チャット → 化学構造。 Claude Desktop 用の MCP サーバーです。分子、反応、実験結果を平易な言葉で説明すると、図を描画します。RDKit でローカルにレンダリングされた印刷可能な PNG/SVG に加え、チャット内でインタラクティブなプレビューも表示されます。「アスピリンを描いて」 はすでに完全なコマンドです。
薬学や化学の学生で、六角形をクリックするのに時間をかけすぎている人向けに作られています。レポートやスライドに実際に必要なものをカバーする 20 個のツールがあります。構造、反応スキーム、ステップバイステップの機構、基質スコープ図、TLC プレート、滴定曲線、模式スペクトル、物質データシート、Ph.Eur. 定量計算、Anki デッキなどです。
必要なものは、インストールコマンド 1 つだけです。Apache-2.0、API キー不要、サーバーへのサインアップ不要、ChemDraw ライセンスも不要です。必要なのは Claude Desktop と uv だけで、それ以外は一度だけ取得されます。レンダリングは完全にローカルで実行され、インターネットにアクセスするのは名前解決とデータベース参照のみです。ChemDraw CDXML は、そこで編集を続けたい人向けのオプションの追加形式であり、必須ではありません。
「カフェインを描いて」 — generate_molecule が生成した印刷可能な PNG:
「エタノールと酢酸のフィッシャーエステル化反応を示して」 — generate_reaction が、矢印の上に条件を付けたスキームをチャットパネルにライブでレンダリングします:
「フィッシャーエステル化機構をステップバイステップで示して」 — generate_mechanism が、インタラクティブパネルに曲線の電子フロー矢印をレンダリングします:
「私の鈴木カップリングのスコープ図を作って: 3a 92%、3b 88%（12 時間後）、3c 64%（ee 94%、dr 10:1）、3d 71%」 — generate_scope_table が、上部に一般式とその条件、その下に生成物を、共通の結合長と共通のキャプション基準線で配置します:
「酢酸エチルの IR スペクトルをスケッチして」 — generate_spectrum（与えられたピークを、タイプごとの軸の慣例に従って描画します）:
「私のエステル化の TLC: 原料 0.30、生成物 0.65、共スポットは両方、原料が少し残っている」 — generate_tlc が、実験レポートが求めるプレートを、移動相と検出をキャプションとして描画します:
「カフェインを 3D で表示して」 — generate_3d が分子（ETKDG + 力場）を埋め込み、チャットパネルにドラッグで回転できるボール＆スティックビューアを開きます:
「イブプロフェンとナプロキセン、ケトプロフェンの違いは？」 — compare_molecules が、共通の足場（MCS）を中性に保ち、異なる部分をすべて強調表示します:
「リン酸と NaOH の滴定曲線、指示薬はフェノールフタレイン」 — generate_titration_curve が、正確な電荷バランスから pH を計算し、当量点、緩衝点（pH = pKa）、指示薬の変色域を表示します。その姉妹ツール generate_species_distribution は、各 pH でどのプロトン化種が優勢かを示します:
「重要な分子を含む Anki デッキを作成して Anki で開いて」 — export_anki_deck が、レンダリングされた構造を埋め込んだ、インポート可能な .apkg を構築します。オプションの AnkiConnect アドオンを使用すると、カードは実行中の Anki に直接入り、クリック不要です:
Related MCP server: ChemMCP
サーバーが公開する全 20 ツール。ファイルは ~/ChemDraw-Output/ に書き込まれます。すべての描画ツールは、チャット内パネル用のライブプレビューも返します。
構造とスキーム
generate_molecule — 名前/SMILES → 2D 構造を PNG + SVG（オプションで CDXML）として出力。特性、官能基検出、Lipinski の Rule of Five チェック付き
batch_generate — 構造のリスト全体を 1 回の呼び出しで処理
generate_reaction — 原料 + 生成物 + 条件 → 矢印の上に条件を配置した反応スキーム
generate_mechanism — 曲線矢印の機構（SN1、SN2、フィッシャーエステル化）をステップバイステップで
generate_scope_table — 方法論文献の基質スコープ図: 上部に一般式とその条件、その下に生成物のグリッド。各生成物には識別子（「1a」）と収率（「78%」）、さらにオプションで ee/dr/時間。すべての構造は共通の結合長、すべてのキャプションは共通の基準線を共有。解決できないエントリは致命的ではなく報告される
compare_molecules — 2〜4 個の構造を並べ、違いを強調表示、共通の足場（MCS）は中性
generate_3d — チャットパネル内で回転可能な 3D ボール＆スティック配座（ETKDGv3 + 力場）と SDF エクスポート
実験結果と分析
generate_spectrum — ピークリストからの模式スペクトル（IR、NIR、ラマン、UV/Vis、蛍光、ORD、CD、¹H/¹³C NMR、MS）を、タイプごとの軸の慣例に従って描画。与えられたピークを描くだけで、スペクトルを予測するものではない
generate_tlc — Rf 値からの TLC プレートのスケッチ: 下端にスタートライン、上端に溶媒フロント、各スポット（原料/反応/共スポット）にキャプション付きレーン、各スポットに Rf を注記、移動相と検出をキャプションとして印刷 — 実験レポートが求めるスケッチ
generate_titration_curve — 正確な電荷バランスからの pH 対 滴定剤体積。当量点、緩衝点（pH = pKa）、指示薬の変色域付き
generate_species_distribution — pH に対するプロトン化種の割合（Henderson–Hasselbalch）と pKa クロスオーバーをマーク
generate_calibration_curve — 標準液を通る最小二乗直線と、そこから読み取った未知試料。校正範囲外の試料は、静かに報告するのではなく外挿としてラベル付け。検出限界と定量限界（DIN 32645）も検証の質問に付随
ベンチ計算（数値 と 計算過程 — 実験レポートは両方を要求します）
calculate_solution — 秤量すべき量（m = c · V · M）、実際に得られた量、希釈（C₁V₁ = C₂V₂ で溶媒量を明記）、混合十字、CuSO₄·5H₂O のような水和物を含むモル質量。計算された量が分析天秤の分解能を下回る場合に警告 — その場合はより大きな量を希釈するのが正しい
calculate_content — プロトコルが求める定量: 各測定の含有量 → Grubbs 外れ値検定 → 平均、s、RSD → 表示含有量に対する t 検定。滴定（参照滴定からの力価決定を含む）と光度測定、さらに油脂特性（酸価、けん化価、エステル価、ヨウ素価）と Karl Fischer 水分を追加の method として
calculate_ph — 弱酸・強酸・弱塩基・強塩基、緩衝液、秤量可能な質量までの緩衝液レシピ。正確な電荷バランスで解き、教科書の近似式を横に表示。両者が一致しない場合、近似式はその前提を失っていると明示。10⁻⁸ M HCl は pH 6.98 であり、8 ではない
物質データ（オンライン参照）
lookup — 質問ごとに 1 つの topic でテキストとして事実を返す: properties（分子式、質量、CAS、InChIKey — デフォルト）、safety（GHS 危険有害性情報、ピクトグラム、注意喚起語）、physical（融点/沸点、溶解度、密度）、biochem（ChEBI 分類と関連 UniProt エントリ）、pathway（KEGG からの代謝経路）
lookup_molecule_data — PubChem + GHS を 1 つのデータシートに統合し、チャット内パネル用に構造も含めて表示
predict_spectrum — 構造が示すべき IR バンド（強度とバンド形状付き）、測定波数が何に属する可能性があるか、¹H シグナルがいくつ期待されるかとその積分比。決定的なので、できないことも明言: 化学シフト（ppm）は提供せず、ジアステレオトピックなプロトンは 1 つのシグナルとして数える
試験対策
export_anki_deck — インポート可能な Anki .apkg としてフラッシュカードを作成: 構造↔名前のドリル（オプションで逆方向: 1 ノートで両方向）、穴埋めカード、同定/検出反応、スペクトルバンドの割り当て — レンダリングされた画像を埋め込み、カードごとのタグ、Parent::Child サブデッキ付き。デッキを再エクスポートすると、カードを複製せずに更新。オプションで AnkiConnect アドオン経由で実行中の Anki に直接配信。独自のカードの代わりに curated_deck_id を渡すと、式検証済みのスターターデッキ（古典的な鎮痛薬、Ph.Eur. 同定反応）を入手可能
各ツールは 5 つの領域のいずれかに属します — 描画、実験グラフ、参照、計算、Anki — そして各ツールは「何に使わないか」を双方向で明示します。そのため「アスピリンを描いて」が基質スコープグリッドになることはなく、「私の緩衝液の pH は？」がプロットツールになることもありません。1 つのツールだけはその外側にあります: save_png はパネルのエクスポートボタンのサーバー側で、クリックしたときに呼び出され、単独では呼び出されません。
2 つのオプションのボールトツール（search_vault、read_vault_entry）は、CHEMDRAW_VAULT_PATH が設定されている場合にのみ表示されます。設定されていない場合、サーバーは上記の 20 ツールのみを公開します。
formats — デフォルトは ["png","svg"]。generate_molecule、generate_reaction、batch_generate ではさらに "cdxml" が加わります。図ツール（generate_scope_table、generate_tlc、generate_spectrum）は、無意味なものを書き出す代わりに、明確なエラーを出して CDXML を拒否します。
abbreviate_groups=True — 一般的な置換基を、化学者が実際に書くラベル（Ph、Bn、OMe、OAc、tBu、CO₂H、Boc、Ts、TBS）として描画します。セルが小さくなるときに価値があります — 基質間で異なる部分だけが明記されるため、スコープ図は読みやすいままです。generate_molecule、generate_reaction、generate_scope_table、batch_generate で利用できます。
render_style — レンダーパラメータの羅列ではなく、名前付きの外観を指定します。同じ4つのツールで使えます。"compact"（細い結合、ラベルサイズ上限、余白を詰める）は2段組レイアウトの小さな図用、"presentation"（結合幅2倍、最小フォントサイズ、余白を多め）は講義スライド用、"grayscale" は白黒印刷用で、赤と青が区別できない2つのグレーになるのを防ぎます。空の場合はデフォルトの外観のまま、変更されません。
annotate_stereo=True — 2D描画にCIP記述子（R/S、E/Z）を表示します（generate_molecule、batch_generate）。
3つの方法があります。1つ選んでください。方法1と2は設定に冪等にマージされ、事前にバックアップを取り、設定済みの他のすべてのMCPサーバーには触れません。その後、Claude Desktopを再起動して、「カフェインを描いて」 と尋ねてください。
方法1 — リポジトリをクローン（コードを読んだり変更したりしたい場合におすすめ。uvがなければインストールし、依存関係を同期し、サーバーを登録します）:
git clone https://github.com/jurimaxam-dotcom/chemdraw-mcp.git
cd chemdraw-mcp && ./install.sh方法2 — PyPIから、クローンなし（uv が必要）:
uv tool install chemdraw-mcp
chemdraw-installchemdraw-install は、インストールされたランチャーの絶対パスを使ってClaude Desktopのエントリを書き込み、登録した起動コマンドを表示します。
方法3 — 設定を手で編集。 これを claude_desktop_config.json の mcpServers の下に追加します（macOS: ~/Library/Application Support/Claude/claude_desktop_config.json）:
"chemdraw-tool": {
"command": "/opt/homebrew/bin/uvx",
"args": ["chemdraw-mcp"]
}手動インストールを失敗させる唯一の落とし穴: Claude DesktopはログインシェルからMCPサーバーを起動しません — 最小限のGUI PATHを使用します。素の
"uvx"や"uv"はそこで解決できず、サーバーは何も言わずに起動に失敗します。必ず、あなたの マシンでwhich uvxが出力する絶対パスをcommandに入れてください。方法1と2はこれを自動で行います。
Javaランタイム（例: brew install openjdk）があれば、OPSIN が体系的なIUPAC名をオフラインで解析できます — データベースに索引がない名前も含みます。Javaがない場合、リゾルバーは単にPubChem/NCIのオンライン検索に進みます。
AnkiConnectアドオンがあれば、export_anki_deck がカードを実行中のAnkiに直接プッシュできます。ない場合は .apkg ファイルを受け取り、自分でインポートします。
ChemDraw（macOS）は決して必要ありません: formats=["cdxml"] をリクエストし、そこで編集を続けたい場合は自分でファイルを開いてください。
chemdraw-doctor # after "uv tool install chemdraw-mcp"
uv run chemdraw-doctor # in the cloned repo
uvx --from chemdraw-mcp chemdraw-doctor # without installing anythingこれが最初に試すべきことです — 「サーバーが何もしない」を名前付きの原因に変えます。チャットでサーバーが死んでいるように見える6つの項目（RDKitレンダリング、Java/OPSINランタイム、uv パス、Claude Desktopエントリ、名前データベース、出力ディレクトリ）をチェックし、問題ごとに、それを修正する正確なコマンドを表示します。3つのレベルが区別されます: [OK]、[LIMITED]（動作するが制限あり）、[FAIL]（壊れている）。[NOTE] は、Claude Desktopがインストールされていないなど、単に該当しないチェックを示します。サーバーが使用可能である限り終了コードは0のままなので、スクリプトで実行できます。（PyPIインストールの場合、uv とClaude Desktopのチェックは [NOTE] を報告します — これらはリポジトリインストーラーに関連するものです。）
あらかじめ明記しておきます。レポートで驚くことがないように:
Javaはオプションであり、それには代償があります。 JREがない場合、OPSINはスキップされ、名前はPubChem/NCI経由でオンラインで解決されます — つまり、名前の検索にはインターネット接続が必要で、それらのデータベースが索引化している名前に対してのみ機能します。SMILES入力はネットワークに触れません。
スペクトルは模式図です。 generate_spectrum は渡されたピークを、スペクトルタイプに応じた正しい軸の規則で描画します。何も測定せず、何も予測しません — ピーク値が計器ではなくチャットから来た場合は、レポートに入れる前に検証してください。
TLCの強度は描画上のヒントです。 オプションの intensity（0…1）は、スケッチ上のスポットを薄くします。これはデンシトメトリーではなく、定量的な意味を持ちません。
CDXMLは脇道です。 RDKit分子から書き出され、ラウンドトリップ検証されますが、PNG/SVGが主要な出力であり、ピクセルテストがカバーするものです。CDXMLはデフォルトでオフで、構造と反応スキームに限定されます — TLCプレート、スコープ図、スペクトルはそれを拒否します。
3Dは1つのコンフォマーです。 generate_3d はETKDGv3で埋め込み、MMFF（フォールバックとしてUFF）で最適化します。これは眺めるためのもっともらしい幾何構造であり、コンフォメーション探索でもエネルギーに関する主張でもありません。
ChemDrawブリッジはmacOS専用で、ローカルにインストールされたChemDrawが必要です。それ以外はすべて、それがなくても動作します。
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以上、パッケージマネージャーは 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 e2e600以上のテストを、テストファーストで記述。e2eテストは、実際のRDKit SVGをヘッドレスChromiumでラスタライズし、正確なピクセルスナップショットと比較します — エクスポートパスとチャット内プレビューは、同じ描画定数に保たれています。
Apache-2.0 — LICENSE を参照。Copyright 2026 jurimaxam-dotcom.
免責事項: これは非公式の独立したプロジェクトであり、Revvityとの提携や承認を受けたものではありません。ChemDraw はRevvity Signals Software, Inc.の商標です。このツールはChemDrawを含まず、必要としません。オプションでオープンなCDXML形式でファイルをエクスポートできます。
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.
