Skip to main content
Glama

Search Eurorack Modules

search_modules
Read-onlyIdempotent

Search the corpus for Eurorack modules matching a combination of filters.

Filters compose with AND. Omit any filter to leave that dimension unrestricted. The result is sorted by module name; pagination metadata in the response envelope lets you page through long result sets.

Args:

  • capability (string): capability id, e.g. 'envelope-generator', 'clock-source'. Run a search with NO capability filter to get the full capability taxonomy (ids + labels + counts) in _meta.taxonomy. Retired/variant slugs resolve via the capability_aliases layer (e.g. 'low-pass-gate' → 'lowpass-gate', 'quantiser' → 'quantizer'), so either form is accepted.

  • manufacturer (string): manufacturer id, e.g. 'make-noise', 'mutable-instruments'.

  • hp_min, hp_max (number): module width in HP. hp_max=10 finds modules ≤ 10 HP.

  • signal_type_in (string): the module accepts a jack of this signal type as input. One of audio, cv, gate, trigger, clock, mixed. signal_type_in='audio' and ='cv' both also match jacks tagged 'mixed' (the schema's value for jacks the source describes as accepting both audio and CV — e.g. Joranalogue Compare 2's signal inputs); the other values match literally.

  • signal_type_out (string): the module produces a jack of this signal type as output. Same 'mixed'-superset semantics as signal_type_in.

  • text (string): free-text match against module id, name, slug, description, and the ids/labels/descriptions of capabilities the module has (case-insensitive substring). Matches hyphenated forms like "filter-8" against the slug/id even when the display name uses a space ("Filter 8"), and is whitespace-insensitive on id/slug/name so "3x MIA" finds the module named "3xMIA". Capability-label coverage means text="multiband" finds modules tagged multiband-filter without knowing the kebab-case id, and a curated alias layer extends that to common word-form variants ("multi-output" / "multi-band" / "band-split" → multiband-filter, "low-pass" → lowpass-filter, retired ids like "voltage-controlled-filter" → vcf). Truly novel wording still requires the _meta.taxonomy overview (run a no-capability search); if you expected a hit and got 0, call report_gap so the alias can be added.

  • voct_tracking_range_min (number): the module has a V/Oct input whose source-stated tracking range is at least this many octaves. Use for "filters that track 5+ octaves" / "oscillators with wide V/Oct range".

  • voct_tracking_quality (string): the module has a V/Oct input with this tracking quality, one of 'calibrated', 'temperature-compensated', 'approximate', 'uncalibrated'. 'temperature-compensated' is the strongest claim.

  • voct_temperature_compensated (boolean): the module has a V/Oct input whose source explicitly states temperature compensation. Implies calibrated but separately flagged because some manuals call out only one.

  • audio_outputs_min (number): the module has at least this many output jacks with signal_type='audio'. Use for "multi-output filters" (≥3 audio outs surfaces LP/BP/HP-tap VCFs like Three Sisters, QPAS, A-108, Polaris) or any multi-tap audio module. Combine with capability='vcf' for the canonical multi-output-filter query.

  • limit (number): default 50, max 200.

  • offset (number): pagination offset.

Returns: { "modules": [{ id, name, manufacturer, hp, capabilities: [string], description, production_status }], "total": number, // total matches (across all pages) "_meta": { "query": , // Present whenever a 'capability' filter matched >=1 module (NOT gated on // total=0 — it accompanies normal results). The category-coverage // denominator, so a "best X" recommendation can self-caveat instead of // reading as "best available": // On a no-capability search: the global capability taxonomy (id, label, // description, module_count) — discover the controlled vocabulary here // instead of a separate list_capabilities call. "taxonomy": [{ "id": "lowpass-gate", "label": "Low-pass gate", "module_count": 19 }], "coverage": { "capability": "stereo-mixer", // the capability you filtered on "category_total": 9, // modules in the corpus with this capability, IGNORING your other filters "corpus_total": 388, // all modules in the corpus "note": "...best of 9 in the corpus, not best available..." // ready-to-use recommendation caveat }, // Present when the server's token-AND fallback rescued an otherwise-empty // phrase query (e.g. "pamela workout" → "Pamela's NEW Workout" via per-word // identifier match). Not an error; just signals that results came from the // relaxed pass rather than the literal phrase. "relaxed_to_tokens": true, // On total=0 (after the token-AND fallback has already been attempted), the // server adds these diagnostic hints so you can retry productively in one // turn instead of guessing variants. Each is independently optional: "would_match_without": ["capability", "text"], // filters that, if individually dropped, would yield ≥1 result — the named filter(s) cost you the match "closest_text_hits": [{ id, name, manufacturer }], // top 3 modules matching 'text' alone (other filters dropped); inspect for a close hit you filtered out by accident "did_you_mean": [{ id, name, manufacturer }], // top 3 edit-distance neighbors of 'text' when it matched nothing literally (a single-token typo like "multgrain" → multigrain); PRESENT means retry with the suggested id, ABSENT means the term is a genuine corpus gap (call report_gap) — the discriminator would_match_without can't give you "capability_suggestions": [{ id, label }], // top 3 valid capabilities matching the 'capability' arg you passed (only set when the arg wasn't a known slug or alias) — use list_capabilities for the full taxonomy "manufacturer_suggestions": [{ id, name }], // top 3 maker slugs matching the 'manufacturer' arg (only set when it wasn't a canonical slug) — the manufacturer arg is EXACT-match, so e.g. "addac" → "addac-system", "nonlinearcircuits" → "nlc"; retry with the suggested id "feedback_hint": "..." // fallback prompt to call report_gap when no other diagnostic applies } }

Examples:

  • "What envelope generators under 8 HP exist?" → {capability: 'envelope-generator', hp_max: 8}

  • "What ALM modules are in the corpus?" → {manufacturer: 'alm-busy-circuits'}

  • "What clock sources are there?" → {signal_type_out: 'clock'}

  • "Modules with 'workout' in the name" → {text: 'workout'}

  • "Filters that track V/Oct over 5 octaves" → {capability: 'vcf', voct_tracking_range_min: 5}

  • "Temperature-compensated filter cores" → {voct_tracking_quality: 'temperature-compensated'}

  • "Multi-output filters with LP/BP/HP taps" → {capability: 'vcf', audio_outputs_min: 3}

Errors:

  • Returns an empty modules array (and total=0) if nothing matches. Not an error — inspect _meta.would_match_without / closest_text_hits / capability_suggestions / manufacturer_suggestions to decide whether to broaden the query or call report_gap.

  • Invalid filter values pass through to the WHERE clause; if no module satisfies them you get total=0.

After picking a hit, call get_module with the id for full details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNo
limitNo
hp_maxNo
hp_minNo
offsetNo
capabilityNoCapability id (kebab-case).
manufacturerNoManufacturer id.
signal_type_inNo
signal_type_outNo
audio_outputs_minNo
voct_tracking_qualityNo
voct_tracking_range_minNo
voct_temperature_compensatedNo

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Going far beyond the readOnly/idempotent hints, the description explains the exact response envelope and edge-case behavior: sorted results, pagination metadata, token-AND fallback (relaxed_to_tokens), mixed-signal-type superset semantics, alias resolution for capability slugs, and all diagnostic hints (would_match_without, closest_text_hits, did_you_mean, capability_suggestions, manufacturer_suggestions). It also warns that empty results are not an error and that invalid filter values pass through. This gives the agent a complete mental model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, it is efficiently structured into Args, Returns, Examples, and Errors sections, with the core purpose and AND-composition stated upfront. Every sentence adds operational value—parameter semantics, response envelope details, or diagnostic guidance—and the length is warranted by 13 parameters and a complex conditional response. There is no filler or repetition of schema defaults.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must fully explain return values, and it does. It documents the top-level shape (modules, total, _meta) and every conditional _meta field (taxonomy, coverage, relaxed_to_tokens, and all diagnostic hints). It also covers error behavior, sorting, pagination, and post-search actions (get_module, report_gap), making the tool fully actionable in a single turn.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 15%, so the description carries the full burden—and it delivers. It adds semantics for every parameter: hp_max=10 means '≤ 10 HP', text matching is case-insensitive/whitespace-insensitive and includes alias handling, signal_type values explain the 'mixed' superset behavior, voct_tracking_quality notes 'temperature-compensated' is the strongest claim, and audio_outputs_min is defined as counting output jacks with signal_type='audio'. The detailed examples further disambiguate parameter intent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific, scoped statement: 'Search the corpus for Eurorack modules matching a combination of filters.' It clearly identifies the resource (Eurorack module corpus), the verb (search), and the filter-based behavior. It also distinguishes itself from siblings like get_module (which retrieves full details for a selected module) by emphasizing filtering and pagination across a result set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong usage context: filters compose with AND, any filter can be omitted, results are sorted by name, and pagination is described. Concrete examples map natural language to parameter values, and it explicitly tells the agent to call report_gap when a term is a genuine corpus gap and get_module after selecting a hit. However, it does not explicitly name sibling search tools (search_manual, search_techniques) or state when NOT to use this tool in favor of them, leaving that distinction implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation4/5

Each tool targets a distinct resource/action: get_module(s) for specs, search_modules for filtered queries, resolve_modules for name mapping, find_compatible_with for per-module relations, reachable_pairings/techniques for rack-level analysis. Minor overlap between get_module/get_modules and the relationship tools (find_compatible_with vs reachable_pairings) could cause misselection, but descriptions clarify scope.

Naming Consistency3/5

Mostly verb_noun snake_case (get_, search_, find_, resolve_, visualize_, report_, lookup_), but three tools break the pattern: rack_redundancy, reachable_pairings, reachable_techniques use noun/adjective phrases without a verb. The get_* cluster is consistent but the overall set mixes conventions.

Tool Count4/5

17 tools is slightly above the ideal 3-15 range but justified by the server's broad scope: module specs, search, manuals, relationships, rack analysis, visualization, and feedback. Each tool has a clear role; the count is reasonable for the domain's complexity.

Completeness5/5

The surface covers the full read-only Eurorack knowledge workflow: module lookup (get_module, search_modules, resolve_modules), manual prose (get_manual_chunk, search_manual), concepts (lookup_concept), techniques (search_techniques, find_role_realizations), compatibility (find_compatible_with, reachable_pairings), rack analysis (reachable_techniques, rack_redundancy), visualization, and provenance (get_source). report_gap even enables self-improvement. No obvious missing operations.

Resources