Skip to main content
Glama

find_sound

Read-onlyIdempotent

Search Ableton Live's library for presets and instruments by describing the sound you want. Get ranked candidates with paths and categories to load directly.

Instructions

Find an instrument or preset in Live's library by what you want it to sound like.

Returns:
    Dictionary with the root that was searched and why, the words that were searched
    for, the ranked candidates each carrying ``item_path``, ``uri`` and ``category``,
    how far the walks got, and the next call.

Note:
    Nothing here has been listened to: the ranking reads the preset's name and the
    browser category in its uri, so load one and listen before believing it fits.
    ``status`` is coverage, not fit: an empty ``candidates`` under ``complete`` does
    mean no name there answers, while ``incomplete`` makes the list a lower bound.
    Measured 2026-09-17 against Live 12.4.6, ``sounds`` completes, ``drums`` completes
    at the depth this tool sends, and ``instruments`` cannot be searched to the end for
    presets, so a negative from that root is never evidence of absence.

    Each word costs one browser walk and blocks Live's main thread, so three are
    searched and the rest named in ``words_not_searched``. ``considered`` is the sum
    of items those walks examined, not the size of the root and not the size of the
    library, so it exceeds either when two words search the same place. Both word
    lists describe the walk, not the library: the ranking scores every intent word,
    and shortened forms, against the names returned, so an unsearched word still
    appears in ``matched``.
    Measured 2026-09-17 against Live 12.4.6, "rhodes" and "moog" match no preset name in
    ``sounds``, and "kick" none in ``drums`` though a folder "Kick" matches under
    ``kind="any"``.

    ``category`` is derived from the uri's fragment rather than read from Live and is
    null where the uri carries none; ``also_in`` names the other categories it was
    filed under. To load one, call ``load_device`` with the candidate's ``load_with``
    block, the target ``track`` and ``confirm=True``, preferring ``item_path``: a
    ``uri`` is walked for again and can run out of budget. Loading an instrument
    silently replaces the one on that track, so read the chain with get_devices first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoWhat to keep. 'preset' is the default and is what a sound is. 'device' with root='instruments' answers which instruments exist at all, rather than which preset to load.preset
rootNoBrowser root to search. Empty picks one from your words: a drum word searches 'drums', everything else searches 'sounds'. The reply says which was chosen and why.
limitNoHow many candidates to return.
intentYesThe sound you want, in your own words and in any order: 'warm bass', 'dark cinematic strings', 'punchy kick'. The phrase is split into words and each one is searched for separately, which is what the browser's own search does not do.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral detail beyond that: it notes nothing is listened to, ranking is based on names and categories, status is coverage not fit, performance costs (each word blocks main thread), and interpretation of 'considered' and word lists. This is far beyond the annotations and helps the agent understand edge cases and limitations.

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

Conciseness2/5

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

The description is excessively long, over 300 words, with detailed performance measurements and specific examples (e.g., 'rhodes' and 'moog'). While structured with paragraphs, it is not concise and would burden an agent parsing it. Key information is buried among many details, and the length is disproportionate to the tool's complexity.

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?

Despite the verbosity, the description is fully complete for an agent to use the tool correctly. It explains the return dictionary structure, the meaning of status and considered, how to load results via load_device, and even warns about silent replacement of instruments. Given the output schema exists, the description effectively covers all necessary behavioral and interpretive context.

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

Parameters4/5

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

Schema coverage is 100%, so all parameters are already documented. The description adds valuable context: it explains that intent is split into words and searched separately, and that root selection defaults based on word type. It also clarifies that the ranking scores all intent words even if unsearched. This goes beyond the schema, justifying a score above the baseline 3.

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 states the tool's purpose: finding instruments or presets by sound description, with a specific verb and resource. It distinguishes itself from generic search by explaining it splits the intent into words and searches each, which differentiates it from siblings like match_sound without naming them explicitly.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as match_sound or find_path. It explains how to interpret results and mentions load_device for loading, but does not state when not to use this tool or what distinguishes it from similar search tools. The usage context is implied by the purpose but not explicit about exclusions.

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