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

With no annotations, the description carries behavioral burden. It adds the auth requirement (paid tier, 403) and the mandatory-filter constraint. However, it omits details like default sorting (schema has 'randomize' but description doesn't explain default order), pagination, or response structure. It doesn't contradict but leaves gaps.

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?

Two short sentences, each essential. First sentence lists filters and constraint; second sentence states authorization requirement. No wasted words, front-loads the action and key conditions.

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?

Given 6 parameters, no output schema, and no annotations, the description covers the input constraints and authorization well but lacks details on output format, pagination, default ordering (randomize is implied but not default), and any limits. It provides sufficient high-level understanding but not full operational completeness.

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?

Description covers 5 of 6 parameters (all except randomize) and adds meaning beyond schema: 'genre ID (from list_genres)' implies a valid source. Also adds the constraint that at least one filter is required, which is not in the schema's optional parameters. This compensates for the 50% schema coverage.

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 uses 'Discover tracks by filter' as a specific verb+resource. It lists concrete filter fields (label ID, artist ID, genre name, genre ID, release year) and includes critical usage constraints ('At least one filter is required'). This clearly distinguishes it from sibling tools like search_tracks, which presumably do text-based search.

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?

Explicitly states the requirement of at least one filter, guiding when to use. Also notes the paid-tier prerequisite and potential 403 for free keys, which is a clear when-to-use/not-use boundary. Does not explicitly name alternative tools, but the required-filter constraint implies it's for filtered browsing, not free-form search.

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

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

With no annotations, the description carries the behavioral burden. It discloses ordering (newest first), pagination (cursor-based), and date range inclusivity. This is useful and goes beyond the schema. It does not mention edge cases like default limit, cursor staleness, or return format, but the core behavior is transparent.

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?

Two sentences with no wasted words. The main purpose is front-loaded, followed by pagination and filtering details. Everything earns its place and is easy to scan.

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 paginated list tool with 5 parameters and no output schema, the description gives the necessary information: purpose, ordering, pagination, and filter semantics. It does not explain default limits or error conditions, but these are less critical for basic invocation. Overall, adequate for correct use.

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?

Schema covers 80% of parameters with descriptions. The description's mention of from/until being inclusive and 'release-date range' is mostly redundant since schema already says 'on or after' and 'on or before'. Cursor semantics in the description mirror the schema's 'next_cursor from the previous page'. No significant new parameter meaning added.

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 exactly what the tool does: it returns an artist's releases, ordered newest first. This clearly distinguishes it from sibling tools like get_label_releases (by artist vs. label) and search_releases (direct listing vs. searching). The resource and scope are unambiguous.

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 implies usage context: you need an artist_id and can paginate with a cursor. It also explains how to filter by date range. However, it does not explicitly tell when to choose this over alternatives like search_releases, or when a label-oriented view would be better. Guidance is present but not exhaustive.

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

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

The description mentions it is cursor-paginated and includes an 'artist per release', which are useful behavioral details. Since no annotations are provided, these disclosures help. However, it doesn't mention what happens if no releases match, potential rate limits, or whether it supports only the given label or also sublabels. The description is decent but could add more edge-case behavior.

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 a single sentence that packs in the key details: sorting, pagination, date filter, and the same-day example. It is front-loaded with the main purpose and uses no filler words. Every clause adds value.

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?

Given the tool is a paginated list endpoint, the description covers sorting, pagination, and date filtering, which are the main usage points. It lacks explicit return format details, but since no output schema exists, the description could have mentioned that it returns releases with artist info, which it does. The main missing piece is what the 'artist' field contains (e.g., artist name vs ID), but that might be inferred from the schema of other tools. Overall, reasonably complete.

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 schema covers 60% of parameters, and the description adds context for the from/until parameters by explaining the inclusive date range and the same-day use case. It also clarifies that the returned data includes artist per release, which maps to the schema but isn't explicitly documented. For the limit and cursor parameters, it only mentions 'cursor-paginated', so it partially compensates for the schema gaps.

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 clearly states the tool returns a label's releases, newest first, with the artist per release. It distinguishes itself from siblings like get_artist_releases and search_releases by specifying it operates on a label and includes a release date filter. The verb 'get' and resource 'label releases' are specific and unambiguous.

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 explains the optional from/until date range and even gives a concrete use case (pass same day for both to see releases on a specific day). However, it doesn't explicitly mention when to use this vs search_releases or get_artist_releases, so some inference is needed. It does imply the tool is for label-scoped browsing.

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

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

With no annotations, the description carries the full burden. It explains the tool returns IDs and deep links for all platforms, but does not disclose error handling (e.g., if track not found on a platform), rate limits, or authentication requirements. The core behavior is clear but basic.

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?

A single sentence that packs all essential information: the action, output, supported platforms, and input constraint. No redundant words, front-loaded with the main purpose.

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?

The tool has 9 parameters and no output schema. The description hints that the output contains IDs and deep links for each platform, but does not elaborate on structure, whether it returns multiple results, or how failures are handled. It is functional but leaves room for ambiguity.

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?

Schema description coverage is only 11%, so the description must compensate. It adds that exactly one parameter should be used, but does not provide format hints (e.g., ISRC pattern) or clarify that some IDs are platform-specific. It lists platforms but adds little beyond the schema's property names.

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 clearly states the tool resolves a track to its ID and deep link on every supported platform, listing all platforms explicitly. It distinguishes from sibling tools by specifying the exact platforms and the input requirements.

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?

The description specifies that exactly one identifier must be provided, which is a key usage rule. However, it does not explain when to use this tool over alternatives like resolve_tracks or get_track, nor does it give examples of when not to use it.

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

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

No annotations are provided, so the description carries full burden. It states the tool returns sorted recordings with ISRCs, implying a read-only operation, but does not explicitly confirm safety, disclose rate limits, or describe error behavior (e.g., invalid ISWC format).

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?

Two sentences with no redundant information. The first sentence introduces the primary function and input format, the second explains the output characteristics. Efficient and 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?

The description covers the tool's purpose and output nature (recordings sorted by popularity, with ISRC). However, it lacks details about the output structure (e.g., fields beyond ISRC), error handling, and performance considerations. Given no output schema, more descriptive compensation is needed.

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?

Schema coverage is 100%, so parameters are documented. The description adds value by providing ISWC format examples, explaining the sort order (by popularity), and mentioning that each recording includes a representative ISRC. This supplements the schema's minimal descriptions.

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 clearly states the tool lists every recording of a musical work by ISWC, with examples of valid ISWC formats. It differentiates from sibling tools like lookup_isrc (ISRC lookup) and search_tracks (text search) by focusing on work-to-recordings mapping.

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?

The description implies usage when an ISWC is available and recordings of that work are needed, but does not explicitly state when not to use this tool or mention alternatives among siblings. No guidance on prerequisites or fallback strategies.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains track ordering, null-position handling for unknown track numbers, the multi-edition aggregation model, the meaning of the editions array and its fields, the edition parameter's renumbering effect, and the reason the MusicBrainz ID fields are arrays. This goes well beyond the schema.

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 long but information-dense and logically structured: main fetch operation first, then tracklist ordering, then the editions/edition parameter explanation, then the MusicBrainz arrays. Every sentence contributes necessary domain context or parameter behavior; there is no filler.

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?

Given there is no output schema, the description supplies what the agent needs to interpret the response: track fields, edition fields, and ID arrays. It also defines the domain-specific behavior of the optional edition parameter. No critical invocation detail appears to be missing.

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?

Schema coverage is already 100%, but the description adds real meaning: it explains that editions are aggregated onto one record, that passing an edition id swaps the default consensus numbering for that edition's numbering, and how tracks missing from an edition are placed. The id parameter's role is also clearly stated as the SonoVault release ID.

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 opens with a specific verb ('Fetch'), an exact target ('one release by SonoVault release ID'), and the key delivered content ('full tracklist with ISRCs'). This clearly separates it from sibling tools that list releases by artist or label, search releases, or retrieve single tracks.

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 gives clear context: use this when you already have a SonoVault release ID and need the release plus tracklist/edition data. It does not explicitly name alternatives or say when not to use it, but the direct-by-ID phrasing is enough to disambiguate from the search/list siblings.

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

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

No annotations provided, so description carries full burden. Only states 'with full metadata' without elaborating on what metadata is returned, or any other behavioral traits like side effects or rate limits.

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?

Single sentence, no wasted words, front-loaded with action and resource. Efficient and clear.

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 simple fetch tool with one parameter and no output schema, description covers purpose but lacks detail about what 'full metadata' includes. Adequate but could be more complete.

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?

Schema coverage is 100%, with schema description 'SonoVault track ID'. Description adds same phrase, no additional meaning beyond schema. Baseline 3 appropriate.

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?

Description clearly states verb 'Fetch', resource 'one track', and unique identifier 'SonoVault track ID'. This distinguishes it from sibling tools like search_tracks (searching) and browse_tracks (browsing).

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?

Explicitly states when to use (when you have a specific track ID). Does not explicitly mention when not to use or list alternatives, but sibling tool names provide enough context to differentiate.

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

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

With no annotations, the description must cover behavioral traits. It mentions that one recording can have multiple ISWCs, a key nuance. However, it does not specify the return format, pagination, or error behavior, leaving gaps in transparency.

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 three concise sentences, front-loaded with the core action. Every sentence adds value without repetition or fluff.

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?

Without an output schema, the description should more fully explain the return structure. While it indicates multiple ISWCs may be returned, it omits details on format or empty results, leaving the agent with incomplete expectations.

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?

Schema coverage is 100% with clear parameter descriptions. The description restates the parameters without adding new meaning, so it does not exceed the baseline expectation for parameter semantics.

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 clearly states the tool finds ISWC work codes based on a recording, using ISRC or track ID. It distinguishes from sibling tools by focusing specifically on ISWC mapping for royalty workflows.

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?

The description indicates use for royalty and publishing workflows, providing clear context. However, it does not explicitly contrast with sibling tools like get_recordings_of_work or lookup_isrc, leaving some ambiguity about when to choose this tool over alternatives.

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

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

No annotations, but the description conveys the read-only nature and output content. Could mention that it returns a list or tree, but still adequate.

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?

One sentence, directly front-loaded with 'canonical'. No superfluous information.

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 simple list with no input or output schema, description is sufficient. Could be more specific about hierarchy structure, but not critical.

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?

No parameters exist; schema coverage is 100%. Description adds meaning by specifying output details, meeting expectations for a parameterless tool.

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?

Description clearly states it lists the canonical SonoVault genre hierarchy with 25 main genres, subgenres, and IDs. No ambiguity.

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?

No explicit when-to-use guidance, but the tool is self-explanatory and has no close sibling. Slight deduction for lack of usage context.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states returns 'full metadata' but does not specify what fields are included or describe error conditions, rate limits, or side effects. The transparency is minimal.

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 a single sentence, very concise and front-loaded. It efficiently conveys the purpose and gives an example. However, it could be slightly improved by mentioning the return format without adding much length.

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 simple lookup tool with no output schema, the description is mostly adequate but lacks specifics about what 'full metadata' includes. No error handling or result structure is described, leaving some gaps for an AI agent.

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 schema description coverage is 100% for the single parameter 'isrc', and the main description also includes an example. The schema already documents the parameter adequately, so the description adds little beyond what is in the schema, resulting in a baseline score of 3.

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 clearly states 'Exact lookup of a recording by its ISRC', providing a specific verb (lookup) and resource (recording by ISRC). It includes an example ISRC code for context, distinguishing it from sibling tools like search_tracks or get_track which use different identifiers or search methods.

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?

The description implies usage when an ISRC is available for an exact lookup, but it does not explicitly state when not to use it or mention alternatives such as get_track or search_tracks. The guidance is present but not detailed.

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

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

With no annotations, the description carries the full burden. It discloses the 100-input limit, cost per line, and input_type mapping. Missing details on error handling or response format, but provides solid behavioral traits.

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 sentences with front-loaded purpose. The second sentence is dense but efficient, covering all parameter details without redundancy. Slightly long but earns its place.

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?

Without an output schema, the description vaguely mentions 'canonical tracks plus cross-platform links' but lacks detail on return structure, error behavior, or partial results. For a batch tool, more completeness is needed.

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?

Schema coverage is 50%, but the description adds crucial semantics: it explains how input_type selects the key format and specifies the {artist, title} structure for 'track_name' objects, going beyond the schema's anyOf definition.

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 clearly states the tool resolves up to 100 inputs to canonical tracks and cross-platform links, using a specific verb and resource. It also explains the input_type parameter, distinguishing it from sibling tools like get_track or search_tracks.

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?

The description indicates usage for batch resolution with cost and limit details. While it doesn't explicitly state when not to use or list alternatives, the context of sibling tools and the focus on bulk resolution provide clear guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the return fields, which is useful, and implies a read-only search operation. However, it does not disclose behavior like partial matching, case sensitivity, pagination, or what happens with no results. The description is honest but not deeply transparent about edge-case behavior.

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 a single, information-dense sentence. It front-loads the action and resource, then lists return fields. Every clause earns its place; no filler or redundancy.

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 simple search tool with 2 parameters and no output schema, the description covers the core purpose and return fields. However, it lacks guidance on the 'limit' parameter, result ordering, or matching behavior. Given the tool's simplicity, this is adequate but not complete; an agent might not know how to interpret the limit parameter or what the default is.

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?

Schema description coverage is 50%: the 'name' parameter is described in the schema, but 'limit' has no description. The tool description adds the return-field context and the purpose of the identifiers, but it does not explain the 'limit' parameter's semantics or default behavior. With 50% coverage, the description partially compensates but leaves the limit parameter undocumented.

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 ('Search'), a resource ('artists'), and the search key ('by name'). It also lists the return fields, which distinguishes it from sibling search tools like search_tracks and search_releases. The tool name and title are reinforced, not merely restated.

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?

The description implies usage context: use this when you need to find an artist by name and get identifiers for joining external datasets. However, it does not explicitly state when to prefer this over siblings like get_artist_releases or search_labels, nor does it mention any exclusions or alternatives. The mention of identifiers for joining against external datasets gives some context but not explicit routing guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the return fields (id, name, release count) but omits details about pagination, ordering, or behavior for missing results. The read-only nature is implied but not stated.

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 concise sentences with no wasted words. It front-loads the primary action and return value, making it easy to parse.

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?

Given the tool's simplicity (two parameters, no output schema, no annotations), the description provides basic functionality and return shape but lacks details on matching behavior (e.g., case sensitivity, partial match) and pagination, leaving some gaps.

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?

Schema description coverage is 50% (only 'name' described). The tool description adds no meaning beyond the schema for either parameter. The 'limit' parameter is not mentioned, so the description does not compensate for the low coverage.

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 clearly states the verb 'Search' and the resource 'record labels', and specifies the criterion 'by name'. It effectively distinguishes this tool from sibling tools like search_artists and search_releases, which operate on different entities.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives beyond the resource name. While the sibling tools are distinct, no when-not or specific context is given, leaving usage implied.

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

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

No annotations provided, so the description must carry the full burden. It does not disclose any behavioral traits beyond basic search (e.g., no mention of result formatting, pagination, case sensitivity, or limitations).

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?

Single sentence, no fluff. However, it omits the limit parameter, which reduces completeness. Still efficient.

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?

No output schema, yet the description does not explain result structure, pagination (limit is not mentioned despite being in schema), or sorting. Missing critical context for a search tool.

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?

Schema provides descriptions for title and artist (67% coverage). The description paraphrases those but adds no new semantics. The limit parameter is not mentioned. Baseline 3 is appropriate.

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 clearly states the action ('search releases') and the key parameters (title, optional artist). However, it does not explicitly distinguish from sibling tools like search_tracks or search_artists, though the focus on releases and title is implicit.

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?

No guidance on when to use this tool vs alternatives (e.g., get_release for a known ID, or search_artists for artist-first workflows). The description only explains what it does, not when to prefer it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains that both fields are required, free-text search is not available, and lists the fields returned per track. It does not cover edge behavior such as exact-match semantics, pagination, or auth requirements, but for a search tool the description is adequately transparent.

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 sentences with no filler. It front-loads the purpose, then the key constraints, and then the return information. Every clause adds useful information.

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?

The description covers the primary purpose, required parameters, constraints, and return fields, which is adequate for a search tool even without an output schema. It could further clarify match behavior or when to prefer sibling tools like lookup_isrc or resolve_tracks, but overall the agent has enough context to 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?

Schema description coverage is 100%, so the schema already documents the three parameters. The description adds context by stating both artist and title are required and clarifies the no-free-text limitation, but it does not add substantial meaning beyond the schema's own descriptions.

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 clearly states the tool searches the SonoVault catalog by artist and title, which is a specific verb and resource. It distinguishes itself from sibling tools like search_artists and search_releases by the required parameters and the note that there is no free-text search, though it does not explicitly name these alternatives.

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?

The description provides clear context for when to use the tool: when both artist and title are known, and explicitly notes that both are required and free-text search is unsupported. It does not explicitly discuss alternatives or when not to use this tool, but the boundary is reasonably clear.

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