Provides integration with Autodesk Fusion to replay FCOH design intent and operation history, generating native F3D parts and STEP exports through the Fusion API.
Provides integration with FreeCAD to generate new parts from FCOH YAML design intent, saving native FCStd and STEP files and preserving FCOH metadata.
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., "@fcoh Validate examples/mounting-bracket.fcoh.yaml and build a new part in FreeCAD."
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.
v0.1.0 / Experimental preview / MIT License / 無料・サポート保証なし
FCOH（Feature-Centric Operation History）形式0.3の最小試作です。 設計意図つきYAMLから、新しい部品をFreeCADまたはFusionで作ります。 ソフトウェアの版番号は0.1.0、実装している形式の版番号は0.3です。 汎用CADファイル変換ソフトではなく、CADに依存しない設計意図・操作履歴の記録と再現を試すOSSです。
FCOH is an experimental, human/LLM-readable YAML representation of CAD design intent and operation history, replayed through native FreeCAD and Autodesk Fusion APIs. It is not a general CAD file converter or a complete round-trip interchange format.
2026-09-13: 両CADへのMCP経由の部品生成と、ネイティブ形式保存・再読込が成功しました。 サンプルのSTEP同士の形状差分も0 mm³でした。検証概要を参照してください。
本プロジェクトのソースコードはMIT Licenseで無償公開しています。 現状有姿で提供し、保証、個別サポート、返信、修正、継続保守の約束はありません。 製造や実務で使う前に、生成形状・寸法・履歴を利用者自身で検証してください。 FreeCAD、Autodesk Fusion、Python依存パッケージなどの第三者製品には、それぞれのライセンスが適用されます。 Fusion本体は同梱せず、その利用権や無償利用を提供するものではありません。
Related MCP server: CAD-Query MCP Server
PowerShell 7、Git、Python 3.11以上、uv、7-Zipを用意してください。
7-Zipは C:\Program Files\7-Zip\7z.exe にあることを前提とします。
Fusion連携は別途Autodesk Fusionをインストールし、利用可能なアカウントで起動しておきます。
git clone https://github.com/SoseiUncle/fcoh.git
cd fcoh
pwsh -File scripts/setup.ps1
.\.venv\Scripts\python.exe -m unittest discover -s tests -vセットアップはFreeCAD 1.1.3公式ポータブル版をダウンロードし、SHA-256を照合して
vendor/ へ展開します。Python依存は uv.lock に従って .venv/ へ導入します。
このリリースはソースチェックアウトから使用してください。単体wheel/PyPI配布には対応していません。
フォルダを移動した場合はFusionアドインとMCPの登録をやり直してください。
このフォルダをVS CodeやCodexのプロジェクトとして開いてください。
コマンドはPowerShell 7で、このフォルダから実行します。
サンプルの生成だけなら Generate-FreeCAD.cmd または Generate-Fusion.cmd を
ダブルクリックしても実行できます。Fusion用はFusionを開いた状態で使います。
.\.venv\Scripts\python.exe -m fcoh.cli validate examples/mounting-bracket.fcoh.yaml
.\.venv\Scripts\python.exe -m fcoh.cli build examples/mounting-bracket.fcoh.yaml --cad freecad生成先は毎回別の outputs/<job_id>/ です。FreeCADでは part.FCStd と part.step、
Fusionでは part.f3d と part.step を保存します。request.json に実行内容、
source.fcoh.yaml に入力の写し、result.json に寸法・体積・履歴・ハッシュを残します。
サンプルは80×40×30 mm、底板厚6 mm、直径6 mmの穴4個を持つブラケットです。
examples/mounting-bracket.fcoh.yaml の params の数値を変更し、再生成してください。
寸法の正本はFCOHです。CAD内で変更した寸法を自動的にFCOHへ戻す機能はありません。
初回は次のコマンドでFcohBridgeをユーザー用AddInsフォルダへ導入します。
pwsh -File scripts/install-fusion.ps1その後Fusionを再起動し、「ユーティリティ → スクリプトとアドイン → アドイン」で
FcohBridge を選び、「実行」「起動時に実行」を有効にします。
Fusionのモデリング画面で、実行中の編集コマンドを完了またはキャンセルしてから:
.\.venv\Scripts\python.exe -m fcoh.cli capabilities
.\.venv\Scripts\python.exe -m fcoh.cli build examples/mounting-bracket.fcoh.yaml --cad fusion --wait 180アドインはローカルの .runtime/queue/ を読み、FusionのCustomEventでメインスレッドへ処理を渡します。
通信ポートやクラウド保存は使用しません。Fusion自体の通常のログイン・ライセンス通信は必要です。
生成文書はFusion上に開いたまま残り、アーカイブはローカルに保存されます。
ジョブは10分で期限切れになり、期限後には生成しません。
生成ロジックはジョブごとにこのプロジェクトの固定パスから読み込みます。
ブリッジ本体を更新したときは scripts/install-fusion.ps1 を実行し、Fusion本体を再起動してください。
この環境ではアドインの停止・実行だけだと古いPythonコードが残ることを実機確認しています。
導入済みアドインは更新前に .runtime/backups/ へ保存します。
Codex CLIを利用する場合、次でユーザー設定に fcoh として登録できます。
pwsh -File scripts/register-mcp.ps1新しく開くセッションで利用してください。既存の会話へツールが自動追加されるとは限りません。 通し検証スクリプトは同じ起動コマンドへstdioで接続します。
ツール | 用途 |
| 対応範囲、FreeCADの配置、Fusionアドインの起動応答を確認 |
| YAMLの型・単位・参照・操作順を検証 |
| 新しい部品を生成。FusionはジョブIDを返す |
| 結果・生成ファイル・計測値を取得 |
依頼例: 「examples/mounting-bracket.fcoh.yamlを検証して、FreeCADで新規部品を生成してください。」
別のMCPクライアントでも、次のコマンドをstdioサーバーとして登録できます。
command: <absolute-path-to-fcoh>\.venv\Scripts\python.exe
args: ["-m", "fcoh.server"]再登録は scripts/register-mcp.ps1、Codex登録の解除は codex mcp remove fcoh です。
.\.venv\Scripts\python.exe -m unittest discover -s tests -v
.\.venv\Scripts\python.exe scripts/verify_mcp.py --cad freecad
.\.venv\Scripts\python.exe scripts/verify_geometry.py
.\.venv\Scripts\python.exe scripts/verify_mcp.py --cad fusion
.\.venv\Scripts\python.exe scripts/verify_cross_cad.pyevidence/ に通し検証の結果を保存します（PC固有パスを含むためGit管理対象外）。
Fusion用の検証はアドインが動作している必要があります。
MCP検証では、部品体積を幾何学的な計算値と比較し、外形寸法、ソリッド数、操作順、
出力ファイルの実在とハッシュ、元YAMLが変更されないことを確認します。
FreeCADでは保存後のFCStdとSTEP再読込、FCOHメタデータ保持も検証します。
FusionでもF3Dを再読込して形状・履歴・FCOH属性を確認します。
両CADの成功後、STEP同士の差分ソリッド体積を比較します。
単位mm、単一部品、XY基準面とZオフセット。
矩形・円の閉じたスケッチ、+Z押し出し、-Zポケット。
meaning / why とFCOH IDをCAD内のプロパティ／属性へ保存。
FreeCADではSpreadsheet、Fusionではユーザーパラメータにも寸法を保存。
押し出し長さはCADの名前付きパラメータに結び付ける。輪郭全体の寸法変更はYAMLから再生成する。
未対応の指定はエラーにします。STEP/STL入力、フィレット、面取り、スケッチ拘束の一般化、 アセンブリ、既存CAD履歴の抽出、完全な往復変換、CAD内の編集結果のFCOHへの書き戻しは未対応です。 このスキーマはFCOH全仕様を確定したものではなく、実行できる最初の部分集合です。
fcoh/ は共通処理、schemas/ はスキーマ、adapters/ はCADごとの処理です。
セットアップ後、vendor/ にFreeCADポータブル版、.venv/ に専用Python環境が作られます。
依存関係は uv.lock へ固定し、OS全体のMCP SDKは変更していません。
再構築はPowerShell 7、uv、7-Zipを用意して scripts/setup.ps1 を実行します。
FreeCAD公式アーカイブのSHA-256を照合してから展開します。
参照: FreeCAD公式配布、 Fusion CustomEvent公式例、 MCP Python SDK、 Codex MCP設定。
Create a NEW part under outputs/. cad: freecad or fusion. Fusion is asynchronous; use fcoh_status.
| Name | Required | Description | Default |
|---|---|---|---|
| cad | No | freecad | |
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the output location and the asynchronous nature of Fusion, but it leaves out other relevant behavior such as repeatability, failure behavior, or what the tool returns.
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 two sentences with no fluff: it front-loads the primary action, then gives cad options and the async caveat. Every sentence contributes and the structure helps quick scanning.
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 simple two-parameter tool, the description conveys the output path and the key behavioral difference between cad modes. It is incomplete about the required `file` parameter and the `job_id` scoping, but overall it still gives an agent enough to select the tool safely.
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 for both parameters. It adds meaning to the cad parameter by naming the valid values and the async consequence, but the required `file` parameter is never explained, leaving its format and role ambiguous.
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 opens with a specific verb and resource ('Create a NEW part under outputs/<job_id>'), making the primary function unmistakable. It also distinguishes this build tool from status checking by pointing to fcoh_status for the Fusion async case.
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 clear usage guidance: 'Fusion is asynchronous; use fcoh_status' tells the agent when to follow up with a sibling tool. However, it does not explicitly address when not to use other siblings like fcoh_validate or fcoh_capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report supported FCOH steps and actual CAD adapter readiness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. The verb 'Report' indicates a read-only, non-destructive operation, and 'actual ... readiness' suggests a live check rather than a static config lookup. However, it doesn't disclose error behavior, prerequisites, or what happens if the CAD adapter is unavailable.
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?
A single sentence with no filler. Key terms are front-loaded, and every word contributes to the tool's 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?
For a zero-parameter, read-only capability query, the description covers the essentials: what is reported and that it reflects actual readiness. Without an output schema, it could offer a hint about the response shape, but this is not a serious gap for such a simple tool.
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 tool has zero parameters, so the baseline is 4. The description needs to add no parameter meaning because there is nothing to configure or pass in.
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 ('Report') and a precise resource ('supported FCOH steps and actual CAD adapter readiness'). This clearly distinguishes it from sibling tools like fcoh_validate and fcoh_build, which imply actions, even though it doesn't name them 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?
The purpose implies this tool should be used when an agent needs to know which FCOH steps are supported or whether the CAD adapter is ready, but it gives no explicit when-to-use or when-not-to-use guidance and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read CAD generation status, measured geometry, and exported artifact paths.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Read' and the listing of outputs indicate a read-only operation and what to expect, but it does not address edge cases, error behavior, or whether the tool can return partial/in-progress results.
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?
A single, front-loaded sentence states the action and object with no filler. Every word contributes to the description.
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 simple one-parameter status tool with no annotations or output schema, the description names the key return categories (status, geometry, artifact paths) and the action. It lacks explicit return-format details, but the low complexity makes the description reasonably complete.
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 schema contains a single undocumented job_id parameter and 0% coverage. The description provides context by implying job_id refers to a CAD generation job whose status is being read, but it does not explicitly define the parameter or its expected format/origin.
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 uses a specific verb ('Read') and identifies a clear resource: CAD generation status, measured geometry, and exported artifact paths. It clearly communicates what the tool does, though it does not explicitly differentiate itself from sibling tools like fcoh_build or fcoh_validate.
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?
There is no guidance on when to use this tool relative to its siblings or how it fits into the CAD workflow. The description does not mention prerequisites (e.g., a job created by fcoh_build) or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a project-relative .fcoh.yaml file without creating a CAD document.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It usefully discloses that the tool does not create a CAD document, which is a meaningful behavioral constraint. However, it does not describe side effects, permissions, exit behavior, or return value beyond that single trait.
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?
A single sentence contains the verb, the target resource, the path constraint, and a key behavioral distinction. There is no repetition of schema fields and no filler.
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 simple single-parameter tool with no output schema, the description covers the essential call context: what file to pass and the key behavioral point. It could add what 'validate' actually checks or what happens on invalid input, but it is otherwise 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 schema gives 0% description coverage, leaving the single 'file' parameter unannotated. The description compensates by specifying that the parameter is a project-relative .fcoh.yaml path, which is valuable semantic information for one parameter.
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 uses a specific verb ('Validate a project-relative .fcoh.yaml file') and states the resource and a key constraint ('without creating a CAD document.' It clearly distinguishes itself from siblings like fcoh_build.
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 phrase 'project-relative' and 'without creating a CAD document' gives clear context for when this validation tool is appropriate and implies an alternative build path. It does not explicitly name sibling alternatives or state exclusion criteria, but the intended use is still clear.
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.0fcoh_buildfcoh_capabilitiesfcoh_statusfcoh_validateScored across 4 tools
Each tool serves a distinct function: capabilities reports environment, validate checks config, build initiates creation, status tracks progress. No overlapping purposes or ambiguous boundaries.
All tools follow a consistent 'fcoh_<verb>' pattern, making the API predictable and easy to navigate. The verb choice clearly indicates the operation.
Four tools is well-scoped for a focused CAD generation pipeline—enough to cover the essential steps without redundancy or bloat.
The set covers the core workflow: capability check, validation, build, and status. Minor gaps like cancellation or listing are absent, but the primary lifecycle is complete for a simple create-and-monitor use case.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Convert Revit files to XKT, IFC, or DWG and query BIM data via natural language.
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
