Skip to main content
Glama

Look up modules

get_modules
Read-onlyIdempotent

Batched get_module — returns { modules: [...], errors: [...] } with full citation-anchored specs for up to 25 modules in one call.

Prefer this over multiple get_module calls when you have a known list of modules to fetch (e.g. preparing to call draw_patch_diagram across N modules, comparing several candidates side-by-side). One round trip vs. N.

Args:

  • module_ids: array of "/" strings. Up to 25 per call; duplicates are deduplicated.

Optional args (apply to every module in the batch, same semantics as get_module):

  • view: "concise" returns the id-card subset (name, manufacturer, hp, description, capabilities, production_status, replaced_by) for every module and drops the heavy arrays — the cheapest way to triage a list ("which of these are LFOs?"). "full" (default) returns complete specs. Ignored when fields is set.

  • fields: top-level keys to include on each module (e.g. ["jacks","parameters"]). id and _meta are always returned. Use this when you only need a slice across N modules (e.g. just jacks for draw_patch_diagram) instead of N full specs.

  • heading_filter / outline_offset / outline_limit: narrow and paginate each module's manual_outline.

Returns:

  • modules[]: GetModuleResponse for each id that resolved (same shape as get_module; narrowed when fields is set).

  • errors[]: { id, message } for each id that failed (e.g. unknown module). Other ids in the batch still resolve.

If you only need a single module, use get_module — same shape, one element. Need only jacks (e.g. for draw_patch_diagram)? Pass fields: ["jacks"] to skip the full specs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoOptional: "concise" returns the id-card subset for every module in the batch and drops the heavy arrays — cheapest way to triage a list. "full" (default) returns complete specs. Ignored when `fields` is set.
fieldsNoOptional: top-level keys to include on every module in the batch (e.g. ["jacks","parameters"]) when you only need a slice — keeps a multi-module fetch from returning full specs. Omit for everything. id and _meta are always returned. Takes precedence over `view`. Same selectable keys as get_module.
module_idsYes
outline_limitNoOptional: max manual_outline entries per module (default 100, hard max 250).
heading_filterNoOptional: case-insensitive substring matched against manual_outline heading_path, applied to every module in the batch.
outline_offsetNoOptional: zero-based manual_outline offset, applied to every module in the batch.

TDQS

A5/5.0
Behavior5/5

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

The description explains deduplication ('duplicates are deduplicated'), error handling ('errors[]: { id, message } for each id that failed... Other ids in the batch still resolve'), and parameter precedence ('Ignored when fields is set'). Annotations already mark read-only/idempotent, and the description enriches with batch semantics.

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?

Though substantial, every section serves a purpose: batched behavior, usage context, arg explanations, return shape, and alternative recommendations. The structure uses clear labels ('Args', 'Optional args', 'Returns') and avoids redundancy.

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?

No output schema exists, but the description specifies the exact return format and edge cases (failed ids, deduplication). It also covers all 6 parameters with behavior and examples, making it fully actionable for an agent.

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 83%, but the description adds critical behavioral details: 'same semantics as get_module,' 'id and _meta are always returned,' and 'applies to every module in the batch.' It also gives concrete examples like 'fields: ["jacks"]' for draw_patch_diagram.

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 precise statement: 'Batched get_module — returns `{ modules: [...], errors: [...] }` with full citation-anchored specs for up to 25 modules in one call.' This clearly distinguishes it from the sibling get_module tool and other lookup tools by emphasizing batch capability and known-list fetching.

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?

It explicitly instructs: 'Prefer this over multiple get_module calls when you have a known list of modules to fetch... One round trip vs. N.' It also names alternatives: 'If you only need a single module, use get_module — same shape, one element,' and provides guidance for using fields to optimize.

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