Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Schemdraw MCP Server Create an RC circuit with a 1kΩ resistor and 100µF capacitor"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
回路図描画ライブラリ schemdraw のための Model Context Protocol (MCP) サーバーです。Claude や他の AI アシスタントが電子回路図を作成・編集できるようになります。
回路図作成: 基本的な電子回路素子（抵抗、コンデンサ、ダイオード等）の配置
自動レイアウト: コンポーネント間の接続と最適な配置
多様な出力形式: PNG、SVG、PDF 形式での回路図出力
柔軟な構成: シンプルな回路からループ回路まで対応
リアルタイム編集: 回路の動的な変更と更新
Related MCP server: Claude Code Control MCP
Python 3.10+
uv (推奨) または pip
# プロジェクトのクローン
git clone https://github.com/fukayatti/schemdraw-mcp-server.git
cd schemdraw-mcp-server
# 依存関係のインストール
uv sync
# 開発用依存関係も含める場合
uv sync --all-extras# プロジェクトのクローン
git clone https://github.com/fukayatti/schemdraw-mcp-server.git
cd schemdraw-mcp-server
# インストール
pip install -e .
# 開発用依存関係も含める場合
pip install -e ".[dev]"# 標準入出力で MCP サーバーを起動
uv run python server.py
# または JSON-RPC over stdio で起動
python server.py --stdioclaude_desktop_config.json ファイルに以下を追加：
{
"mcpServers": {
"schemdraw": {
"command": "uv",
"args": ["run", "python", "/path/to/schemdraw-mcp-server/server.py"],
"cwd": "/path/to/schemdraw-mcp-server"
}
}
}Claude で以下のようにリクエストできます：
抵抗とコンデンサと LED を使ったシンプルな回路図を作成してください
# 開発用依存関係のインストール
uv sync --all-extras
# コードフォーマット
uv run black .
uv run isort .
# リントチェック
uv run flake8 .
uv run mypy .
# テスト実行
uv run pytestresistor - 抵抗器
capacitor - コンデンサ
inductor - インダクタ
diode - ダイオード
voltage_source - 電圧源
current_source - 電流源
battery - バッテリー
bjt_npn - NPN バイポーラトランジスタ
bjt_pnp - PNP バイポーラトランジスタ
mosfet_n - N-ch MOSFET
mosfet_p - P-ch MOSFET
opamp - オペアンプ
and_gate - AND ゲート
or_gate - OR ゲート
not_gate - NOT ゲート
nand_gate - NAND ゲート
nor_gate - NOR ゲート
xor_gate - XOR ゲート
ground - グラウンド
vdd - 電源
vss - 負電源
label - ラベル
create_circuit新しい回路図を作成します。
パラメータ:
title (オプション): 回路図のタイトル
size (オプション): [幅, 高さ] の配列
add_component回路に素子を追加します。
パラメータ:
component_type (必須): 素子のタイプ
component_id (必須): 素子の識別子
label (オプション): 素子のラベル
value (オプション): 素子の値
direction (オプション): 配置方向 (right, left, up, down)
position (オプション): [x, y] 座標
connect_components素子間を接続します。
パラメータ:
from_component (必須): 接続元の素子 ID
to_component (必須): 接続先の素子 ID
connection_type (オプション): 接続タイプ (wire, dot)
create_loop_circuitループ回路を作成します。
パラメータ:
components (必須): コンポーネントのリスト
size (オプション): 回路の一辺の長さ
save_circuit回路図を保存します。
パラメータ:
filename (必須): 保存ファイル名
format (オプション): 出力形式 (png, svg, pdf)
dpi (オプション): 解像度
get_circuit_info現在の回路図の情報を取得します。
list_available_components利用可能な素子タイプの一覧を取得します。
add_spacerコンポーネント間にスペースを追加します。
optimize_layout回路図のレイアウトを最適化します。
Claude への指示例:
抵抗（1kΩ）とコンデンサ（100µF）を直列に接続した RC 回路を作成してください
この指示により、以下のような回路図が生成されます：
[電源] ――[R1: 1kΩ]――[C1: 100µF]――[GND]SCHEMDRAW_DPI: デフォルトの出力解像度 (デフォルト: 150)
SCHEMDRAW_FORMAT: デフォルトの出力形式 (デフォルト: svg)
このリポジトリをフォーク
フィーチャーブランチを作成 (git checkout -b feature/amazing-feature)
変更をコミット (git commit -m 'Add some amazing feature')
ブランチにプッシュ (git push origin feature/amazing-feature)
プルリクエストを作成
このプロジェクトは MIT ライセンスの下で公開されています。詳細は LICENSE ファイルを参照してください。
schemdraw - 優れた回路図描画ライブラリ
Model Context Protocol - AI との統合を可能にするプロトコル
問題や質問がある場合は、Issues でお知らせください。
回路図にコンポーネントを追加
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | コンポーネントのラベル（オプション） | |
| value | No | コンポーネントの値（オプション） | |
| position | No | 位置 [x, y]（オプション） | |
| direction | No | コンポーネントの方向（オプション） | |
| component_id | Yes | コンポーネントの識別子 | |
| component_type | Yes | コンポーネントのタイプ（resistor, capacitor, diode等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic action. With no annotations provided, the description carries full burden but fails to mention side effects, state changes, or constraints (e.g., uniqueness of component_id, interaction with existing components).
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 a single sentence, very concise. While it is minimal, it is not verbose and avoids unnecessary words. However, it may be too brief for a tool with 6 parameters, but it scores well on conciseness.
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 (6 parameters, 2 required, no output schema or annotations), the description is inadequate. It does not explain valid component types, position semantics, direction effects, or any uniqueness constraints. The schema provides some detail but the description should add context.
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 has 100% description coverage, so the schema already explains each parameter. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the description neither improves nor degrades parameter understanding.
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 clearly states the verb 'add' and the resource 'component to circuit diagram', making the purpose obvious. It is unambiguous and distinguishes from sibling tools like 'add_spacer' and 'connect_components', though not explicitly.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description does not mention when to use 'add_component' over 'add_spacer' or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コンポーネント間にスペースを追加して文字の重複を防ぐ
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | スペースの長さ（デフォルト: 1.0） | |
| direction | No | スペースの方向（デフォルト: right） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool adds space to prevent duplication but does not disclose any side effects, such as whether it modifies existing components or affects the layout in other ways. There is no mention of reversibility or any behavioral traits beyond the basic action.
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 a single sentence in Japanese, which is concise and to the point. It effectively conveys the purpose without unnecessary detail. However, it may be too brief for non-Japanese speakers, but assuming the target audience understands Japanese, it is well-structured.
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 tool's simplicity with two optional parameters and no output schema, the description is adequate. However, it lacks details about the unit of length and what 'character duplication' means exactly. The description does not explain how the spacer integrates with existing components, but for a basic tool, this may be sufficient.
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 has 100% coverage, with both 'length' and 'direction' parameters described. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 clearly indicates the tool adds space between components to prevent character duplication. The verb 'add' and resource 'space between components' are specific, and the purpose is stated. However, it does not explicitly differentiate from sibling tools, but the sibling list does not include similar spacing tools, so it is sufficiently clear.
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?
No guidance on when to use this tool versus alternatives. The description implies it is for spacing, but there is no mention of when not to use it or any alternative approaches. The sibling tools include 'add_component' and 'optimize_layout', but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コンポーネント間を接続
| Name | Required | Description | Default |
|---|---|---|---|
| to_component | Yes | 接続先のコンポーネントID | |
| from_component | Yes | 接続元のコンポーネントID | |
| connection_type | No | 接続のタイプ（デフォルト: wire） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description is minimal and does not disclose behavioral traits such as whether it mutates state, requires existing components, or returns any result.
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?
Very concise, single phrase. However, it lacks structure such as separating key information from optional details.
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 3 parameters, no output schema, and no annotations, the description is too brief. It does not explain what happens after connection, returns, or prerequisites.
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 coverage is 100% with parameter descriptions provided. The tool description adds no additional meaning beyond what the schema already states.
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?
Description 'Connect between components' is vague. It states the general action but lacks specificity about what type of connection or context, and does not distinguish from sibling tools like add_component or create_circuit.
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?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
新しい回路図を作成
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 回路図のサイズ [width, height]（オプション） | |
| title | No | 回路図のタイトル（オプション） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavioral traits. It only states the creation action, with no details on side effects (e.g., does it overwrite?), initialization state, or required permissions. The agent gets minimal behavioral insight.
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 a single short sentence, which is concise, but it is essentially a tautology of the tool's name. It could include more useful information without becoming verbose. Content earns its place but adds minimal value beyond name.
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 no output schema, no annotations, and two optional parameters, the description should provide more context about the created circuit (e.g., default state, return value). It is incomplete for an agent to fully understand the tool's behavior and output.
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 100% with Japanese descriptions for both parameters (size and title). The main description adds no additional parameter meaning. Per rules, baseline 3 is appropriate since schema already documents parameters.
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 '新しい回路図を作成' clearly states it creates a new circuit diagram, matching the tool name. However, it does not differentiate from the sibling tool 'create_loop_circuit', which likely has a similar purpose. Without context, an agent may not know which to choose.
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?
No guidance on when to use this tool versus alternatives like 'create_loop_circuit'. The description offers no context on prerequisites, when-not-to-use, or typical use cases. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定されたコンポーネントで四角形の閉回路を作成
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 回路の一辺の長さ（デフォルト: 3） | |
| components | Yes | 回路に含めるコンポーネントのリスト |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as whether the tool modifies existing circuits, requires authentication, or handles invalid components. Only states 'create', which implies non-destructive, but no details.
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 a single short sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the core purpose.
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?
The tool has no output schema and the description does not explain return values or behavior in edge cases (e.g., invalid components, missing size). Given the complexity of creating a circuit, more context is needed.
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 coverage is 100%, so parameters are already documented. The description adds no additional meaning beyond stating 'with specified components', which is redundant with the schema's component list description.
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 clearly states the tool creates a rectangular closed circuit with specified components. It differentiates from siblings like 'create_circuit' (more general) and 'connect_components' (focuses on connections) by specifying 'loop' and 'rectangular', but could be more explicit about the loop nature.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies use when creating a closed loop circuit, but doesn't contrast with alternatives like 'create_circuit' or 'connect_components'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
現在の回路図の情報を取得
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'get information', which implies a read operation, but does not disclose any behavioral traits such as side effects, required permissions, or response format. For a simple getter, this is insufficient.
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 a single, front-loaded sentence with no wasted words. It is appropriately concise for a zero-parameter tool.
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 lack of output schema and annotations, the description should provide more context about what information is returned. Without that, the agent cannot fully understand the tool's output, making it incomplete.
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?
There are no parameters, and schema description coverage is vacuously 100%. The description adds no parameter info beyond the schema, earning the baseline score of 3.
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 verb ('get') and resource ('current circuit diagram information'), distinguishing it from sibling tools that create or modify circuits. However, 'information' is vague; it could be more specific about what data is returned.
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?
No guidance on when to use this tool versus alternatives like list_available_components or create_circuit. There is no mention of context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
利用可能なコンポーネントタイプの一覧を取得
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond listing. It does not mention side effects, permissions, or whether the list is static or dynamic.
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?
Single, short sentence that conveys the purpose without any fluff. Front-loaded and efficient.
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 no parameters and no output schema, the description is minimally complete. It states what the tool returns, though it could be slightly improved by specifying the expected format or scope.
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 has no parameters, so the description does not need to add parameter semantics. Baseline score of 4 is appropriate as there is nothing to explain.
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 'Get list of available component types' clearly states the verb (list) and resource (available component types), and distinguishes from sibling tools like add_component which perform different actions.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies it is for retrieving list of component types, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
回路図のレイアウトを最適化して文字の重複を防ぐ
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions preventing character duplication but does not detail other behavioral aspects such as whether it is destructive or reversible, especially given no annotations.
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 a single, front-loaded sentence that conveys the essential purpose with no unnecessary words.
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?
While the tool has no parameters and simple purpose, the description lacks context on what exactly is optimized (e.g., whole circuit or selection) and any prerequisites, leaving some ambiguity.
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?
There are zero parameters, so the baseline is 4; the description does not need to add parameter information, and it effectively communicates the tool's action.
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 clearly states the tool optimizes layout to prevent character duplication, specifying a verb and resource that distinguishes it from sibling tools like add_component or connect_components.
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?
No guidance is provided on when to use this tool versus alternatives, or any conditions under which it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
回路図を画像ファイルとして保存
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | DPI設定（デフォルト: 150） | |
| format | No | 出力フォーマット（デフォルト: svg） | |
| filename | Yes | 保存するファイル名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and description only states the basic action. Does not disclose file overwrite behavior, destructive effects, or any side effects on circuit state.
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?
Single sentence is concise but lacks structure; no front-loading of critical information.
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?
Minimally complete given tool simplicity, but missing details on file handling and default behavior that would aid agent decision-making.
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 coverage is 100% with parameter descriptions. Description adds no additional meaning beyond schema, so baseline 3 is appropriate.
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?
Description clearly states 'save circuit diagram as image file' with specific verb and resource. Distinguishes from sibling tools like create_circuit and get_circuit_info.
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?
No guidance on when to use versus alternatives, no prerequisites or context for invocation.
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.1.0add_componentadd_spacerconnect_componentscreate_circuitcreate_loop_circuitget_circuit_infolist_available_componentsoptimize_layoutsave_circuitScored across 9 tools
Each tool has a clearly distinct purpose: adding components, spacing, connecting, creating circuits, loops, info, listing components, optimization, and saving. No overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., add_component, connect_components, optimize_layout).
9 tools is well-scoped for a circuit schematic server, covering creation, editing, layout, and saving without being excessive or insufficient.
Core operations are present, but missing essential features like deleting components, disconnecting, or editing properties, which limits the tool's completeness for a full circuit editor.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
AI agent draws editable hand-drawn diagrams (flowchart, ER, architecture) via MCP, not static images
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
