Figma Context MCP
Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.
Beschreibung vom Entwickler (englisches Original)
AI-agent MCP server for FPGA design: compile, validate & generate Verilog from C⏚ HDL.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
CG_JARDu brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"neosyn-fpga": {
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}Führe das in deinem Terminal aus
claude mcp add neosyn-fpga --env CG_JAR=your-value -- uvx neosyn-fpga-mcpTrag die leeren Werte ein, bevor du ihn startest.
In .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"neosyn-fpga": {
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"neosyn-fpga": {
"type": "stdio",
"command": "uvx",
"args": [
"neosyn-fpga-mcp"
],
"env": {
"CG_JAR": "your-value"
}
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
CG_JAR envDiese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde über die Domain neosyn.io bestätigt (die Registry prüft, wem die Domain gehört)
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (1.4.0) kam vor 38 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv) auf deinem Computer.
In derselben Kategorie: Figma Context MCP, Claude Real Video, Figma MCP Server
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
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.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
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] } }
Nur der Anfang wird gezeigt; den Rest findest du im Repo