Prototype · Preview: every server in the official registry, synced every 30 minutes. Reviews and accounts come in a later step.
PopNx MCPMCP servers for people who use AI · explained in plain words

Neosyn Fpga MCP

by Neosyn-Logicversion 1.4.0i★ –iRuns on your computer
Registry nameio.neosyn/neosyn-fpga-mcp

Install

Overview

Description from the maker (original English)

AI-agent MCP server for FPGA design: compile, validate & generate Verilog from C⏚ HDL.

PopNx MCP’s three pillars

These three are never merged into one score: opinions, measurements and popularity are different things.

What you can do with it

We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.

  • Connection: Runs on your computer
  • Transport: stdio
  • Category: Design, images & audio

Install

Pick the AI app you use, then copy the settings.

Before you install

  • Basic checks: 1 of 1 passed
  • Runs on your computer with your user’s permissions (files, network, apps).
  • You fill in yourself: CG_JAR

You need

  • PyPIPython’s uv installed (for the uvx command)

Which app do you use?

Pick your app above. We remember it, so next time the button says “Install in …”.

Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json

{
  "mcpServers": {
    "neosyn-fpga": {
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

Run this in your terminal

claude mcp add neosyn-fpga --env CG_JAR=your-value -- uvx neosyn-fpga-mcp

Fill in the empty values before running it.

Open in Cursor

Or copy the settings yourself

Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json

{
  "mcpServers": {
    "neosyn-fpga": {
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.

Open in VS Code

Or copy the settings yourself

Paste into .vscode/mcp.json in your project

{
  "servers": {
    "neosyn-fpga": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "neosyn-fpga-mcp"
      ],
      "env": {
        "CG_JAR": "your-value"
      }
    }
  }
}

Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.

This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.

Your choice stays on this device in a cookie; no account needed.

Values you fill in

  • CG_JAR env
    Path to the C⏚ compiler jar (cg-language-server.jar). Download the prebuilt jar from the cg-compiler GitHub releases.

These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.

What it can do

Runs on your computer; the tool list appears in your AI app after you install it.

Basic checksi

We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 8, 2026

  • ✓ Pass

    Maker matches the repo

    The registry name was verified against the domain neosyn.io (the registry checks domain ownership)

  • … Not checked yet

    Still maintained

    We have not read this repo from GitHub yet

  • … Not checked yet

    Has a licence

    We have not read this repo from GitHub yet

  • – Not applicable

    Endpoint responds

    This one runs on your computer; there is no internet endpoint

  • – Not applicable

    Sign-in with OAuth

    Runs on your computer and uses local settings instead

  • … Not checked yet

    No hidden instructions in tool descriptions

    Runs on your computer; we can only read tool lists from internet endpoints

Compared with others in Design, images & audioi

  • More stars than 0% of the other 2764 servers in this category
  • Published to the registry more recently than 41% of the other 2764 servers in this category
  • Basic checks equal to or better than 100% of the other 2764 servers in this category

Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.

Common questions

Is Neosyn Fpga MCP safe?

It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.

What keys or codes does it need?

The registry does not list a required key, though some servers ask you to sign in on first use.

Does it run on my computer or in the cloud?

It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).

Is it still maintained?

The GitHub repo last changed –, and the latest version (1.4.0) reached the registry 39 days ago.

Which apps can use it?

Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.

What can I use instead?

In the same category: Figma Context MCP, Claude Real Video, Figma MCP Server

Alternatives

Servers in the same category from other makers, sorted by stars.

Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi

Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.

Runs on your computer★ 16,165MITUpdated 5 months ago
Install

Claude Real Video

by HUANGCHIHHUNGLeo

Let any LLM watch a video locally — and search everything it has ever watched.

Runs on your computer★ 2,284MITUpdated 2 months ago
Install

Figma’s official server gives AI your design data so it can turn designs into code or describe them accurately. Connects to Figma’s cloud.

Runs in the cloud★ 2,152Updated 13 months ago
Install

README from the maker

Open the README

Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.

neosyn-fpga-mcp

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:

  1. `cg_context.md` — a knowledge pack. Load it as the system prompt and the model can write plausible C⏚: the mental model, types, ports, structs/enums/generics, the standard library, and the gotchas that sink first drafts.
  2. the MCP server — the compiler as tools, so the model verifies its own output instead of recalling it.

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.

Install

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:

  • Open source — a prebuilt jar from cg-compiler releases, or build it from source.
  • Commercial — the jar inside an installed Neosyn C⏚ extension, which adds the fast bytecode simulator and VHDL output. It needs your licence file: set 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.

Requirements

  • Python 3.10+
  • Java 17 or newer on PATH — the jar's bytecode targets 17.
  • Optional: 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

Connect it to an MCP host

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.

Tools the server exposes

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.

ToolParams (besides source / extra_files)ReturnsWhen 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_simulatetimeout=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_verilogtarget='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_synthtop=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_scaffoldkind='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_examplepattern='', k=1no 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_errormessage{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_reportreport_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_fsmtask=None{ok, diagnostics, fsm}Confirm a task's compiled state machine has the intended states/transitions.
cg_graphnetwork=None{ok, diagnostics, graph}Confirm a network's compiled wiring (instances, ports with widths/interfaces, connections).
cg_docstopic=''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.
Choosing a backend

Two tools take a backend selector:

  • `cg_simulate(source, simulator=…)` — which simulator runs the design:
  • '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").
  • `cg_synth(source, flow=…)` — which yosys synthesis flow runs:
  • 'generic' *(default)* — portable synthesizability check (synth). cg_synth(src) or cg_synth(src, flow="generic").
  • a vendor FPGA family — '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.

How the model should use it

  1. Draft C⏚ (always starting with package).
  2. cg_lint → free and instant; catches the mistakes the compiler will happily accept, above all a test: block that checks nothing.
  3. cg_check → fix every diagnostic, and read warnings: those are the compiler's own objections to code it will nonetheless accept.
  4. cg_simulate → confirm ok: true and that the output matches intent.
  5. cg_generate_verilog once it simulates, to hand off RTL.
  6. 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.

The loop, end to end
from neosyn_fpga_mcp import cg_mcp_server as cg

src = '''package com.example.demo; task Counter { properties { test: { value: [1, 2, 3] } }

Only the beginning is shown; read the rest in the repo

Ask PopNx