Skip to main content
Glama

Look Up Concept

lookup_concept
Read-onlyIdempotent

Return a canonical definition for a primitive Eurorack / synthesis concept and its relations to other concepts in the corpus.

Use this for VOCABULARY questions, not module questions — when the user is asking what a term means or how two terms relate, not which modules implement it. Typical shapes:

  • "Is four-quadrant mult the same as through-zero AM?" → lookup_concept("four-quadrant mult")

  • "What's the difference between a gate and a trigger?" → lookup_concept("gate")

  • "Modular signal level vs line level — when does it matter?" → lookup_concept("modular signal level")

  • "Are clock dividers just pulse counters?" → lookup_concept("clock divider")

  • "Are polyphonic patch cables TRRRRRS?" → lookup_concept("polyphonic cable")

Lookup is case-insensitive across three axes, tried in order: the canonical id ("through-zero-fm"), the canonical label ("Through-Zero FM (TZFM)"), and any registered alias ("tzfm", "through zero fm"). Spaces and hyphens are matched literally; the lookup does NOT normalize whitespace beyond lowercasing. If the term doesn't match anything, the response includes up to 5 substring-matched suggestions.

Args:

  • name (string, required, min length 2): the term to look up. Examples: "AM", "ring mod", "four-quadrant mult", "TZFM", "clock divider", "gate", "trigger".

Returns: { "concept": { "id": "amplitude-modulation", "label": "Amplitude Modulation (AM)", "description": "A multiplication of two signals: the carrier...", "aliases": ["am", "amplitude modulation", "amplitude mod"], "related_concepts": [ { "related_concept_id": "ring-modulation", "related_concept_label": "Ring Modulation (RM)", "relation_kind": "commonly_confused_with", "note": "AM with a unipolar modulator preserves the carrier..." }, ... ], "source_id": null, "citation_url": "https://learningmodular.com/glossary/...", "citation_quote": "Amplitude modulation is when..." } | null, "_meta": { "query": "", "matched_via": "id" | "label" | "alias" | "none", "concept_suggestions": [ { "id": "...", "label": "...", "matched_via": "alias", "matched_text": "..." } ], "feedback_hint": "...?" } }

Relation kinds:

  • "related_to" — see-also link (default; symmetric in spirit).

  • "subtype_of" — X is a specific case of Y (RM ⊂ AM, TZFM ⊂ linear FM).

  • "inverse_of" — X is the opposite of Y (clock-divider ↔ clock-multiplier).

  • "commonly_confused_with" — they're distinct, but people conflate them (gate vs trigger, AM vs RM, modular level vs line level).

When to cite: every concept carries either source_id or citation_url + citation_quote. Surface the citation when the answer affects a decision (e.g. "the corpus cites learningmodular.com — TRS cables are physically the same connector whether carrying balanced mono or unbalanced stereo; only the destination determines the role").

When the result is null and concept_suggestions are provided, present 2–3 closest matches to the user. If none look right, the corpus genuinely doesn't carry that concept — call report_gap with kind="missing_field" and tool_name="lookup_concept" naming the term and its expected definition.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

A5/5.0
Behavior5/5

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

The description deeply discloses behavioral traits: case-insensitivity, matching order (id, label, alias), literal space/hyphen matching, no whitespace normalization, substring suggestion behavior, null handling, and relation kinds. Annotations only state readOnly and idempotent, so the description carries and enriches the behavioral disclosure.

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?

Long but tightly organized: purpose, usage, matching behavior, Args, Returns, relation kinds, citation guidance, null handling. Every section adds needed information, with front-loaded purpose and clear formatting. No filler or 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?

For a deceptively simple tool (one parameter), the description covers all necessary context: matching semantics, return shape, relation type meanings, citation expectations, and null/suggestion handling. With no output schema, this is exceptionally complete.

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% (the name parameter has only type/minLength), so the description must carry all semantic weight. It does this with an 'Args' section listing the parameter, type, required status, min length, and several concrete examples. This fully compensates for the bare 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 clearly and specifically states the tool's purpose: 'Return a canonical definition for a primitive Eurorack / synthesis concept and its relations to other concepts.' It explicitly separates vocabulary questions from module questions, and the examples show concrete use cases, distinguishing it from sibling tools like get_module or search_modules.

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?

Provides explicit usage guidance: 'Use this for VOCABULARY questions, not module questions.' It gives typical question shapes, explains when to cite, and instructs what to do when the result is null (present suggestions, then call report_gap). This is far beyond minimal guidance.

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