Skip to main content
Glama

Find Compatible Modules

find_compatible_with
Read-onlyIdempotent

Return modules that have a typed compatibility relationship with the given module. Both edge directions are returned and tagged via the per-match direction field — so a single call answers both "what is X a R for?" and "what is a R for X?".

relationship is OPTIONAL. Omit it to get EVERY edge touching the module across all relationship kinds — the bare "what pairs with / relates to X?" question — with each match self-describing via its own relationship. Pass a relationship to restrict to that one kind. Prefer the relationship-less call when you don't already know which kind exists; reach for the typed form only when the question names a specific role ("what clocks X?").

Use this for two question shapes:

  1. Patch-time compatibility — "what could I use as a clock source for X?" (returns matches with direction='inbound'), or "what does X clock?" (direction='outbound').

  2. Catalog comparison — "what's an alternative to X?" (symmetric), "what does X replace?" (outbound) / "what replaces X?" (inbound), "is there an expander for X?" (inbound).

The vocabulary describes the edge as stored (from = role-bearer, to = target):

Patch-time:

  • clock-source-for — A clocks B

  • cv-source-for — A produces CV that B consumes

  • modulator-for — A is a modulator suitable for B (LFO, S&H, random)

  • audio-source-for — A is an audio source for B (typically a VCO into a VCF)

  • quantizer-for — A quantizes for B

  • trigger-source-for — A produces triggers that B consumes

  • envelope-target-for — A is something B's envelope output is designed to drive Catalog:

  • replaces — A is the newer successor to B (Morphagene replaces Phonogene)

  • alternative-to — symmetric: A and B occupy similar design space with different character

  • expander-for — A is an expander module for the host module B

Direction tag on each match:

  • outbound: queried module is the FROM side (role-bearer). Match is what the queried module does as R.

  • inbound: queried module is the TO side. Match is the R-for the queried module.

  • symmetric: only for alternative-to.

Args:

  • module_id (string, required): "/"

  • relationship (string, optional): one of the values above. Omit for all edges.

  • limit (number): default 50, max 200

Returns: { "module": { id, name }, "relationship": | null, // null when none was passed (all-edges query) "matches": [{ id, name, manufacturer, notes, source_id, direction, relationship }] }

If the module is unknown, returns an error. If no relationships have been recorded in either direction, returns matches=[]. The notes field describes the edge in the canonical A→B direction; combined with direction the caller can read it correctly either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
module_idYes
relationshipNo

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly annotation, the description discloses many behaviors: both edge directions are returned and tagged, unknown modules produce an error, empty matches array when no edges exist, the meaning of the notes field relative to direction, and default/max limits. It also clarifies that omitting relationship returns all edge types, each self-describing.

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 highly structured with clear sections for usage, vocabulary, direction semantics, arguments, and return shape. Every sentence carries information; there is no repetition or fluff. It is front-loaded with the core purpose and then details.

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 provides an explicit return object example, covers error and empty cases, and explains how to interpret the notes field. For a tool with ten relationship types and bidirectional semantics, the description is complete and self-contained.

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 0%, but the description fully compensates: it explains each enum value (e.g., clock-source-for, alternative-to), specifies the module_id format ("<manufacturer-slug>/<module-slug>"), describes the optional behavior of relationship, and documents limit's default and maximum. This is a textbook example of description adding meaning beyond 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 a specific verb and resource: 'Return modules that have a typed compatibility relationship with the given module.' It immediately clarifies bidirectional results and the optional relationship filter, distinguishing it from a simple one-direction lookup.

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

Usage Guidelines4/5

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

The description gives explicit guidance for when to omit vs. pass the relationship parameter, and enumerates two concrete question shapes (patch-time compatibility, catalog comparison) with examples. However, it does not name alternative sibling tools or explicitly say 'use this instead of X', so it stops short of full alternative differentiation.

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