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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[
      -  "module_id",
      -  "relationship"
      -]New value: +[
      +  "module_id"
      +]
  2. First observed

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.

Resources