Skip to main content
Glama

eurorack

by com.eurorackref

Resolve Module Names to IDs

resolve_modules
Read-onlyIdempotent

Bulk fuzzy name → id resolver. Pass a list of module NAMES (the way a user writes their rack — "Maths", "Plaits", "Pamela's New Workout", "Morph 4") and get back, per name, the best-matching corpus module id plus recovery affordances. This is the "import my rack" tool: resolving a 60-module inventory is ONE call here, not 60 search_modules calls.

Use this the moment a user gives you a list of module names to map onto the corpus — before get_modules / draw_patch_diagram / reachable_techniques / rack_redundancy, all of which want ids. Feed the resolved best_match.id into those.

For each input name it runs the same resolution search_modules uses (exact id, unique-slug recovery, module_aliases, separator-fold, token-AND, and edit-distance + multi-token fuzzy "did you mean"), then returns:

  • best_match: the single resolved module ({ id, name, manufacturer, hp, capabilities, production_status }), or null when nothing resolved confidently.

  • score: confidence 0..1 (1.0 exact id, ~0.97 unique slug / alias, ~0.9 literal name hit, ~0.72 token-AND relaxed, 0 when best_match is null).

  • match_kind: "id" | "slug" | "exact" | "relaxed" | "ambiguous" | "fuzzy" | "none".

  • did_you_mean: up to 5 fuzzy neighbours to confirm — populated when best_match is null (a near-miss like "morf 4" → joranalogue/morph-4, or "tiny time machin" → oam/tiny-time-machine).

  • ambiguous: up to 5 candidates when several modules tied for the match and the server declined to pick (e.g. a slug shared across manufacturers). Present them to the user; do NOT silently take the first.

The server AUTO-RESOLVES a confident single match but never guesses through a genuine tie — that's the ambiguous bucket. A name with best_match=null AND empty did_you_mean/ambiguous is a real corpus gap: consider report_gap(kind="missing_module").

Args:

  • names (string[], required): module names or ids, up to 100. Order and duplicates are preserved in the response.

Returns: { "resolutions": [ { "input": "Pamela's New Workout", "best_match": { "id": "alm-busy-circuits/pamelas-new-workout", "name": "Pamela's NEW Workout", "manufacturer": "ALM Busy Circuits", "hp": 8, "capabilities": [...], "production_status": "current" }, "score": 0.9, "match_kind": "exact", "did_you_mean": [], "ambiguous": [] }, ... ], "_meta": { "requested": 3, "resolved": 2, "feedback_hint"?: "..." } }

Errors:

  • Throws only on a malformed call (missing/empty names array, or > 100 names). Unresolved individual names are NOT errors — they come back with best_match=null and the recovery fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namesYesModule names (or ids) to resolve, up to 100. Order and duplicates preserved.

TDQS

A5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: auto-resolves confident single matches, never guesses through ties, preserves order/duplicates, returns best_match=null for unresolved names without throwing, and discloses score semantics (1.0 exact, ~0.97 slug/alias, etc.). 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?

Well-structured with a clear intro, explicit use case, args, returns with example, and error handling. Every sentence adds value; the length is justified given the complexity (fuzzy matching, ambiguity, scoring). Front-loaded with the core 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?

Despite no output schema, the description documents the full return shape (resolutions array with input, best_match, score, match_kind, did_you_mean, ambiguous, _meta), score ranges, match_kind enum values, and error behavior. It covers edge cases like ambiguous ties and corpus gaps.

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?

Input schema covers the single 'names' parameter (array of strings, 1-100 items). The description adds critical semantics: examples of user-style names, accepts IDs too, preserves order/duplicates, and clarifies what unresolved names look like. This fully compensates for and enriches the schema.

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 'Bulk fuzzy name → id resolver' and clearly states it maps a list of module names to IDs with recovery affordances. It distinguishes itself from siblings like search_modules and get_modules by emphasizing batch processing ('60-module inventory is ONE call').

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?

Explicitly states 'Use this the moment a user gives you a list of module names' and names specific follow-up tools (get_modules, draw_patch_diagram, reachable_techniques, rack_redundancy) that require IDs. It also instructs when not to use it: if best_match is null and did_you_mean/ambiguous are empty, consider report_gap instead.

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