Skip to main content
Glama

eurorack

by com.eurorackref

Visualize module

visualize_module
Read-onlyIdempotent

Module visualization tool. Use when the user wants to understand how a module's modes work, how parameters change between modes, or what a specific mode does — a visualization communicates the per-mode behavior better than prose. The host renders the result inline in the chat as an interactive visualization (mode buttons, per-mode descriptions, schematic curves); you do not need to build an artifact yourself — just call this tool.

Do not use for general module specs (HP, jacks, capabilities) — call get_module instead.

After calling, your prose can reference what the user is seeing in the visualization (e.g. "in formant mode, all three outputs become bandpass filters") rather than describing the visualization itself.

Currently supported viz families:

  • filter_response — filters with characterized response curves (e.g. Three Sisters, Ripples, Belgrad, A-124, Filter 8, QPAS, SVF 1U, Cinnamon, C4RBN, Ikarie)

  • oscillator_morph — multi-mode oscillators and excited resonators (e.g. Rings, Loquelic Iteritas, Plaits)

A module is supported when every one of its modes has a behavior_model_id the renderer knows. If you're unsure whether a given module qualifies, just call this tool — the error names the gap.

Errors:

  • "Module not found: " if no module with that id exists.

  • "Module not yet supported by visualize_module: " when one or more modes lack a renderer-known behavior_model_id, or when the module mixes incompatible viz families. Suggest get_module for the underlying spec.

The returned spec is a JSON object with: module_id, module_name, manufacturer, viz_type, params[], modes[], response_model_id, presets[]. Each mode has a behavior_model_id that the renderer uses to pick the curve set (e.g. crossover_lp_bp_hp vs formant_three_bp for filter_response).

response_model_id (top-level) vs per-mode behavior_model_id: for multi-mode modules the top-level field is intentionally null — each mode carries its own behavior_model_id since the modes use different curve sets (e.g. Three Sisters' crossover vs formant). Read the per-mode values from modes[].behavior_model_id. The top-level is populated only for single-curve modules where one model applies across the whole module. null at top-level + populated per-mode = "modes carry distinct models," not a bug.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
module_idYesStable module id, "<manufacturer-id>/<module-slug>" (e.g. "whimsical-raps/three-sisters").

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly and idempotent hints, but the description adds substantial behavioral context: that the host renders inline, that no artifact needs building, error messages and their meanings, and the nuance around behavior_model_id at top-level vs per-mode. This goes well beyond annotations.

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?

The description is long but every sentence adds value—purpose, usage, examples, errors, and response spec. It is well-structured with bullet lists and paragraphs, and it is front-loaded with the primary purpose.

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 thoroughly explains the return JSON structure, both top-level and per-mode fields, and the intentional null behavior. It also covers all error cases, making the tool fully understandable.

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

Parameters3/5

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

Schema description covers 100% of the single parameter (module_id) with format and example, meeting the baseline. The description itself adds little about the parameter beyond restating that it's used in errors, so baseline 3 is appropriate.

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 clearly states it visualizes module modes, parameter changes, and specific mode behavior. It differentiates itself from the sibling tool get_module by explicitly saying not to use it for general module specs, making its purpose unambiguous.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance: when the user wants to understand modes or parameters. It also gives a when-not-to-use directive and names the alternative (get_module). The instruction to call if unsure further clarifies usage.

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

All eurorack toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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