Get the CUE SHEET for a track — album, catalogue number, ISRC, tempo, key, publisher, and every writer with their IPI, society and performance share. Hand this over when the user needs delivery paperwork, rights information, or asks who wrote it. AINSOF controls master and publishing, so these are stated facts, not estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | Yes | a track_id, or the track's title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description's additional note that AINSOF controls master and publishing and that the data is 'stated facts, not estimates' adds valuable context about data reliability and provenance. This is useful beyond the structured annotations, though it does not reveal detailed failure behavior or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences: the first states what the tool returns, and the second states when to use it and how trustworthy the data is. There is no filler, and the most important operational information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and strong annotations, the description covers the resource, the delivered fields, the usage scenarios, and the authoritative nature of the data. Even without an output schema, an agent has enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, track_id, is already well documented in the input schema, including the fact that it accepts either a track_id or the track's title. With 100% schema coverage, the description does not need to repeat parameter details, and it doesn't add materially to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get the CUE SHEET for a track') and enumerates the key fields returned, such as album, catalogue number, ISRC, and writer details. This makes the tool's purpose immediately clear and distinguishes it from sibling tools that find or analyze tracks rather than return cue-sheet data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: when the user needs delivery paperwork, rights information, or asks who wrote a track. It does not name alternative tools to avoid or provide when-not-to-use guidance, so it falls just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
search_music, find_soundtrack, and search_by_reference all discover catalogue music, and find_soundtrack overlaps with search_music for description-based requests. The long descriptions clarify the intended input type, but an agent could still reasonably pick the wrong tool when a user asks for music for a video.
Most tools follow a readable verb + object pattern (analyze_video, deliver_score, get_track, get_upload_link), but others are noun phrases (cue_sheet, listen_link, feedback) or awkwardly different (about_ainsof, score_my_video). The naming is not chaotic but lacks a single consistent convention.
With 12 tools, the set is within the well-scoped 3-15 range and each tool addresses a clear stage of the catalogue and scoring workflow: search, preview, upload, analyze, score, deliver, and feedback. No obvious filler or redundancy bloating the count.
The set covers the core lifecycle from music discovery and video analysis through scoring, delivery, and user feedback. Minor gaps exist such as no explicit browse/album listing tool, but search_music can retrieve albums and composers, so this should not cause agent failures.