Skip to main content
Glama

eurorack

by com.eurorackref

Rack Redundancy / What Can I Sell

rack_redundancy
Read-onlyIdempotent

Call this when the user asks what they can SELL, remove, downsize, or trim — "what can I sell?", "which modules are redundant?", "what's doing double duty?", "I have too many modules, what can go?", "what's not pulling its weight?". The inverse of reachable_techniques: where that adds, this prunes.

Given the user's COMPLETE rack, it runs a leave-one-out over the same technique matcher reachable_techniques uses — for each module, does removing it cost any currently-reachable technique? Returns three buckets plus the overlap map:

  • load_bearing: removing the module drops ≥1 reachable technique → KEEP. sole_filler_for names the techniques it props up.

  • sell_candidates: removing it drops nothing AND another rack module covers the same function → the first place to look. overlaps names the shared function and also_provided_by the other providers.

  • utility_or_uncovered: removing it drops nothing and nothing else does its job — it fills no catalogued technique role (usually a mixer / VCA / I/O / mult) OR serves an idiom the corpus is thin on. Judge by hand; this is NOT "sellable".

  • overlap_map: every function ≥2 of the rack's modules provide (the "you have three reverbs" view) — the evidence behind sell_candidates.

IMPORTANT — this is decision-support, not a verdict, and the limits bite here:

  • cardinality is NOT counted: a 2nd VCA / envelope / mult reads "redundant" though real patches use both at once. Overrule the tool on utilities.

  • only the curated catalog is seen: a module serving an under-covered genre looks redundant when it isn't.

  • two modules covering the same role are BOTH flagged — you can usually drop only one.

  • it cannot weigh sonic character, ergonomics, or sentiment. Trust it most for specialized overlap (e.g. several reverbs); present results as candidates to weigh, never "sell these". Pass the COMPLETE rack — the server is stateless and a partial rack distorts the analysis.

Args:

  • rack (string[], required): module ids, e.g. ["make-noise/maths", "intellijel/quad-vca"]. Max 64. Unknown ids are returned in unresolved (with did-you-mean), not silently dropped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rackYes

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations (readOnlyHint, idempotentHint, etc.), disclosing the exact algorithm behavior: leave-one-out over the technique matcher, three output buckets, overlap_map semantics, statelessness, and distortion risk with partial racks. It also openly states limits such as ignoring cardinality, catalog coverage, and sonic/ergonomic factors. This substantially exceeds annotation coverage and gives the agent realistic expectations.

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

Conciseness4/5

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

The description is quite long, but almost every sentence carries substantive information needed for safe use of this decision-support tool. The structure is good—trigger phrases first, then bucket definitions, then important caveats, then args—but it could be tightened slightly without losing essential caveats. It is lengthy but not padded.

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?

For a complex analysis tool with no output schema, this description is exceptionally complete. It explains what results look like (load_bearing, sell_candidates, utility_or_uncovered, overlap_map), the meaning of each bucket, the algorithm, the server's statelessness, input requirements, and failure behavior. Nothing critical is missing for an agent to select and invoke the tool correctly.

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?

Although the schema only defines 'rack' as a string array, the description fully compensates: it explains the required format with examples (e.g., ['make-noise/maths', 'intellijel/quad-vca']), the max of 64, the minimum 1, and the behavior for unknown ids (returned in unresolved with did-you-mean). This adds rich meaning beyond the bare schema and makes correct invocation much easier.

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 explicit user triggers ('what can I sell?', 'which modules are redundant?') and states the tool's function: leave-one-out pruning analysis. It clearly distinguishes this from reachable_techniques by calling it 'the inverse' and noting 'where that adds, this prunes.' This is specific verb+resource+differentiation.

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?

The description gives direct usage guidance: call it when the user asks about selling/removing/redundancy, and explicitly notes the inverse relationship with reachable_techniques. It also provides strong 'when-not' guidance—'cardinality is NOT counted', 'this is NOT sellable' for utility modules, and 'present results as candidates to weigh, never sell these'—helping the agent decide whether to use or override results.

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