Skip to main content
Glama

find_path

Read-onlyIdempotent

Find the exact mechanism and catalog paths that serve your intent, returning the route to use when you need to act in Ableton Live.

Instructions

Find the mechanism that serves an intent, and the catalog rows when rows serve it.

Returns:
    Dictionary with the chosen route, any matching rows with their paths and docs,
    and the next call to make when rows are not the answer.

Note:
    There are four routes, and which one comes back matters more than the rows do.
    ``catalog_row`` means the rows carry the answer: each hit gives the path template to
    fill in, the access verbs, the full doc, and ``scopes``, the other places the same
    property exists, since track, return, master and chain mirror one another and a clip
    row usually has an arrangement_clip twin. ``writes`` appears when the best row is a
    read-only parameter object and names the sibling that actually takes a value.

    ``device_parameter`` means the answer is a knob inside a device, which this catalog
    cannot enumerate because what a device exposes depends on the device: filter cutoff,
    resonance, attack, threshold and everything else behind a front panel arrive this
    way, with the procedure to reach them.

    ``blocked`` means Live's API cannot do it at all, with what to do in Live instead.
    ``intent_tool`` is reported in the ``tool`` field alongside the rows rather than in
    place of them, because a tool that verifies its own work is the better route to the
    same end but the path is still worth seeing. ``unresolved`` means nothing matched,
    and ``unmatched`` lists the words that found nothing, which is usually where the
    query went wrong.

    A lookup costs about 1.5k tokens instead of the whole catalog. It does not touch
    Live: it reads the catalog only, so nothing here proves anything about the set that
    is open.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoRestrict to one catalog area, e.g. 'clip' or 'track'. The areas are listed in the live://catalog resource. Empty searches all of them.
limitNoHow many rows to return. Six is about 1.5k tokens.
queryYesWhat you want to do, in your own words. 'turn the bass down', 'sidechain the pad', 'where is the loop brace'. Producer vocabulary is expected: the lookup translates it into the catalog's own words.
accessNoRestrict to rows granting this verb: get, set, call, observe or automate. Use 'set' when you intend to write, which filters out the read-only parameter objects.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.4
    • changedInput schema / properties / area / description
      Previous value: -"Restrict to one catalog area, e.g. 'clip' or 'track'. The areas are listed in the ableton://catalog resource. Empty searches all of them."New value: +"Restrict to one catalog area, e.g. 'clip' or 'track'. The areas are listed in the live://catalog resource. Empty searches all of them."
  2. Addedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable context beyond those: the lookup costs about 1.5k tokens, 'does not touch Live,' and 'nothing here proves anything about the set that is open.' These are behavioral disclosures—cost and side-effect boundary—that the annotations do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and uses structured Returns/Note sections, but it runs long (~250 words). The device_parameter paragraph's enumeration ('filter cutoff, resonance, attack, threshold and everything else behind a front panel') is illustrative but padded, and the route details could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with complex multi-route semantics, the description covers the four routes, the writes field, the intent_tool nuance, the unmatched diagnostics, cost, and the no-Live-access caveat. An output schema exists, so structural return details are covered elsewhere; the description supplies the semantic layer an agent needs. Minor gaps remain around explicit alternative selection, but overall it is complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds some indirect meaning—e.g., the 'writes' route and 'read-only parameter object' discussion illuminate the access parameter's 'set' filtering behavior—but it does not add per-parameter semantics beyond what the schema already states for area, limit, query, and access.

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 opening line states a specific verb and resource: find the mechanism serving an intent plus the catalog rows when rows serve it. It is clearly distinguishable from siblings like describe (describes an object), find_sound (sound matching), and set_parameter (direct write), because this is a lookup/routing tool, and the four-route note further sharpens the identity.

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

Usage Guidelines3/5

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

Usage guidance is mostly implied: the description frames the tool as a ~1.5k-token alternative to reading the whole catalog, and the route explanations guide the next call ('the next call to make when rows are not the answer'). However, it never explicitly names sibling alternatives or states when-not-to-use conditions, so an agent must infer when this beats describe or lom_describe.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.