Check whether a playlist brief is possible at all, before choosing any tracks.

Call this first, before query_library, whenever the user asks for a playlist with constraints. If feasible is false the brief cannot be satisfied by this library: tell the user which constraint fails and stop. Do not build a playlist anyway, do not relax the constraint yourself, and do not try alternative track combinations.

max_achievable_display is the longest playlist the library can produce under these constraints. When explaining a refusal, describe what the user asked for in their own words and quote max_achievable_display for what is possible. Never show the user a millisecond figure and never convert one yourself.

A brief with no constraints at all cannot be checked. If the user has not said how long the playlist should be or what should be in it, ask them before calling this.

Search the user's music library and return matching tracks with their totals.

Call this before stating any fact about the library. Never estimate a count, a duration or a track name from your own knowledge, and never add numbers up yourself: use total_matching and total_duration_ms from the result, which are computed exactly. The tracks list is truncated to limit entries, so it may be shorter than total_matching.

To find a longest, shortest, highest or lowest track, pass order_by as one of longest, shortest, highest_energy, lowest_energy and read the first entry. Never rank, compare or pick a maximum out of the list yourself; the ordering is computed here.

Quote duration_display for a track and total_duration_display for a set of them. Never convert milliseconds to minutes yourself.

Energy is an estimate, not a measurement. Every track carries energy_provenance saying where its value came from, and any answer that mentions energy must say it is an estimate.

If a genre search finds nothing, known_genres lists the genre tags the library actually uses. If the user's word is another name for one of them, as rap is for hip hop, search again with that tag and say which tag you searched. Never substitute a genre that is merely related.

Check a proposed playlist against hard constraints and report every violation.

Call this before presenting any playlist to the user. Do not judge for yourself whether a playlist meets its constraints. Each violation names the offending track ids and an adjust_by amount in the constraint's own unit: negative means remove that much, positive means add that much. Act on adjust_by rather than guessing how much to change.

When describing the playlist, quote track_count and total_duration_display from this result verbatim. Never sum durations yourself and never convert milliseconds to minutes yourself.

A duration violation also carries adjust_by_display, the same amount written in minutes and seconds. Show the user that, never the millisecond figure.

Pass the same release-year bounds you gave check_feasibility, so a track outside the window is caught here too.

If the user asks for an energy level or a mood, pass target_energy between 0 and 1. It is scored, never enforced: soft_scores reports how close the playlist came, and because energy is estimated rather than measured, any answer that mentions it must say so.

Look up background on one artist in the user's library, from published sources.

Call this for any question about an artist's history, members, origins, influences or career. Pass the artist's name and the user's question. It returns the passages from MusicBrainz and Wikipedia that best match the question.

Answer only from these passages. If they do not contain the answer, tell the user your sources do not cover it, even if you believe you know. Never fill the gap from your own knowledge.

Cite every passage you use by its id in square brackets, such as [can-03], straight after the claim it supports. Never cite an id this tool did not return.

This tool knows nothing about the user's tracks. Use query_library for those.