Return the full citation-anchored specification for one Eurorack module by id.
Use this when the user names a specific module and you want its specs (HP, power, jacks, parameters), capabilities (envelope, quantizer, logic, etc.), or firmware history.
The typed prose fields (jack/parameter/mode descriptions) are paraphrased summaries; manual_outline → get_manual_chunk give the verbatim manual prose to quote against. How much to quote and overall answer shape live in SKILL.md (the "Answer shape" section + §8 citation) — this description is the data contract.
## Provenance fields
Every typed row in the response — capabilities[], jacks[], parameters[], modes[], firmware_versions[], plus nested zones/assignments/tracking — carries a source_id pointing at the source the claim was extracted from. Cross-reference list_references(module_id=...) for the source title and canonical_url.
The typed prose fields — jacks[].description, parameters[].behavior, modes[].description, capabilities[].notes, firmware_versions[].notes — are extractor-synthesized summaries grounded in the manual, NOT verbatim quotes. Treat them as the corpus's stated claim about the field; they're authoritative for what the field *does*, but they are not direct manual text. For verbatim quotation in your answer, always pull the actual prose via get_manual_chunk(chunk_id) — the description fields are the typed claim, not the source quote.
manual_outline[] bundles a lightweight outline of the module's manual prose — one entry per chunk with heading, source, and a ~140-char preview snippet. Always scan it before answering — for prose-shaped questions to find the relevant chunk, for spec-shaped questions to find a chunk to quote alongside the typed data. When a snippet looks relevant, call get_manual_chunk(chunk_id) to pull the full text. manual_outline_total is set ONLY when the outline was truncated for a verbose module; its absence means the returned outline is complete. When set, use search_manual to reach chunks beyond the cap.
Module IDs are slug-shaped: "<manufacturer-id>/<module-slug>". For example:
- alm-busy-circuits/pamelas-new-workout
- make-noise/maths
## Optional args — trim the payload, target the outline
By default this returns the full spec. For narrow questions you can shrink it:
- view: "concise" returns just the id-card fields (name, manufacturer, hp, description, capabilities, production_status, replaced_by) and drops the heavy arrays — use it for triage ("which of these is the quantizer?") or when you only need to confirm what a module is. "full" (default) returns everything. Ignored when fields is set.
- fields: array of top-level keys to include (e.g. ["jacks","parameters"]). id and _meta are always returned. Use this for a quick jacks-only or specs-only read instead of paying for character[]/common_problems[]/role_fitness[]/the full manual_outline. Takes precedence over view.
- heading_filter: case-insensitive substring on manual_outline heading_path — e.g. "calibration" returns only outline chunks under a Calibration heading, so you skip scanning a long outline.
- outline_offset / outline_limit: page through manual_outline (default 100 per page, hard max 250). Combined with manual_outline_total this lets you reach chunks past the cap without falling back to search_manual.
Returns:
- id, name, manufacturer { id, name }
- hp, depth_mm
- power: { plus_12, minus_12, plus_5 } (mA)
- description (manufacturer's prose summary, citation-backed)
- capabilities[]: functional tags with per-module realization notes (source_id per row)
- jacks[]: inputs and outputs with voltage range, signal_type, prose description (a paraphrased summary, NOT a verbatim quote — to quote the manual, pull the source prose via get_manual_chunk), plus assignments[] for assignable jacks (destination menu — empty for fixed-function jacks). When mirrors_parameter is set, the jack mirrors that knob's current assignment (e.g. Pizza CTRL CV mirrors the CTRL knob). normalled_from { id, name } is set when this input has a hardware normal — i.e. when unpatched, it receives the signal at the named source jack (e.g. Multigrain GATE normalled from NEXT). null when no normal exists. V/Oct inputs may carry an optional tracking { tracking_range_octaves, tracking_quality, temperature_compensated } object — present only on jacks that have been audited for V/Oct metadata. Fields inside may be null when the source is silent on that aspect. Optional _field_absent: { <field_name>: { source_id, note } } records fields that were audited and found to be source-silent — read it before hedging: an entry under voltage_min means "the manual doesn't state this" (so a confident "the manual doesn't specify" answer is appropriate); the field being null *without* an entry means "not yet extracted" (hedge differently — recommend the user check the manual).
- parameters[]: knobs, switches, menu settings with range, unit, behavior (paraphrased summary, NOT a verbatim quote — same as jacks[].description; quote get_manual_chunk for source text), plus zones[] (labeled regions along the control's travel — e.g. Swells FLOW "Sine" / "Random" halves, optionally mode-scoped) and assignments[] (destination menu for assignable knobs/menu-settings) — both empty arrays for plain controls. Modal-module params may also carry per_mode_notes (rebinding text keyed by mode_id slug, present only when the param rebinds per mode — e.g. Plaits MORPH, Swells EBB/FLOW). Same _field_absent convention as jacks[] — when default_value is null and _field_absent.default_value is present, the manual doesn't state a default.
- modes[]: mode list for modal modules (Plaits, Swells, MFX) — { id, label, description, behavior_model_id, scope? }. Empty for modeless modules. Mode ids cross-reference parameters[].per_mode_notes keys and parameters[].zones[].mode_id. Optional scope is set when modes are selectable independently per member rather than module-wide — 'per-segment' (Stages hold/ramp/step), 'per-envelope' (Tangrams cycle/single), 'per-output' (PNW), 'per-channel'. Member count is carried by the corresponding enumerated parameters/jacks (e.g. Stages' six Type Button N parameters), not duplicated on the mode rows.
- hidden_functions[]: functions reached via a trigger other than a single labeled control — { id, trigger_type, affected_control, label, description }. trigger_type is a controlled vocabulary ('long-press' | 'hold' | 'combo' | 'double-press' | 'power-on-hold' | 'held-turn') so recall/menu-diving load is countable; affected_control names the panel control the trigger acts on (null for module-global functions like hold-on-power-up calibration). Empty for modules whose controls are all directly labeled. Read this for "how do I get to X?" / menu-diving questions and when assessing how much hidden state a module carries — the same info used to live buried in parameters[].behavior prose.
- panel_sections[]: manufacturer-named regions of the front panel (e.g. Multigrain "Dedicated Sound CV inputs" grouping GATE/NEXT/SELECT, "Morph section" grouping the MORPH knob + MORPH CV jack). Each entry has { label, description, members: [{ kind, id, name }] } where members cross-reference jacks[] / parameters[] by id. Empty for modules without manufacturer-named groupings.
- character[]: curated subjective-character claims (vocal/aggressive/clean/gritty/lush/...) with source citations. Read this when the user asks about *sound* or *feel* rather than specs — filter choice for "carve rhythmic transients" or "warm pad voice" hinges on character, which the typed-fields surface can't carry. Each entry: { tag, note (prose elaboration), source_id (when archived in sources), citation_url + citation_quote (when sourced from a review/forum/video we don't archive per-module) }. Empty for modules that haven't been character-audited yet — distinguish "empty array, audit pending" from "no character worth noting." Tags are open-vocab; common starter set: vocal, aggressive, clean, gritty, acidic, lush, dark, bright, smooth, woody, formant, screaming.
- common_problems[]: curated first-aid lore — repeatable failure modes that owners hit but the manual doesn't cover (calibration drift, hum, screen offset, firmware-flash brick recovery, bus-normalling caveats). Read this when the user asks "anything I should watch out for with X?" or describes a symptom matching a known module quirk. Each entry: { problem_summary (one sentence), cause (prose), fix_or_workaround (prose), confidence ('confirmed' | 'likely' | 'anecdotal'), source_id, citation_url, citation_quote }. Empty array means "no curated problems on file" — agents should NOT extrapolate to "no known problems"; the audit is opt-in per module and most modules have not been touched yet.
- role_fitness[]: role-realization rollup — canonical techniques whose role_realizations this module fills, with the affordances it brings to that role. Use this when the user wants to know "what roles can this module play?" — e.g. Optomix → lpg role in low-pass-gate-pluck, affordances_provided=[lowpass-gate]. Each entry: { technique_id, technique_label, role_id, role_label, affordances_provided, notes }. Pair with list_techniques(filter={ module_id }) for the full role_definition + sibling realizations, or find_role_realizations(technique_id, role_id) to substitute other modules into the same role.
- firmware_versions[]: version + release_date (may be partial: YYYY | YYYY-MM | YYYY-MM-DD) + notes (per-version changelog prose when the source provides one — e.g. "Added Smooth Random waveform type. Added Logic parameter (AND/OR/XOR)."). Use this to answer "what changed in v2?" without web search.
- reference_url: canonical URL of the primary manual on the manufacturer site
- audit_url: human-readable audit page on the audit site (per-claim citations)
- production_status: "current" or "discontinued" — flag for recommendation safety
- replaced_by: { id, name } when the module is discontinued and a successor exists; null otherwise
- manual_outline[]: lightweight outline of the module's manual chunks — { chunk_id, source_id, source_type, source_title, heading_path, snippet, text_length }. Ordered by (source_id, chunk_index). When the snippet looks worth reading in full, call get_manual_chunk(chunk_id). Empty when no manual prose has been ingested yet for this module.
- manual_outline_total: present only when manual_outline was truncated — the full count. Hit search_manual to reach the rest.
- _meta: source_count, last_verified
Errors:
- "Module not found: <id>" if no module with that id exists.
If the user asks something the manual does not cover (e.g. subjective "is this good for percussion?"), say so explicitly — never confabulate from spec data.