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 vi...
Part of the Eurorack server.
Free to start. No card required.
AI agents invoke visualize_module to trigger processes or run actions in Eurorack. Execute operations can have side effects beyond the immediate call -- triggering builds, sending notifications, or starting workflows. Rate limits and argument validation are essential to prevent runaway execution.
visualize_module can trigger processes with real-world consequences. An uncontrolled agent might start dozens of builds, send mass notifications, or kick off expensive compute jobs. PolicyLayer enforces rate limits and validates arguments to keep execution within safe bounds.
Execute tools trigger processes. Rate-limit and validate arguments to prevent unintended side effects.
{
"version": "1",
"default": "deny",
"tools": {
"visualize_module": {
"limits": [
{
"counter": "visualize_module_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}See the full Eurorack policy for all 17 tools.
These attack patterns abuse exactly the kind of access visualize_module gives an agent. Each links to the full case and the policy that stops it:
Other execute tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
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: <id>" if no module with that id exists. - "Module not yet supported by visualize_module: <id>" 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.. It is categorised as a Execute tool in the Eurorack MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the Eurorack MCP server in PolicyLayer and add a rule for visualize_module: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Eurorack. Nothing to install.
visualize_module is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the visualize_module rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for visualize_module. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
visualize_module is provided by the Eurorack MCP server (https://eurorackref.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 17 Eurorack tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.