Skip to main content
Glama

Search tracks

search_tracks
Read-onlyIdempotent

Search your Engine DJ library by text, tempo, key, rating, play history, and analysis flags to find tracks matching specific criteria.

Instructions

Search the Engine DJ library by text, tempo, key, rating, play history and analysis flags. Set include_total for a count alongside the page: it is capped at 1000, and a capped result comes back as total: 1000 with total_capped: true -- treat that as 'at least 1000', never as an exact count. flags.has_cues means a hot cue is actually set (the blob is decoded when the index is built), not merely that Engine analysed the track; flags.has_beatgrid means a beatData blob is present. playlist: {id} or {name} narrows the search to one playlist -- results still come back by relevance or id, not in playlist order; use get_playlist_tracks for that. With more than one library connected, pass library (a uuid or path from list_libraries, either the ~/... form or the absolute one) to choose which one; the default is the supported library with the most tracks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
bpmNo
keyNo
addedNo
flagsNo
limitNo
cursorNo
fieldsNo
playedNo
ratingNo
libraryNoWhich library to use: either the uuid or the path reported by list_libraries (the reported ~/... form is accepted, as is the absolute path). Omit it to use the supported library holding the most tracks. A READ may always omit it. A WRITE may omit it only when a single supported library is connected: with two or more, a write refuses with ambiguous_library listing them, since the choice decides which disk changes; ask the user which, then pass it here. A library copied onto another drive keeps its uuid, so a uuid can name two connected libraries: a write naming such a uuid refuses with ambiguous_library as well. Pass the path to write to one of them.
playlistNo
redact_pathsNo
include_totalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.17.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: the total cap semantics (total_capped: true), the meaning of flags.has_cues and flags.has_beatgrid (decoded blob vs. merely analyzed), and the playlist ordering caveat. It also discloses the ambiguous_library failure mode for writes, which is relevant even though this tool is read-only. No contradiction with annotations.

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

Conciseness4/5

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

The description is dense but every sentence earns its place: it front-loads the core purpose, then covers the count cap, flag semantics, playlist ordering, and library selection. It is longer than a typical description, but the length is justified by the number of subtle behaviors it must disclose. A slight deduction because the library paragraph is long and could be tightened, but it is not padded.

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 read-only search tool with 14 parameters, no output schema, and several non-obvious behaviors, the description covers the critical gaps: pagination via cursor is implied by the schema, the total cap is explained, flag semantics are clarified, playlist ordering is routed to a sibling, and multi-library selection is fully specified. The only thing not described is the exact shape of returned track objects, but with no output schema and a fields parameter, the agent can infer that from the schema and the tool's purpose. This is complete enough for correct invocation.

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 description coverage is only 7%, so the description must compensate, and it does for the most subtle parameters: include_total (cap and total_capped semantics), flags.has_cues and flags.has_beatgrid (blob-decoding nuance), playlist (ordering caveat and id/name forms), and library (uuid/path forms, default selection, ambiguous_library behavior). It does not walk through every filter object (bpm, key, rating, played, added), but those are fairly self-explanatory from their property names, and the description's targeted explanations cover the genuinely ambiguous ones.

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 ('Search the Engine DJ library') and enumerates the searchable dimensions (text, tempo, key, rating, play history, analysis flags), which clearly distinguishes it from siblings like get_tracks, get_playlist_tracks, and run_sql. It also names the sibling get_playlist_tracks explicitly when discussing playlist ordering, so an agent can tell this tool apart without opening schemas.

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?

The description gives explicit when-to-use guidance: use get_playlist_tracks when playlist order is needed, pass library when multiple libraries are connected, and treat include_total's capped result as 'at least 1000'. It also explains the default library selection behavior. This is strong routing and context that goes well beyond the schema.

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