# How to build a VST3 or CLAP plugin with an AI coding agent

By Sonorie. Published 2026-10-27, last changed 2026-10-27. https://sonore.dev/blog/build-audio-plugin-with-ai-coding-agent/

An AI coding agent can write a working VST3 or CLAP plugin, but not from memory. Agents fail on C++ audio frameworks by inventing names that sound right, and by writing code that compiles but breaks the audio thread. The fix is to give the agent the framework's real API to check against, a set of rules it cannot guess, and a definition of "done" that a validator enforces. That is what the Sonore SDK ships for Claude Code, Codex, Cursor and any MCP client. Of the established plugin frameworks, it is the only one with an official MCP server: JUCE and iPlug2 ship agent instruction files, but nothing an agent can query.

## Why agents get audio plugins wrong

An unfamiliar C++ library rarely makes an agent refuse. It makes the agent improvise, and audio plugins punish improvisation in three ways:

1. **Invented names.** A class that should exist, such as a `CompressorPro`, or a real class given a method from a different framework. The code reads perfectly and does not compile.
2. **Code that compiles and is still wrong.** An allocation or a lock inside `process()`, which runs on the audio thread. It works on the developer's machine and drops out under load in someone's session.
3. **Rules that live nowhere in the API.** A look-ahead limiter that does not report its latency smears every parallel mix it sits in. A parameter table reordered in version 1.1 loads old sessions into the wrong controls. Nothing in a header says either.

The first problem is about names, the second about behaviour, the third about conventions. A larger model helps with none of them, because the information is not in its training data reliably enough to trust.

## What the agent needs instead

Three things, each answering one of those failure modes:

| The agent needs | Because | In the Sonore SDK |
| --- | --- | --- |
| A way to check that a name exists | Memory produces plausible names | An MCP server whose search covers all 766 public types in 282 headers |
| The rules a plugin must follow | They cannot be read off the API | The skill and `sonore_rules`: process signatures, latency, what the audio thread forbids |
| A definition of done | "It compiles" is not "it works" | Generated projects with a self-check and a real-time audit in `ctest`, ready for the validators |

All three are generated from the SDK's headers by the same script. That matters more than it sounds. A hand-written cheat sheet for agents drifts from the code within a release, and then it is a second source of invented names. Here, `npm run verify:llms` fails the build if the files disagree with the headers, and `npm run verify:mcp` checks that search finds every public type, so "no match" from the server is a real answer rather than a gap in an index.

## The MCP server's six tools

The server runs from a local checkout over stdio, needs only Node.js, and every tool only reads files in the checkout.

| Tool | What it answers |
| --- | --- |
| `sonore_search` | Does this class, function, alias or concept exist, and where. Words match in any order, so "ladder filter" finds `LadderFilter`. |
| `sonore_declaration` | The real declaration, with the comment that explains why it exists. |
| `sonore_header` | What one header is for, its public types, and the include line. |
| `sonore_headers` | Every header, with a one-line purpose. |
| `sonore_example` | A complete working plugin: effect, instrument, sidechain, aux outputs, MIDI output, sampler, reverb, native editor and more. |
| `sonore_rules` | The shape of a plugin, which `process` signature makes an instrument, latency reporting, and what is forbidden on the audio thread. |

An example of the difference it makes. Asked for `CompressorPro`, the server answers that nothing in the SDK matches. Asked for "ladder filter", it returns `LadderFilter` and the diode ladder, with the headers they live in. The agent writes the second, not the first.

## Setting it up

Clone the SDK, then add the skill and the server to your agent. For Claude Code:

```sh
git clone https://github.com/SonorieAI/sonore-sdk "$HOME/sonore-sdk"
npx skills add SonorieAI/sonore-sdk --skill sonore-sdk -a claude-code -g
claude mcp add --scope user sonore-sdk -- node "$HOME/sonore-sdk/scripts/mcp-server.mjs"
```

Codex takes `-a codex` and `codex mcp add`. Cursor and Antigravity take the skill with `-a cursor` or `-a antigravity` and the server in their MCP config file. The **Install Skill & MCP** button on [the home page](/#agents) has the exact commands for each. Without the `skills` command-line tool, copying `skills/sonore-sdk` into the agent's skills folder does the same job.

## A first prompt that works

Be specific about the plugin, and say what done means:

```txt
Make a tape-style saturator plugin with Drive, Tone and Mix.
Start from a generated Sonore project. Look up every sonore:: name
before you use it. It is done when it builds, ctest passes, and
clap-validator and pluginval run clean.
```

With the skill loaded, the agent follows the SDK's workflow on its own: it generates a project with `sonore_new_plugin.cmake`, writes the DSP into the one `src/plugin.cpp`, checks names as it goes, and builds. One source file becomes a `.clap`, a `.vst3`, an Audio Unit on macOS, an LV2 bundle and a standalone app, and the same project builds an AUv3 for iPhone and iPad and an Android app.

## What "done" means

A plugin that compiles is a draft. The generated project gives an agent three checks to work through, in order of what they prove:

1. **It builds** every format from one compile.
2. **`ctest` passes.** It runs two tests. The standalone app's `--verify` renders audio offline and asserts that it is healthy. In a project built from an SDK checkout, the real-time audit (`sonore_add_rt_test`) counts every allocation made on the audio thread across sample rates and block sizes, and fails on any. The SDK holds its own examples to the same bar: nine sample rates from 8 kHz to 384 kHz, block sizes from 1 to 8192, zero allocations.
3. **The validators pass.** `clap-validator` and `pluginval` load the plugin the way hosts do. Both project templates pass them at pluginval's strictness 10 as generated, so a failure is something the agent introduced.

The audit and the validators catch what reading the code does not, which is why they belong in the prompt.

## What still needs you

An agent with the right tools writes a plugin that loads, passes validation and does not allocate on the audio thread. It cannot tell you whether the saturator sounds good, whether the interface feels right in a session, or whether a host you care about behaves. Listening, taste and testing in your own DAW stay with you. So do the formats with gatekeepers: AAX needs Avid's developer agreement and PACE signing, which no framework can grant.

For the step-by-step version, without an agent, read [Getting started](/docs/getting-started/). For how the SDK compares with JUCE, iPlug2 and the rest, see [Audio plugin frameworks compared](/blog/audio-plugin-frameworks-compared/).

## Sources

- [Sonore SDK repository](https://github.com/SonorieAI/sonore-sdk): the README's "Writing plugins with a coding agent" section, `llms.txt`, and `scripts/mcp-server.mjs`
- [The sonore-sdk skill](https://github.com/SonorieAI/sonore-sdk/tree/main/skills/sonore-sdk)
- [Model Context Protocol specification](https://modelcontextprotocol.io/specification)
- [Agent Skills format](https://agentskills.io)
- [llms.txt convention](https://llmstxt.org)

## Questions

### Can ChatGPT, Claude or Cursor write a VST3 plugin?

Yes, if the agent can check the framework's real API and build the result. Left to memory, agents invent class and method names that do not exist in the framework they are using. With the Sonore SDK's MCP server and skill installed, the agent looks every name up, starts from a generated project, and treats the plugin as done only when it builds and the validators pass.

### What is the Sonore SDK MCP server?

A Model Context Protocol server that runs locally from a checkout of the SDK, over stdio, with no dependencies beyond Node.js. Its six read-only tools answer whether a name exists, show its real declaration, describe a header, list headers, return a complete example plugin, and state the rules of a plugin. It speaks MCP 2026-07-28 and the older `initialize` handshake.

### Does the MCP server send my code anywhere?

No. It reads the SDK checkout on your machine and nothing else: no network access, no telemetry, and no tool that writes files.

### Which coding agents does it work with?

The skill uses the Agent Skills format, which Claude Code, Codex, Cursor and Antigravity read. The MCP server works with any MCP client, including the ChatGPT desktop app through Codex.

### Is it free?

Yes. The Sonore SDK, its skill and its MCP server are open source under the Apache License 2.0, which allows closed-source and commercial plugins with no revenue limit, fee or splash screen.