Figma Context MCP
Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.
作者による説明(英語の原文)
AI-agent MCP server for FPGA design: compile, validate & generate Verilog from C⏚ HDL.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
CG_JAR必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます
{
"mcpServers": {
"neosyn-fpga": {
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}ターミナルでこれを実行します
claude mcp add neosyn-fpga --env CG_JAR=your-value -- uvx neosyn-fpga-mcp動かす前に、空欄の値を入力してください。
プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"neosyn-fpga": {
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"neosyn-fpga": {
"type": "stdio",
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
CG_JAR envこの設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック
レジストリ名はドメイン neosyn.io で確認済みです(レジストリがドメインの所有を確認しています)
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(1.4.0)がレジストリに届いたのは38 日前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにPython (uv)も必要です。
同じカテゴリには:Figma Context MCP, Claude Real Video, Figma MCP Server
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.
Let any LLM watch a video locally — and search everything it has ever watched.
The Figma MCP server brings Figma design context directly into your AI workflow.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
An MCP server that hands the C⏚ FPGA toolchain to an AI agent. The model writes hardware; the server compiles, simulates and synthesis-checks it against the real compiler, and hands back structured diagnostics the model can act on.
That is the difference worth caring about. An LLM asked for Verilog will confidently emit something that does not build, does not synthesize, or silently folds away to nothing. Here every step is judged by the same compiler a human uses.
Two parts work together:
Knowledge gives a good first draft; the compiler in the loop makes it right. Both are model-agnostic — any stdio-MCP host (Claude Desktop, Claude Code, Cursor, Cline) works, and the context pack works with any LLM at all.
Why not fine-tune? C⏚ is a niche language with little public code, and it gains features every release. A fine-tuned model is expensive and goes stale. In-context knowledge plus a verification loop costs nothing to retrain, tracks the language as the compiler evolves, and converges by *running* code rather than recalling it.
pip install neosyn-fpga-mcp
Then point it at a C⏚ compiler jar:
export CG_JAR=/path/to/cg-language-server.jar
Two ways to get that jar:
NEOSYN_CG_LICENSE to it, or keep it at the default path the extension uses. Without one, every tool reports the licence problem instead of running.cg_capabilities reports which one you have and what it can do, probed rather than assumed.
PATH — the jar's bytecode targets 17.yosys on PATH for cg_synth (override with $YOSYS); iverilog for cg_simulate(simulator='iverilog'). Neither is needed for cg_check, cg_generate_verilog, or the bytecode simulator.Smoke-test the verification core without an MCP client:
python3 - <<'EOF'
from neosyn_fpga_mcp import cg_mcp_server as cg print(cg.simulate("package d;\ntask T { properties { test: { v:[1,2,3] } }\n" " out push u8 v; u8 c; void setup(){c=0;}\n" " void loop(){c=c+1; v.write(c);} }")) EOF
Add a server entry. Use absolute paths.
{
"mcpServers": { "cg": { "command": "neosyn-fpga-mcp", "args": [], "env": { "CG_JAR": "/abs/path/to/cg-language-server.jar" } } } }
The same command/args/env shape works for Claude Desktop, Claude Code, Cursor, Cline and other stdio-MCP hosts.
Then load `cg_context.md` as the system prompt (or paste it at the top of the conversation). The model now knows the language *and* can verify it.
13 tools. Every tool that takes source accepts source (a C⏚ string) and an optional extra_files map ({"Defs.cg": "..."}) for imported bundles/tasks.
These are the only names that exist, and the server says so rather than hoping you read this table: a call to a tool that does not exist comes back with the whole list and the closest real name (cg_compile → "did you mean cg_check?"), cg_capabilities carries the list, and the first call of a session carries it once. The list is generated from the tool registry, so it cannot drift out of step with the table below.
| Tool | Params (besides source / extra_files) | Returns | When to use it |
|---|---|---|---|
cg_check | — | {ok, diagnostics:[…], warnings:[…], summary} | After cg_lint, on any draft — fix every diagnostic before simulating. warnings carries validator findings the compiler accepts but objects to (bool == 1, assigning to a const): ok stays true because the program does compile, and the summary says so, because ok is the field that gets acted on. Needs a compiler ≥ 2.10.0 — older ones report nothing here. |
cg_simulate | timeout=60, simulator='bytecode' | {ok, simulator, timed_out, diagnostics, output} | The ground-truth correctness check. output holds port values + print() lines; a properties { test: {...} } block self-checks. Iterate until ok. |
cg_generate_verilog | target='verilog', output_dir=None, top=None | {ok, file_count, files:{path:content}} (+ {output_dir, written} when persisted) | After simulate passes, to hand off RTL. target is 'verilog' or 'vhdl'. Pass output_dir (relative to $PROJECT_ROOT) to write the files to disk and keep them. Pass top (an entity name) to emit only that entity and what it instantiates; needs a compiler newer than 3.4.0, and an older one is refused rather than emitting everything. |
cg_synth | top=None, timeout=180, flow='generic' | {ok, verdict, top, flow, cells, arith_ops, latches, warnings, stat, problems, output} | The strongest correctness signal — yosys-synthesizes the Verilog. verdict ∈ REAL / FOLDED (constant-folded — inputs weren't on ports) / SUSPECT (latches inferred) / ERROR, so you can't confabulate success. warnings explains a degenerate datapath or inferred latch. |
cg_capabilities | — | {ok, jar, jar_present, bytecode_simulator:{available,reason,detail}, simulators:[…], tools:{…}, advice} | What this host can actually do, probed rather than assumed. The fast bytecode simulator ships with the commercial distribution and is absent from the open-source compiler, so any flat claim about it is wrong in one of the two environments — call this before deciding how to verify. |
cg_scaffold | kind='task', name, package, inputs, outputs, verify=True | {ok, kind, source, holes:[{line,text}], verified:{check,simulate}, message} | Start here when writing new C⏚ from a blank file. Returns a complete, COMPILING, self-checking skeleton with the datapath left as >>> FILL IN holes, verified green before you get it — so any later failure is your edit. kind ∈ task (a sync task whose test: block value-checks every output cycle by cycle — the default and the strongest) / fsm / stream / network / generic. inputs/outputs are "name:type" strings, honoured for task and stream. Complements cg_example: scaffold when writing something new, example when a validated implementation of the kernel already exists. |
cg_example | pattern='', k=1 | no pattern → {ok, index:[{name,kind,use_when,tags}]}; a pattern → {ok, name, kind, source, …, runners_up:[…]} | Scored lazy lookup into the validated-code dictionary (NOT search). Specificity-weighted, so 1/sqrt→RSqrt but sqrt→FixedSqrt; returns 1-2 runners-up to self-correct. k>1 returns more sources for composition. |
cg_lint | — | {ok, findings:[{rule,line,severity,message,fix}]} | Static checks for code the compiler accepts and is still wrong. Chiefly a test: fixture that drives inputs but compares no output — it passes even with a dead design. No jar and no simulator, so run it on every draft before cg_check, and again before claiming a design is verified. |
cg_suggest_for_error | message | {ok, recipe, hint, source} | Map a compiler rejection to the recipe with the fix pattern (div/shift-by-variable → Recip; data-dependent loop bound → SeqDiv). cg_check/cg_simulate/cg_generate_verilog auto-attach this as a suggestion when a diagnostic matches. |
cg_report | report_dir='fpga/build', schematics=True | {ok, report, kernels, sim_ok, message} | Finalize the FPGA report: renders /report.html (synthesis table with the REAL/FOLDED/SUSPECT verdict and cell counts, the simulation PASS/FAIL, the generated-Verilog list, and best-effort datapath SVGs). Does no synthesis — the rows accumulate as a byproduct of passing the same report_dir to cg_synth and cg_simulate. |
cg_fsm | task=None | {ok, diagnostics, fsm} | Confirm a task's compiled state machine has the intended states/transitions. |
cg_graph | network=None | {ok, diagnostics, graph} | Confirm a network's compiled wiring (instances, ports with widths/interfaces, connections). |
cg_docs | topic='' | no topic → {ok, topics:[{topic,description}]}; a topic → {ok, topic, description, content} | Fetch a markdown knowledge doc on demand. context = the core C⏚ language pack; riscv = the worked RV32I CPU reference (loadable single-cycle core + reusable patterns for CPU-shaped hardware: barrel shifter, signed/unsigned widening, sub-word load/store, boot-stream program loading, testbench capture). Read riscv when building a processor/decoder/datapath/stack machine. |
Two tools take a backend selector:
'bytecode' *(default)* — the compiler's fast bytecode simulator. No HDL toolchain needed; a properties { test: {...} } block self-checks. cg_simulate(src) or cg_simulate(src, simulator="bytecode").'iverilog' — generate Verilog + a testbench and run Icarus Verilog (vvp), a Verilog-level cross-check. A testbench is emitted only for a network whose name contains `Test` with a capital T (e.g. network TestFoo); a lowercase _test network drives the bytecode sim's test property only, not iverilog. Needs iverilog on PATH. cg_simulate(src, simulator="iverilog").'verilator' — accepted for forward-compat but reported unavailable unless the verilator binary is installed. cg_simulate(src, simulator="verilator").'generic' *(default)* — portable synthesizability check (synth). cg_synth(src) or cg_synth(src, flow="generic").'ice40', 'ecp5', 'xilinx', 'gowin', 'intel' — maps to that part's primitives (LUTs/BRAM/DSP). cg_synth(src, flow="ice40").top defaults to the first non-testbench task/network (the synthesizable DUT); pass it when a file holds several designs. Override the yosys binary with $YOSYS.
package).cg_lint → free and instant; catches the mistakes the compiler will happily accept, above all a test: block that checks nothing.cg_check → fix every diagnostic, and read warnings: those are the compiler's own objections to code it will nonetheless accept.cg_simulate → confirm ok: true and that the output matches intent.cg_generate_verilog once it simulates, to hand off RTL.cg_synth (optional) → confirm the Verilog maps to real hardware (ok: true, a sensible cells count, no problems).Step 2 exists because steps 3–4 can BOTH pass on a design that does nothing: a fixture with no output vector is green against a dead DUT. cg_lint is the only step that catches that, and it costs nothing to run.
The loop in steps 2–3 is the point: the model writes, the compiler judges, the model fixes. cg_context.md ends with the same protocol so the model follows it even without separate instruction.
from neosyn_fpga_mcp import cg_mcp_server as cg
src = '''package com.example.demo; task Counter { properties { test: { value: [1, 2, 3] } }
冒頭だけを表示しています。続きはリポジトリで読めます