FrontPanel MCP is an MCP server for the apps you build on FrontPanel Platform. The instrument or test tool you ship to your customers — the one that talks to your gateware on an Opal Kelly FPGA — gains an extra path: an AI assistant can read its state and operate its controls the same way a human user would.

You annotate your app — say which UI actions and gateware operations you want exposed — and FrontPanel Platform handles the rest: the local HTTPS server, the port, schema validation, sandboxing, credentials, and the wire protocol. Your job is to describe the surface; the Platform delivers it to the AI client.

From an implementation perspective, the construction follows this mental model: Each UI control in your app invokes a handler. With MCP enabled, those same handlers are also exposed as tools an AI client can call. One handler, two callers: the user and the AI.

Test and measurement work involves long sequences of parameter changes, captures, and register reads — repetitive work that AI assistants are well-suited to, provided they can reach the instrument.

Letting an AI drive an instrument has historically meant building a custom server: choosing a transport, designing a protocol, adding authentication, documenting it for clients, and maintaining it. That is a sizable project on its own.

FrontPanel MCP removes that work. The Model Context Protocol — the open standard AI clients already use — is built into FrontPanel Platform. Your app declares what it exposes; the Platform handles transport, sandboxing, schema validation, audit, per-app permissions, and the wire protocol. You write the part specific to your hardware: what each tool does.

See the Enabling MCP in our FrontPanel Platform Developers Guide to build MCP compatibility into your application. For examples of MCP usage, please see the Reference Apps section of that page.

Your desktop AI translates the request into a sequence of tool calls. UI controls move in real time and results return in chat.

The AI reads device status, toggles diagnostic registers, and explains the readings using the tools the app already provides.

The agent would make some measurements, adjust the code or parameters, rebuild, and test with new measurements taken from the real hardware system.

Similar to the hardware-in-the-loop scenario, adding a debug/console log within the software app and providing MCP tool access to that log can provide an AI agent with convenient log visibility to allow automated debugging iterations.

Claude Code writes a JavaScript snippet, runs it in the Platform’s sandboxed scripting environment, iterates on the output, and saves the final version as a reusable fixture.

A semiconductor vendor ships a DAC or ADC evaluation board as a SYZYGY peripheral that plugs into the Opal Kelly SZG-HUB1450 host board. The vendor writes the gateware that drives their part, pairs it with a FrontPanel Platform app for the operator UI, and ships the result as an .fpp their customers install alongside FrontPanel Platform.

With MCP enabled on that .fpp, the evaluating engineer can drive the eval board through an AI assistant in addition to the UI. The vendor’s gateware exposes the operations a characterization session actually needs — set DAC code, capture ADC samples, run a standard SNR or INL sweep, read on-chip register state — and the AI orchestrates them in response to natural-language requests such as:

For the vendor, this is leverage. The same gateware and tool surface serves an engineer clicking through the UI, a customer driving an AI-led characterization, and a regression script in a CI pipeline — all from the same .fpp, with no separate test harness or scripting layer to ship and maintain.

An AI-driven test runner uses the same tool surface a human operator uses. No second binary, no separate firmware server, no extra trust boundary.

An AI walks a new user through their first capture, observing live device state and acting on it with the user’s approval.

An MCP-driven script is a concise record of how a measurement was taken, and can be re-run on a different unit or bench to reproduce the result.

Four pieces sit on the path between your gateware and the AI. You write two of them; FrontPanel Platform supplies the rest.

To connect to an MCP-enabled FrontPanel Platform application, you must first enable the MCP server within the Platform. Click on the settings button (gear icon) in the sidebar menu and enable “Allow AI assistants to connect”. Once the server is running, follow the instructions below to connect your AI agent to the FrontPanel Platform MCP.

Desktop AI (e.g. Claude Desktop or ChatGPT) is an example front-end for an operator at the bench. The user describes an intent in natural language, the AI plans a sequence of tool calls, and the controls in your app move accordingly.

1. Launch the app. Open FrontPanel Platform, launch your MCP-capable app, and grant it MCP permission when prompted.
2. Connect Claude Desktop. A one-time step: add FrontPanel Platform’s local MCP endpoint to Claude Desktop’s MCP server list. The Platform’s settings dialog shows the URL and provides a copy button.
3. Operate the device. “Show me the current counter values.” “Reset counter 2 and watch it for ten seconds.” The AI selects the appropriate tool, runs it, and returns the result.

Each tool call is recorded in the Platform’s Activity window, and the operator can interrupt or override at any time.

Where the desktop client works well. Long sequences of parameter changes, parameter sweeps, and conditional waits (“watch this value until it stabilizes”) — workflows that are tedious to drive by hand but easy to describe in a sentence.

Claude Code uses the same MCP endpoint and the same tools, but the workflow shifts toward code: the user is in a terminal, and the AI is writing scripts rather than chatting through individual calls.

The key feature in this mode is the run_javascript tool (the script permission from earlier). Instead of issuing one MCP tool call per step, the AI writes a JavaScript program that calls your tools in sequence — locally, inside a sandboxed scripting context provided by FrontPanel Platform — and returns one consolidated result.

// What Claude Code might write and run via run_javascript:
await mcp.tools.waveform_set_frequency({ hz: 1_000_000 });
await mcp.tools.waveform_set_amplitude({ volts: 2.0 });
await mcp.tools.digitizer_capture_once({ duration_us: 1000 });
const samples = await mcp.tools.digitizer_read_samples();
return analyzeFFT(samples);Code language: JavaScript (javascript)

This is one round-trip on the MCP wire instead of five. For a sweep with hundreds of points, the difference is significant.

The coding-tool workflow also produces an artifact the desktop flow does not: a script that can be saved, refined, version-controlled, and replayed later as a regression test.

• “Write a script that sweeps X.” Claude Code drafts the script, runs it via run_javascript, iterates on the output, and writes the final version to a file in your repo.
• “Why is this measurement noisy?” Claude Code probes device state, plots the data, and uses the same diagnostic tools available to the support team.
• “Add a regression test for this fix.” The script the AI just ran becomes the basis of a new automated test, checked in alongside the gateware change.

Each AI client — Claude Desktop, Claude Code, Cursor, and others — has its own way of registering an MCP server, and the config formats change over time. Rather than maintain per-client setup walkthroughs in this guide, the Platform’s MCP Settings dialog offers a one-click “Copy connection prompt” action: it generates a short, paste-ready prompt containing the live endpoint URL, transport type, and any configured credentials. The user pastes that prompt into their AI client and the AI itself walks them through the client-specific setup.

For example, the prompt might look like this:

and the response from Claude Code:

Sure — Claude Code supports MCP servers, including Streamable HTTP endpoints
like the one you've described. You have two options: the  <span style="background-color: initial; font-family: inherit; font-size: inherit; text-align: initial; white-space: pre-wrap; color: initial;">claude mcp CLI</span>
<span style="background-color: initial; font-family: inherit; font-size: inherit; text-align: initial; white-space: pre-wrap; color: initial;">or a config file.</span>


<strong>Option 1 — CLI (quickest)</strong>:
claude mcp add frontpanel --transport http https://localhost:3737/mcp

That registers the server under the name frontpanel for the current project.
To make it available in every project, add --scope user:

claude mcp add frontpanel --scope user --transport http https://localhost:3737/mcp


<strong>Option 2 — .mcp.json (project-scoped, version-controllable):</strong>
Create or update .mcp.json at your project root:

{
  "mcpServers": {
    "frontpanel": {
      "type": "http",
      "url": "https://localhost:3737/mcp"
    }
  }
}


<strong>Verify:</strong>
claude mcp list

You should see frontpanel listed. Inside a session, ask me to list available
tools — you should see entries prefixed app:<runtimeId>: for each FrontPanel
app you have running.

One gotcha: https://localhost typically uses a self-signed cert. If you see
TLS errors, the cleanest fix is to trust the FrontPanel Platform certificate
in your system trust store. Setting NODE_TLS_REJECT_UNAUTHORIZED=0 works as
a quick test but should not be left on.Code language: plaintext (plaintext)