---
name: eurorack-reference
description: Query the Eurorack Reference MCP for citation-anchored data about Eurorack synthesizer modules — specs, jacks, parameters, capabilities, firmware history, and source references. Render single-module mode visualizations and multi-module patch diagrams inline on claude.ai surfaces. Use when the user asks about a specific module, wants to compare modules, is planning a rack, is following or describing a multi-module patch, or needs verifiable information about modular synthesizer hardware. Every fact returned is sourced; surface citations when they affect the user's decision.
---

# Querying the Eurorack Reference MCP

This skill helps you query the [Eurorack Reference](https://eurorackmcp.com/) service effectively.

## When to use this

- The user names a specific Eurorack module ("look up the Maths", "what's the HP on Plaits")
- The user asks a typed question about modular synth hardware ("which modules under 10HP do quantization", "what envelope generators are out there")
- The user is planning a rack and needs spec data
- The user wants to verify a claim about a module against the manufacturer manual
- The user is following or describing a multi-module patch with at least 3 named corpus modules and explicit wire connections — render the patch graph (see §4 below; this is the one query you should consider calling **proactively**)

## When NOT to use this

- **Pricing or availability** — not in the corpus
- **Subjective patching advice** ("is Maths good for percussion?") — the corpus contains manufacturer-stated facts only, not opinions
- **Non-Eurorack synth hardware** — the corpus is Eurorack-specific. When the user wants to *bridge* off-platform gear into Eurorack, that's still a corpus question — see §12 for the polite-decline-plus-bridge shape.
- **Modules not in the corpus** — corpus is currently ~19 modules; if the lookup misses, fall back to the manufacturer's website rather than confabulating, and call `report_gap` with kind="missing_module" so the corpus can grow (see §9)
- **Patch suggestions** ("what should I patch this to?") — `draw_patch_diagram` draws patches that already exist, not patches the user might want

## How to query

### 1. Identify the module first

If the user says "Maths" or "Plaits" you don't always know which manufacturer.
Call `search_modules` with a `text` filter to confirm:

```
search_modules({"text": "maths"})
```

This returns thin records. Pick the right hit by manufacturer + name, then
call `get_module` for full detail.

### 2. Use `get_module` for detail, not multiple narrower calls

`get_module` returns the full spec in one round-trip — manufacturer, HP,
power, all jacks (inputs and outputs), all parameters, capabilities, firmware
history, reference URLs, and an `audit_url`. Don't call `list_capabilities` +
`list_references` separately if you have the module id; `get_module` already
covers them.

### 3. For "how does this mode work" questions, use `visualize_module`

When the user asks how a module's *modes* work, how parameters change between
modes, or what a specific mode does — particularly when a visual explanation
beats prose — call `visualize_module` instead of `get_module`. On claude.ai
surfaces (web, Desktop chat, mobile) the host renders the result inline as an
interactive visualization with mode buttons; on text-only surfaces (Claude
Code, other agents) it returns the underlying JSON for prose use.

After the call, the host signals when it has rendered the widget. Don't
re-describe the visualization in prose when that signal lands — the user can
already see it. Reference what they're seeing instead ("in formant mode,
CENTRE stays anchored to FREQ while LOW and HIGH spread away").

Scoped to modules with `viz_type` mappings — currently filter-family
modules (`filter_response`: Three Sisters, Ripples, Belgrad, A-124, Filter 8,
QPAS) and excited-resonator / macro-oscillator voices (`oscillator_morph`:
Rings, Loquelic Iteritas, Plaits). For modules without a mapping the tool
returns an explicit "not yet supported" error; fall back to `get_module`.

### 4. For multi-module patches, use `draw_patch_diagram` — and lean toward offering it

`draw_patch_diagram` draws a patch diagram: modules laid out by wire
topology (matrix-shaped patches anchor on a hub; otherwise modules step
left-to-right in signal-flow order), jacks as colored ports, wires
bezier-connecting them. Inline SVG on claude.ai surfaces; JSON elsewhere.

**Lean toward offering it.** When the user has been describing a patch over
several turns ("clock Plaits with PNW, take the output through Rings, send
Rings into Clouds in stereo"), don't wait to be asked — default to offering
the diagram: *"Want me to render this patch?"* If they accept, call
`draw_patch_diagram`; otherwise stay in prose. The cost of offering is one
sentence the user can wave off; the cost of not offering is invisible
(prose-when-diagram-would-help). Every other tool in this skill is reactive
(the user asks, you answer); `draw_patch_diagram` is the exception — when
in doubt, offer.

**Strict gate — call only when ALL hold:**

1. At least 3 named corpus modules (a 2-module diagram is ceremony, not value)
2. Explicit wire connections between them
3. A diagram would unload cognition prose can't match — tutorial-following,
   their-own-rack description, or "remind me what's connected to what"

Do NOT call for: a single module, a question about one module's jacks,
"what should I patch X to?" (that's a recommendation, not a graph), or
hypothetical patches with unnamed placeholders ("connect a VCO to a filter").

**Prerequisite — call `get_module` first to discover jack names.** Corpus
jack names are descriptive, not panel-text shorthand: Plaits' V/OCT input is
`"V/Oct CV input"`, its trigger is `"TRIG input"`, Rings' strum input is
`"Strumming trigger input"`. Guessing produces "Unknown jack" errors. For
each module in the patch, call `get_module` first unless you've already seen
its jacks earlier in the conversation.

**Spec shape — agent emits, server resolves:**

```
draw_patch_diagram({
  "modules": [
    {"ref": "pnw",    "id": "alm-busy-circuits/pamelas-new-workout", "role": "clock"},
    {"ref": "plaits", "id": "mutable-instruments/plaits",            "role": "voice"},
    {"ref": "rings",  "id": "mutable-instruments/rings",             "role": "processor"}
  ],
  "wires": [
    {"from": "pnw.OUT1",    "to": "plaits.TRIG input"},
    {"from": "pnw.OUT2",    "to": "plaits.V/Oct CV input"},
    {"from": "plaits.OUT",  "to": "rings.Audio input"}
  ],
  "notes": ["PNW OUT1 firing 1/16 gates; OUT2 quantized V/OCT"]
})
```

`ref` is a short alias *you* assign for use in wire endpoints. `id` is the
corpus module id. `role` is what the module does in *this* patch — pick
`clock`, `modulator`, `voice`, or `processor` based on the module's role
here, not its general identity (Maths is a modulator slow-cycling, a voice
audio-rate). Mixers, attenuators, mults, switches collapse into `processor`.
The renderer lays out by wire topology, not by role bucket, so role is
currently informational metadata — still required, declare it accurately.

`notes[]` carry patch-level prose displayed below the diagram (knob settings,
signal-flow narration, context the diagram alone wouldn't convey).

**After the call**, reference what the user is seeing rather than describing
the diagram itself. ("That's the routing — PNW's OUT1 fires Plaits, OUT2
quantizes V/OCT, audio leaves into Rings.")

### 5. For capability searches, start with `list_capabilities`

To answer "what envelope generators exist" or "which modules have built-in
quantization", first call `list_capabilities` (no args) to see the full
taxonomy with `module_count` per capability. Then call `search_modules` with
the capability id you want.

```
list_capabilities()  # see taxonomy
search_modules({"capability": "envelope-generator", "hp_max": 12})
```

### 6. For prose-shaped questions, use `search_manual`

`get_module` covers typed fields — parameters, jacks, modes, capabilities,
firmware history, and curated lore (character traits via `character[]`,
known-issue first-aid via `common_problems[]`). It does **not** carry the
manual's procedural and diagnostic prose: calibration sequences, LED
meanings, button combos, factory-reset procedures, panel walkthroughs. When
the user asks something that lives in continuous text rather than a typed
field, call `search_manual`.

For "anything I should watch out for with X?" / "is this a known issue?"
shapes, read `get_module.common_problems[]` first — that's where curated
first-aid lore lives (firmware-flash recovery, calibration drift, hum,
screen offset, bus-normalling caveats). An empty array means "no curated
entries on file," not "no known problems"; fall back to `search_manual`
for module-specific prose, or punt if neither covers it.

```
search_manual({"query": "calibration PITCH", "module_id": "intellijel/scales"})
search_manual({"query": "factory reset", "module_id": "make-noise/maths"})
search_manual({"query": "tap tempo", "module_id": "4ms/tapographic-delay"})
```

Always pass `module_id` when the user has named a module — it narrows the
search to the relevant document and keeps results focused. The response
gives you BM25-ranked excerpts with `heading_path` and `snippet`; treat the
`text` field as a direct quote from the manual, not as a typed fact. When
citing, frame as "the manual says ..." with the `audit_url` for verification.

The corpus is keyword-indexed (not semantic), so vocabulary matters: if a
first query returns nothing, try terms the manual would use rather than the
user's terms (Scales calls V/Oct "PITCH"; some modules call presets
"scenes" or "snapshots"). The tool will not hallucinate — empty results
means the corpus genuinely doesn't have that text.

Do not use `search_manual` for content already in `get_module` — typed
fields there are authoritative. `search_manual` is for what doesn't fit
tables.

### 7. For source verification, use `get_source` or `list_references`

Every fact returned by `get_module` includes `source_id` references. If the
user asks "where did you get that?" or "is the PDF still current?", call
`get_source` with the `source_id`. The response includes `canonical_url` (the
manufacturer's URL), `archived_url` (a worker route streaming the archived
PDF/HTML from R2), `last_verified`, and `canonical_changed_at`.

If `canonical_changed_at > last_verified`, the manufacturer's document
changed since the service last checked. **Surface that caveat to the user.**

### 8. Cite sources when they affect the answer

If you tell a user a CV input accepts -5V to +5V, link to the source via the
`audit_url` so they can verify. Don't suppress the citation in the name of
conversational tone — the whole point of this service is that every claim is
backed.

### 9. When the corpus or a tool falls short, call `report_gap`

This MCP is **not** strictly read-only. `report_gap` is a write channel for
flagging what didn't work. Call it proactively — without being asked —
whenever you hit:

- `missing_module` — user named a module not in the corpus
- `missing_field` — you expected a typed field and it wasn't on the module
- `empty_result` — a reasonable query came back empty
- `tool_confusion` — a tool's behavior surprised you
- `other` — anything else worth flagging

```
report_gap({"kind": "missing_module", "module_id": "rossum/mob-of-emus",
            "expected": "user asked about Mob of Emus specs",
            "observed": "not in corpus"})
```

If a user asks "did you report that?" or "can the maintainer see this?" —
the answer is yes, via this tool. Do **not** route users to external contact
paths when the gap fits one of the kinds above; report it yourself.

`get_module` (on stub modules) and `search_modules` (on empty results) emit
a `_meta.feedback_hint` field as a breadcrumb. When you see it, that's the
explicit cue to call `report_gap`.

### 10. For vocabulary / concept questions, use `lookup_concept`

`lookup_concept` is the place primitive-vocabulary questions land — the ones
that aren't about a specific module but about a synthesis or Eurorack term
itself:

- "Is four-quadrant mult the same as through-zero AM?"
- "What's the difference between a gate and a trigger?"
- "Modular signal level vs line level — when does it matter?"
- "Are clock dividers really just pulse counters?"
- "Are polyphonic patch cables TRRRRRS?"

Pass the user's term as `name`; lookup is case-insensitive across the
canonical id, the canonical label, and a registered alias list ("AM", "ring
mod", "TZFM", "4Q mult"). The response carries the definition, the alias
list, and **related concepts** with a `relation_kind`:

- `subtype_of` — X is a specific case of Y (RM ⊂ AM, TZFM ⊂ linear FM)
- `inverse_of` — X is the opposite of Y (clock-divider ↔ clock-multiplier)
- `commonly_confused_with` — distinct but often conflated (gate vs trigger,
  AM vs RM, modular level vs line level)
- `related_to` — see-also default

When the user's question is "is X the same as Y?", check
`related_concepts[]` for a row where `related_concept_id` matches Y — the
`note` field carries the disambiguation prose ("RM is AM where both inputs
are bipolar and DC is rejected"). Surface that note rather than re-deriving
the relationship from training knowledge.

```
lookup_concept({"name": "four-quadrant mult"})
lookup_concept({"name": "TZFM"})
lookup_concept({"name": "gate"})
```

`search_manual` will set `_meta.concept_hint` on an empty result whose
query matches a concept alias — that's the explicit cue to call
`lookup_concept` instead.

When the lookup misses, the response includes up to 5 substring-matched
suggestions. Present the closest one or two to the user; if none look
right, the corpus genuinely doesn't carry that concept — call `report_gap`
with kind="missing_field" and tool_name="lookup_concept".

Do NOT use `lookup_concept` for module questions ("which modules do FM?") —
that's `search_modules` / `list_capabilities`. Concepts are the
*vocabulary*; modules are what *implements* them.

### 11. Verify field-value meanings by inspecting an example

When the user asks what a corpus *field value* means — not which modules
have it — don't define it from training knowledge alone. The corpus carries
real metadata that grounds these terms.

The typical shape: user asks "what does `voct_tracking_quality=calibrated`
mean?", or "what counts as a `lowpass-gate` capability here?", or "what
does the `modal_string_synth` behavior model do?". `search_modules` will
list modules that carry the value, but that's *enumeration*, not
*definition*. To define the term, follow the search with `get_module` on
at least one example and read the field's surrounding metadata:

- For V/Oct tracking quality → `jacks[].tracking` on a V/Oct input
- For capability ids → `capabilities[].notes` on a module with that tag
- For behavior models → `modes[].description` + `parameters[].per_mode_notes`

Defining a term solely from search_modules results (or training knowledge)
is a grounding failure even when the resulting prose sounds plausible.
Inspect one record.

### 12. Cross-platform questions — structured punt, not bare decline

When the user's question is about non-Eurorack hardware (Prophet 08, Korg
SQ-64, Pro Tools, Behringer Model 15, Kurzweil DSP, etc.), the bare "this
is Eurorack-only" decline leaves signal on the floor. Most of these
questions are about *bridging* the off-platform gear into Eurorack — that's
a corpus-shaped problem the MCP can answer.

Use this three-step shape:

1. **Acknowledge** the off-platform context in one sentence so the user
   knows you heard the question. ("The Prophet 08 itself is a desktop synth
   outside this corpus.")
2. **Reframe as a bridge query** if the question is about integration. The
   most common shapes:
   - "How do I get my [non-Eurorack synth] into Eurorack?" → call
     `search_modules` with `capability=midi-source` (and/or `cv-output`) to
     find MIDI-to-CV interfaces. Yarns, EaganMatrix, and similar modules
     bridge MIDI hardware into the modular world; let the corpus name them.
   - "How do I record / sync my Eurorack patch with [DAW]?" → audio-out
     modules + clock-source modules from the corpus. `signal_type_out=audio`
     and `signal_type_out=clock` cover the routing.
3. **Punt cleanly** if no bridge applies (pure off-platform troubleshooting:
   *"my SQ-64's gate LED is stuck"*). State scope honestly and name a
   stronger reference community for that gear — r/synthesizers and the
   manufacturer's forum are the right pointers. Don't confabulate fix
   procedures for hardware that isn't in this corpus.

Don't paste hardcoded module names from this section — they drift as the
corpus changes. Let `search_modules` surface the current bridge candidates
at query time. The capability filter is the durable contract; the matching
modules are an implementation detail.

## Distinguishing manufacturer claims from inferred behavior

The service ships facts from manuals. If a user asks something the manual
doesn't address (e.g. "is this module good for percussion?", "how does it
feel to play?"), say so explicitly:

> "The manual covers Maths' specs but doesn't make subjective claims about
> use cases. From the spec — function generator with adjustable rise/fall
> and Vari-Response curves — you could absolutely use it for percussion
> envelopes, but that's an inference, not a manufacturer claim."

Never confabulate from spec data. The audit site exists so users can
verify; the MCP returns `audit_url` for the same reason.

## Example queries that work well

| User asks | Tool | Args |
|---|---|---|
| "Look up Pamela's New Workout" | `get_module` | `{"id": "alm-busy-circuits/pamelas-new-workout"}` |
| "What modules quantize to musical scales" | `search_modules` | `{"capability": "quantizer"}` |
| "Show me ALM modules" | `search_modules` | `{"manufacturer": "alm-busy-circuits"}` |
| "What sequencers are under 16HP" | `search_modules` | `{"capability": "cv-sequencer", "hp_max": 16}` |
| "How does Three Sisters' formant mode work" | `visualize_module` | `{"id": "whimsical-raps/three-sisters"}` |
| User describes a 3+ module patch | `draw_patch_diagram` | (after calling `get_module` per module to learn jacks) |
| "What's source #3?" | `get_source` | `{"source_id": 3}` |
| "What's the firmware history on Maths?" | `get_module` | `{"id": "make-noise/maths"}` (firmware_versions in response) |
| "Is four-quadrant mult the same as TZFM?" | `lookup_concept` | `{"name": "four-quadrant mult"}` |
| "What's the difference between a gate and a trigger?" | `lookup_concept` | `{"name": "gate"}` |

## Module ID convention

Module ids are slug-shaped: `<manufacturer-slug>/<module-slug>`.

Examples in the corpus:
- `alm-busy-circuits/pamelas-new-workout`
- `make-noise/maths`
- `mutable-instruments/plaits`
- `intellijel/sealegs`
- `whimsical-raps/three-sisters`
- `4ms/spherical-wavetable-navigator`

If you don't know the slug, don't guess — `search_modules({"text": "..."})`
first.

## Carrying context across sessions

If the user mentions specific modules in their case ("I have a Plaits, a Three Sisters, an 814, and four FX returns"), it might be a good idea to save that to memory so future sessions don't have to re-ask. Same for things the corpus can't answer for you — what's downstream of the final mix, how they label their cases, recurring patch nicknames.

Use judgment. A one-off question about a single module probably isn't worth a memory entry. But if the user is describing their rack, planning a buy, or working through a setup you'll likely revisit, a one-line memory ("rack: Plaits, Three Sisters, ADDAC814, four mono FX returns into 814") saves a turn next time and avoids reasoning forward through partial information.

Cache the user's environment, not corpus data. Module specs (jacks, parameters, capabilities) live in the corpus and are one tool call away — caching them in memory duplicates ground truth and goes stale when the corpus updates. The user's rack and downstream chain are what the corpus *can't* tell you.

## Source provenance — the `canonical_changed_at` warning

Every `get_module` response carries source references. Each source row has
`last_verified` and `canonical_changed_at`. The pair is the staleness
signal:

- `canonical_changed_at > last_verified` → manufacturer's document changed
  since the service last verified it. Treat the data as stale-pending-review.
- `canonical_changed_at` ≤ `last_verified` (or null) → the data was
  current as of the last check.

Surface this when the user is making a decision the answer affects.