lastfm-mcp

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact — 'Needs authentication' — which the annotations do not convey. It does not contradict the annotations (a tag-apply operation matches readOnlyHint=false), but it discloses little else, such as behavior on duplicate tags or whether existing tags are merged.

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 tight and front-loaded: the purpose and auth requirement lead, followed by a compact one-line-per-parameter list. There is no filler. It is appropriately concise, though the arg list could be merged into prose without losing clarity.

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 presence of an output schema and security annotations lowers the burden for return-value disclosure, and the description covers the essentials of a simple 3-parameter write tool. However, given the dense sibling set of add_artist_tags, add_track_tags, and remove_album_tag, the description misses a chance to clarify how this tag operation differs from those, which is the main completeness gap.

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?

With schema description coverage at 0%, the description carries the full burden of parameter documentation and does compensate: it names each parameter and adds format detail — 'Up to 10 tags, comma separated' — that the bare schema lacks. This is meaningful, though it could go slightly deeper (e.g., whether tags must already exist or are created on demand).

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+resource combination, "Apply your own tags to an album," which clearly states the operation and distinguishes it from retrieval siblings like get_album_tags and get_album_top_tags. The phrase 'your own tags' also signals user-scoped tagging. However, it does not explicitly contrast itself with the closely related add_artist_tags and add_track_tags, relying on the name to carry that differentiation.

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 gives no guidance on when to use this tool versus alternatives such as add_artist_tags, add_track_tags, or remove_album_tag, and no indication of prerequisites beyond authentication. There is no when-to-use or when-not-to-use framing, leaving the agent to infer usage from the tool name alone.

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?

Annotations already indicate this is a mutating, idempotent, non-destructive operation.me description adds valuable behavioral context beyond annotations: it requires authentication and clarifies that tags are applied to the authenticated user's own tag set. It does not contradict the annotations.

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 brief and front-loaded: a one-sentence purpose, an authentication note, and a compact argument list. Every sentence earns its place with no 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 two-parameter mutation with an output schema and supporting annotations, the description covers purpose, authentication, and both parameters' semantics. Nothing critical is missing for an agent to invoke this 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 0%, so the description must compensate. It does: 'artist' is defined as an artist name, and 'tags' is given format constraints ('Up to 10 tags, comma separated'). This adds genuinely useful meaning beyond bare property names and string types.

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 action ('Apply your own tags') on a specific resource ('an artist'), clearly distinguishing it from sibling tools like add_album_tags, add_track_tags, and remove_artist_tag. The mention of 'your own' also signals that this is a user-specific tagging operation.

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 intended use is implied: use this tool when you need to tag an artist. However, the description does not explicitly contrast it with alternatives like remove_artist_tag or get_artist_tags, nor does it state any conditions under which another tool should be preferred.

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?

Annotations already establish non-read-only, non-destructive, idempotent behavior; the description adds 'Needs authentication' and 'your own tags,' which clarifies personal vs community tagging. It does not cover effects on existing tags or response behavior, but this is tempered by the annotations and output 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?

Three short lines plus an args block; the main action and auth requirement are front-loaded. No filler or repetition.

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 three-parameter mutation with output schema and annotations present, the description covers the action, auth requirement, and parameter constraints. It could add a pointer to remove_track_tag/get_track_tags or clarify effects on existing tags, but these are not essential for a correct call.

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?

With 0% schema description coverage, the description is responsible for parameter meaning. It provides one-line definitions for artist, track, and tags, with the useful constraint 'Up to 10 tags, comma separated.' However, 'Artist name' and 'Track name' largely restate the property titles, so the added semantic value is only moderate.

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 opens with 'Apply your own tags to a track', a specific verb ('apply') and resource ('track') plus the personal-tag scope. This distinguishes it from sibling write tools like add_album_tags/add_artist_tags and read tools like get_track_tags.

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 gives the prerequisite that authentication is needed, but does not explicitly state when to use this tool over remove_track_tag or add_artist_tags/add_album_tags, nor mention scenarios where it should not be used. Usage context is only implied by the tool name and first sentence.

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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds the specific behavioral consequence: disabling writes until re-authentication. This provides actionable context beyond the binary hints, clarifying the exact scope of impact. No contradiction with annotations; the description enhances rather than repeats.

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, dense sentence that front-loads the core action ('Forget the stored session key') followed by the consequence. There is no filler or redundant phrasing. Every word contributes meaning, making it highly 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?

Given the tool's simplicity (no parameters, output schema present), the description is complete. It states what the tool does, the effect on writes, and the condition for recovery (re-authentication). With annotations covering safety indicators, nothing critical is missing for an agent to correctly invoke this 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?

With zero parameters, the schema is trivially complete (100% coverage). The description needs to convey no parameter information. Per the rubric, a tool with 0 parameters receives a baseline of 4, and the description appropriately does not attempt to add nonexistent parameter details.

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 (forget stored session key) and the consequence (disabling writes until re-authenticated). This is specific and distinct from sibling authentication tools like start_authentication or finish_authentication. The agent immediately understands the tool's function without 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?

The description implies usage (when you need to invalidate the session) but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. Since there are no alternative paths discussed, the guidance is only implied through the purpose, not explicitly provided.

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 adds a useful behavioral detail: the result is a stored session key rather than just a return value. However, it does not disclose potential side effects, failure modes, or what happens if the token is invalid, and the annotations already cover idempotency and non-destructiveness.

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 short sentences with no filler. The core behavior is stated first, and the parameter explanation directly follows in a clear, scannable format.

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 single-parameter authentication-completion tool, the description contains everything needed to invoke it correctly. Since an output schema exists, return-value details are already covered elsewhere, and no further prerequisites or caveats are essential for this step.

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?

Despite 0% schema description coverage, the description fully explains the only parameter: token is the one returned by start_authentication after browser approval. This adds essential provenance and precondition information that the raw schema property name 'Token' does not provide.

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 action ('Exchange an approved token for a stored session key') and identifies the exact resource involved. It clearly reads as the completion step in an authentication flow, distinguishing it from siblings like start_authentication, get_authentication_status, and clear_authentication.

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 gives clear usage context: the token must come from start_authentication and be approved in the browser before being passed. It does not explicitly list alternatives or when-not-to-use conditions, but the sequential guidance is strong enough to route an agent correctly.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds useful context like using mbid instead of names and autocorrect behavior, but does not mention potential response formats or rate limits. It does not contradict annotations.

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 concise and front-loaded with the main purpose, followed by a clear parameter list. Each sentence earns its place; no 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?

Given the complexity of 6 parameters with no required ones, and the presence of an output schema, the description covers key usage aspects. It explains the mutually exclusive name/mbid requirement and optional parameters. Missing edge cases like error conditions are not critical given the output schema.

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 0%, so the description must compensate, and it does by explaining album, artist, mbid, username, autocorrect, and lang. However, it doesn't detail the format or required syntax for each beyond the basic explanation, relying on parameter 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 states a clear purpose: 'Get album metadata' with a specific list of data types (tracklist, listeners, playcount, tags, wiki). This is distinct from sibling tools like get_album_tags or search_albums, which target subsets or different operations.

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 the tool is for retrieving album-level metadata but does not explicitly state when to choose this over siblings like get_album_tags or search_albums. It provides no exclusions or conditions, but the purpose is clear enough to infer basic usage.

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?

Annotations already declare readOnly, idempotent, and non-destructive, and the description adds useful behavior: artist/album are only required when mbid is absent, omitted user uses the authenticated account, and autocorrect can fix misspellings. This goes beyond the structured metadata without contradicting it.

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 purpose sentence is front-loaded and the Args block is compact, with each parameter earning its place. No filler or repetition exists.

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?

With an output schema present and annotations covering the read-only safety profile, the description sufficiently explains the call contract: what resource is read, which user is used, and the identifier options. It might still benefit from explicitly pointing to get_album_top_tags for aggregated tags, but that gap is minor.

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 0%, so the description is the only source of parameter meaning. It documents all five parameters and explains the required-unless-mbid relation, the default user behavior, and the autocorrect behavior. It does not provide extra formatting details, but the schema already supplies types and defaults.

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 first sentence states a specific verb and resource: it gets the tags a single user applied to an album. This clearly separates it from sibling get_album_top_tags, which returns aggregated top tags, and from other tag-related tools.

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 makes clear this is for reading one user's personal tags and that user defaults to the authenticated account, giving a clear usage context. It does not explicitly list alternatives or say when not to use get_album_top_tags, but the 'one user' framing conveys when this tool is appropriate.

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?

Annotations already declare read-only, idempotent, open-world, and non-destructive. The description adds community scope and popularity ordering, which is useful context beyond annotations, but it does not disclose rate limits, authentication requirements, or error behavior. With annotations present, this is 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?

The description is extremely concise and front-loaded with the purpose, followed by a clean parameter list. Every sentence earns its place, and there is no 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 read-only lookup with an output schema, the description covers the core semantics and parameter meanings. It lacks deeper explanation of how mbid interacts with artist/album and does not mention potential edge cases, but it is minimally viable.

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 has zero description coverage, and the Args section compensates well by explaining each parameter, including the 'Required unless mbid is given' relationship and the autocorrect behavior. It could be more explicit that artist and album are typically paired, but overall it adds meaningful value.

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?

States a specific action ('Get the tags') and resource ('an album') with a clear scope ('whole community') and ordering ('by popularity'). It is distinct from user-specific tag tools but does not explicitly name sibling alternatives, so it just misses a 5.

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 about when to use this tool versus siblings like get_album_tags or get_artist_top_tags. The 'whole community' phrase implies a use case, but there is no explicit when-to-use, when-not-to-use, or alternative routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context around autocorrect fixing misspellings and username-scoped playcounts, but does not disclose behavior such as precedence when both artist and mbid are supplied or error behavior for unknown artists.

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 compact: a one-line purpose summary followed by a tight Args list. Every sentence adds value and the key constraint about artist/mbid is front-loaded. No filler or repetition.

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 read-only metadata getter with an output schema and annotations already present, the description covers the parameters and the shape of the returned data well. It is missing only light usage guidance that would help an agent decide between this and sibling artist endpoints.

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 0%, but the Args block fully compensates: every parameter gets an explanation, and the crucial semantic that artist is required unless mbid is given is stated. This adds meaning the bare nullable schema cannot convey.

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?

States a specific verb ('Get') and resource ('artist metadata'), and enumerates the returned fields (listeners, playcount, similar artists, bio). This clearly distinguishes it from sibling artist endpoints like get_artist_top_tracks, get_artist_tags, or get_artist_correction by scope of metadata.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives. An agent must infer from 'artist metadata' that this is for core profile data rather than artist charts or tags; no exclusions or prerequisites are provided.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the core behavioral intent—returning a canonical spelling—but does not disclose extra details such as fallback behavior if no correction exists. With no contradiction and strong annotation coverage, a 3 is appropriate.

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 one focused sentence followed by a compact Args block. It front-loads the purpose and adds no redundant or filler content.

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 single-parameter, read-only tool with an output schema and comprehensive annotations, this description gives an agent everything needed to invoke it correctly. No critical invocation details are 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?

The Args section fully documents the only parameter: "The name as written, possibly misspelled." This goes beyond the schema's bare title and tells the agent to pass the raw user-entered spelling rather than a pre-corrected value, which is essential for correct use.

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 identifies the action and resource: "Get Last.fm's canonical spelling for a misspelled artist name." This distinguishes it from artist metadata retrieval tools like get_artist and search_artists, even 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.

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

The description gives a clear use condition: call this when you have a possibly misspelled artist name and need Last.fm's canonical spelling. It does not explicitly list alternatives or exclusions, but the correction-specific purpose makes the invocation context clear.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond the schema: artist is required unless mbid is given, user defaults to the authenticated account, and autocorrect can rewrite the artist name. No contradiction with annotations exists.

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 compact, with the core purpose in the first sentence and a tight Args list that adds only necessary detail. No filler or redundancy is present.

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 read-only, non-destructive lookup with an output schema, the description covers all parameters and key behaviors. Minor gaps remain, such as not specifying behavior when both artist and mbid are supplied or what happens when neither is provided, but the description is otherwise sufficient for correct invocation.

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 0%, so the description carries the full burden for parameters, and it succeeds. It explains the meaning of each parameter, the conditional requirement between artist and mbid, the user default, and the effect of autocorrect. This is significantly more informative than the plain parameter names in 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-resource pair ('Get the tags one user applied to an artist') and includes the owner dimension, which clearly distinguishes it from sibling tools like get_artist_top_tags or get_tag_top_tags. An agent can infer exactly what this call returns and who it is scoped to.

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 establishes clear usage context: it reads a specific user's tags on an artist, and it clarifies the artist/mbid relationship and the default user. It does not explicitly name alternatives or exclusion cases, but the 'one user' phrasing makes the intended use reasonably obvious.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, establishing this as a safe read operation. The description adds behavioral context about pagination (limit/page) and autocorrect functionality, which are not covered by annotations. It does not contradict the annotations and provides useful extra detail.

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 clear sentence followed by a structured Args list. It is front-loaded with the main purpose and provides parameter details efficiently without any fluff or redundancy. Every sentence 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?

For a read-only list tool, the description covers the purpose, all parameters, and pagination behavior. It does not describe the response format, but an output schema exists to handle that. It lacks explicit mention of sorting or rate limits, but these are not critical for a simple retrieval operation. The description is sufficiently complete for an agent to call it 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 schema has zero property descriptions (coverage 0%), so the description must compensate. It fully explains each parameter: artist (required unless mbid given), mbid (MusicBrainz ID), limit (results per page), page (which page to fetch), and autocorrect (fix misspelled names). This adds meaningful semantics beyond the raw schema and clarifies the relationship between artist and mbid.

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 'Get an artist's most played albums.' This clearly identifies the action (get) and the specific resource (artist's most played albums). It distinguishes itself from sibling tools like get_user_top_albums and get_tag_top_albums by targeting the artist context. It is a precise, non-tautological statement.

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 any guidance on when to use this tool versus alternatives. It does not mention alternatives, prerequisites, or exclusions. The only usage hint is that 'artist' is required unless 'mbid' is given, which is more about parameter selection than tool selection. There is no comparison to get_artist_top_tracks or other artist-specific tools.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the 'community applied' semantic and the 'by popularity' ordering, which are useful behavioral details. It does not disclose potential errors, response size limits, or behavior when neither artist nor mbid is provided, but the output schema exists and the tool is simple.

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 components: a one-sentence purpose statement that is front-loaded, and a compact Args list. Every piece of text earns its place, and there is no fluff. The format is scannable and appropriately sized for a simple read-only tool.

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 read-only query tool with output schema and annotations covering safety, the description covers the essentials: purpose, parameter semantics, and a key ordering constraint. It does not explain the difference from get_artist_tags or handle edge cases (e.g., both artist and mbid omitted) beyond the conditional requirement. Overall, it is adequate and complete for most agent usage.

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 0%, so the description must compensate. The Args section does this by explaining the effect of autocorrect and the conditional requirement of artist/mbid. This adds real meaning beyond the type/nullable schema fields. It could have included formats or examples, but the provided semantics are sufficient for correct invocation.

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 ('Get'), resource ('the tags the community applied to an artist'), and ordering ('by popularity'). This clearly distinguishes it from the sibling 'get_artist_tags' (which presumably returns a user's own tags) and other entity-specific top-tags tools.

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 when to use the tool (when you need community-applied tags for an artist) but does not explicitly contrast it with alternatives like get_artist_tags or get_album_top_tags. It provides parameter usage guidance ('artist required unless mbid is given') but no exclusion criteria or explicit 'use this instead of X' statements.

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?

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the burden on the description. The description adds meaningful behavioral context including the autocorrect behavior (fixing misspelled names) and the conditional requirement that artist is needed unless mbid is provided. It does not disclose rate limits or auth needs, but these are less critical given the annotation coverage.

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 front-loaded summary sentence followed by a clean, well-formatted Args list. Every line earns its place, with no tautology or 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 the output schema exists, the description need not explain return values. It covers all parameters and the key dependency (artist or mbid). It could be slightly more complete by explicitly noting behavior when neither parameter is supplied or how the artist/mbid interaction is resolved, but overall it is adequate for a 5-parameter 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 description coverage is 0%, so the description must fully compensate. The Args block provides clear, useful semantics for all five parameters: artist (name, required unless mbid), mbid (MusicBrainz ID), limit (results per page), page (pagination), and autocorrect (fix misspellings). This adds significant meaning beyond the raw 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's first sentence, 'Get an artist's most played tracks', uses a specific verb and resource, and the 'artist's' qualifier clearly distinguishes it from sibling tools focusing on users, tags, charts, or albums. This leaves no ambiguity about which endpoint is being described.

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 clearly implies the tool is for artist-scoped top tracks, which is enough for an agent to choose it over user/chart/tag track tools. However, it does not explicitly state when to prefer this over get_artist_top_albums or get_user_top_tracks, nor does it mention any exclusions.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that the session is 'write-capable' and that the report includes which user, which goes beyond the annotations and is useful for the agent. 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.

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

A single, front-loaded sentence that efficiently conveys the tool's purpose without any wasted words. It is concise and well-structured.

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 zero-parameter, read-only status tool with an output schema, the description fully covers what an agent needs to know to call it correctly. The output schema handles return values, so no further details are required.

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 tool has zero parameters, so the description has nothing to add. Per the rubric, 0 params sets a baseline of 4, and the description appropriately omits any parameter details, as none exist.

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 a specific verb ('Report') and a specific resource ('whether a write-capable session is stored') and includes the scope ('for which user'). It clearly distinguishes from authentication lifecycle siblings like start_authentication, finish_authentication, and clear_authentication, as well as other get_* tools.

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 guidance on when to use this tool versus alternatives. The context implies it is for checking session status before write operations, but the description does not state that or name any alternatives or exclusions. The agent must infer usage.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so no safety contradiction exists. The description adds only the temporal nuance "right now" and does not discuss pagination behavior, response shape, or potential limitations; this is acceptable but not rich.

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 compact and front-loaded, with a single purpose sentence followed by a minimal parameter list. No words are wasted, and it remains informative for the tool's simplicity.

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 read-only list tool with an output schema and annotations, the description covers the operation and both parameters. It could be more explicit that this is the global Last.fm chart rather than user- or region-specific, but the name and "right now" mostly convey that.

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 0%, so the description carries the burden of explaining the parameters. It does so adequately: limit is "Results per page" and page is "Which page of results to fetch." This adds meaning beyond the bare integer types and defaults.

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 clear action and resource: "Get the most popular artists on Last.fm right now." It distinguishes from chart top tracks/tags by resource, but does not explicitly differentiate from user or geo-scoped artist tools, so it loses the last point.

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?

There is no guidance on when to use this tool vs. alternatives like get_user_top_artists, get_geo_top_artists, or get_chart_top_tracks. The context is implied by the name, but no exclusions or selection criteria are stated.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. It adds the temporal context 'right now' but doesn't disclose additional behavioral details like pagination limits beyond parameter semantics.

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 extremely concise and front-loaded: a clear one-sentence purpose followed by compact parameter explanations. There is no wasted wording or redundant restatement of the schema.

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 simple two-parameter shape, rich annotations, and presence of an output schema, the description is complete enough for an agent to select and call the tool correctly. No missing essential context stands out.

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 0%, so the description must carry parameter meaning. It does so clearly: 'Results per page' for limit and 'Which page of results to fetch' for page. This is basic but sufficient for the two simple parameters.

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 resource and action: 'Get the most popular tags on Last.fm right now.' The explicit mention of 'tags' plus the chart context distinguishes it from sibling chart tools like get_chart_top_artists and get_chart_top_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?

No guidance is given about when to use this tool versus alternatives such as get_top_tags or the user-specific tag tools. The description only states what the tool does, not when it should be selected.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safe read-only nature is well covered. The description adds a small behavioral cue with 'right now,' implying the chart is time-sensitive and may change. It does not mention rate limits or pagination behavior beyond parameter meanings, but for this simple read-only chart tool the annotation coverage lowers the burden.

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 compact and front-loaded: one clear sentence announces the tool's purpose, followed by concise parameter explanations. There is no redundant or filler content; every sentence 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?

For a simple paginated read-only chart tool with strong annotations and an output schema, the description covers the core purpose and parameters well. It is slightly incomplete given the large sibling set, because it does not explicitly state that this is the global Last.fm chart or contrast it with geo-, tag-, or user-specific track tools.

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?

Although the input schema has 0% description coverage, the tool description fully compensates by explaining both parameters: 'limit: Results per page' and 'page: Which page of results to fetch.' This adds meaningful semantics beyond the schema's types and defaults, giving an agent enough information to construct correct calls.

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 action and resource: 'Get the most popular tracks on Last.fm right now.' This is clear and points to the global chart rather than user- or geo-scoped track listings. However, it does not explicitly name or differentiate sibling tools like get_chart_top_artists or get_geo_top_tracks, so it falls just short of full differentiation.

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 phrase 'right now' implies current global popularity, which suggests when to use this tool versus user, geo, or tag-specific track tools. There is no explicit guidance about when not to use it or which alternative to prefer in other contexts, leaving the usage decision mostly to inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. However, the description adds no behavioral context beyond the annotations—no mention of pagination behavior, auth requirements, rate limits, error cases, or result ordering. With annotations present, the bar is lower, but the description still provides zero additional behavioral insight.

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 short sentences plus an argument list, with no wasted words. It front-loads the core purpose and then gives per-parameter explanations. Every sentence 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?

For a simple read-only tool with an output schema and strong annotations, the description covers the essential aspects: purpose and parameter semantics. It does not explain any prerequisites or edge cases, but these are less critical given the low complexity and existing structured metadata.

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 0%, so the description must compensate. It does: country is explained as 'Country name in ISO 3166-1 form, such as Finland,' and limit/page are defined as 'Results per page' and 'Which page of results to fetch.' This adds meaningful guidance beyond the bare schema types and defaults.

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 a specific verb and resource: 'Get the most popular artists in one country.' This differentiates it from sibling tools like get_geo_top_tracks (tracks vs artists), get_chart_top_artists (global chart vs country), and get_tag_top_artists (tag-based vs geo-based).

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 no guidance on when to use this tool versus alternatives such as get_chart_top_artists or get_user_top_artists. It only implicitly suggests country-based use, but does not explicitly name any sibling or condition for choosing 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description doesn't need to restate those. It adds value by noting the scoping to a single country and optional city narrowing (location), which is context beyond the schema. No contradictions 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.

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

The description is concise, using a single sentence for the purpose and an Args list for parameters. It is front-loaded with the core function first, and every sentence adds value. No redundancy or 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 the tool's moderate complexity (4 parameters, one required) and the presence of an output schema, the description is largely complete. It covers the key parameters and hours of use is clear. It could be more complete by noting pagination behavior (e.g., max limit) or return structure, but the output schema likely covers that. The description is sufficient for an agent to call 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 input schema has 0% description coverage, so the description carries the burden of explaining parameters. It provides useful but brief descriptions for all four parameters: country as ISO 3166-1, location as optional narrowing, and limit/page for pagination. While it doesn't specify exact formats for limit/page beyond defaults, it compensates adequately for the schema's lack of 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 a specific verb ('Get') with a resource ('most popular tracks in one country'), making its purpose immediately understandable. It is distinct from the sibling 'get_geo_top_artists', which targets artists, so an agent can easily differentiate them without opening the schema.

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 the tool is for fetching top tracks by country but does not explicitly state when to prefer it over alternatives like 'get_chart_top_tracks' or 'get_user_top_tracks'. There is no mention of exclusions or prerequisites beyond the required 'country' parameter, so usage context is implied but not explicit.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns playcounts and that 'user' defaults to the authenticated account, which is useful. However, it doesn't disclose pagination behavior beyond the parameters, or any rate-limit or data-completeness caveats. 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.

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

The description is compact and front-loaded with the core purpose. The Args section is terse and useful. It earns its place without fluff, though the format is a bit mechanical.

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 read-only, idempotent list tool with an output schema and only three optional parameters, the description covers the essential semantics. It doesn't explain return value structure, but the output schema exists, so that burden is reduced. Minor gaps: no mention of pagination defaults or how 'every artist' interacts with pagination, but overall adequate.

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 0%, so the description must compensate. It does explain 'user' (whose library to read, defaults to authenticated account) and 'limit'/'page' (results per page, which page). This adds meaning beyond the bare schema, but it's minimal and doesn't clarify types, ranges, or edge cases. 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 states a specific verb and resource: 'Get every artist in a user's library, with playcounts.' This clearly distinguishes it from sibling tools like get_user_top_artists or get_chart_top_artists, though it doesn't explicitly name a sibling. The scope ('every artist in a user's library') is clear.

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: it reads a user's library, and the 'user' parameter defaults to the authenticated account. However, it doesn't explicitly state when to use this tool versus alternatives like get_user_top_artists or get_chart_top_artists, nor does it mention any exclusions or prerequisites.

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?

Annotations already declare the operation is readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds the observable ordering behavior ('most similar first') and the effect of the autocorrect parameter, but does not mention other behaviors like pagination or rate limits. This is adequate for such a simple read-only lookup.

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 compact: one clear sentence introducing the tool and a short Args list that covers every parameter without extraneous wording. Every sentence is necessary.

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 read-only, idempotent tool with an output schema, the description covers the essential aspects: purpose, how to identify the subject, and how to control the result. The output schema handles return-format details, so nothing critical is 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?

Input schema descriptions are completely absent (0% coverage), so the description must compensate. All four parameters are explained: artist and mbid as alternatives, limit as an expected count, and autocorrect as a flag for typo correction. This fully makes up for the lack of schema-level documentation.

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 a specific verb ('Get') and resource ('similar artists') and adds the ordering detail 'most similar first', making the purpose unmistakable. It clearly stands apart from siblings like get_artist or get_artist_top_artists, which focus on different facets of an artist.

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 conveys the context of when to use this tool: when you need artists 'similar to this one'. It does not explicitly mention alternatives or exclusions, but the parameter note 'artist required unless mbid is given' gives an implicit necessity to choose one identifier path.

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 annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds only the notion of similarity, with no extra context about result ordering, limits, unknown tags, or authentication requirements. It does not contradict the annotations.

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 extremely brief and front-loaded: one clear purpose sentence followed by a single parameter definition. Every word earns its place and there is no redundant or boilerplate content.

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 one-parameter, read-only tool with rich annotations and an output schema, the description is mostly sufficient to select and invoke it correctly. The main missing context is what 'similar' means semantically, such as similarity source, ordering, or limits, but this is not critical for basic invocation.

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 0%, so the Args line carries the burden. It clarifies that 'tag' is a tag name and acts as the similarity seed, which is meaningful beyond the schema's bare string type. It does not explain exact-match behavior or formatting, but the single simple parameter is adequately described.

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 that the tool retrieves tags similar to a given tag, naming the resource and the relationship. It is distinguishable from nearby siblings like get_tag_info or get_similar_artists, though it does not explicitly contrast itself with them.

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 intended situation is implied: use this when you need tags similar to a specific tag. However, the description gives no explicit guidance about when to choose this over other tag-related tools and states no exclusions or prerequisites.

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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that results are sorted 'most similar first' and that autocorrect can fix misspelled names, which add value beyond annotations. However, it does not mention any potential latency, rate limiting, or the fact that it might call an external API, which would be useful context.

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 concise and well-structured, with a one-line summary followed by a clear list of parameters. Each sentence serves a purpose, and the key usage condition ('Required unless mbid is given') is front-loaded. No fluff or redundant 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?

Given the tool's moderate complexity (5 params, no required params), the description is complete: it covers what the tool returns (similar tracks, most similar first), the parameter combinations, and autocorrect behavior. The presence of an output schema also reduces the need to explain return values, so nothing essential is 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 description coverage is 0%, so the description must compensate. It does explain the purpose of each parameter, including the conditional requirement for artist/track vs mbid, and the meaning of autocorrect. This is more than the bare schema provides, effectively covering the 5 parameters.

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's function: 'Get tracks similar to this one, most similar first.' This is a specific verb ('Get') with a resource ('tracks similar to this one') and an ordering detail. It is easily distinguished from sibling tools like get_track, get_similar_tags, or get_user_recent_tracks, all of which have different resources.

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 use: it is about finding similar tracks, which is not covered by other tools like get_track or get_similar_artists. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit exclusionary 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the specific data returned and explains that lang affects the description language, but it does not discuss behavior for unknown tags or null lang. This is acceptable given the strong annotations, but not especially rich.

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 compact and front-loaded: a one-sentence summary followed by a minimal, directly relevant Args block. There is no filler or redundant restating of the tool name.

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 read-only, two-parameter tool with an output schema and strong annotations, the description is nearly complete. It could be slightly improved by defining what 'reach' means or noting behavior when lang is omitted, but nothing essential is missing for invoking the 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 description coverage is 0%, so the inline Args block carries the semantic weight. It explains that tag is the tag name and lang is an ISO 639 alpha-2 language code for the description. It does not explicitly mention that lang is optional, but the schema's default null provides that information.

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 a specific verb ('Get') and a specific resource ('a tag's description, total uses and reach'), making the tool's function immediately clear. The sibling list confirms it is distinct from tag-related list tools like get_tag_top_artists and get_similar_tags, so an agent can select it without 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?

The description clearly indicates this is for fetching tag metadata rather than tag-related charts or similar tags. It does not explicitly state when not to use it or name alternatives, but the scope is obvious enough that an agent can infer the right 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds the behavioral detail of 'most associated' ranking, but does not disclose additional traits like pagination limits, case sensitivity, or result format. This is adequate but 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 compact and front-loaded with the action, followed by a brief args list. There is no filler or repetition; every sentence contributes 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?

Given the output schema exists and annotations cover safety, the description is mostly complete for calling this simple read-only tool. It explains purpose and all parameters. It lacks usage context or clarifications about edge cases, but nothing critical is missing for basic invocation.

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 0%, so the description carries the parameter documentation burden. It provides clear one-line meanings for all three parameters: tag name, results per page, and page number. It makes up for the schema gap, though it does not specify ranges or formatting constraints.

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 and resource: 'Get the albums most associated with a tag.' It differentiates from sibling tools like get_tag_top_artists and get_tag_top_tracks by specifying albums. The purpose is 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?

The description implies usage when a tag's top albums are needed, but it does not explicitly mention alternatives or when not to use it. No exclusions or comparisons to sibling tag tools are provided.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds only the ranking concept 'most associated' and pagination parameters, but does not disclose ordering details, potential empty results, or behavior when the tag is unknown. This is adequate but lacks richer behavioral context.

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 minimally sized and front-loaded with the core purpose before the parameter list. Every line earns its place, with no filler or repetition of the schema defaults.

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 read-only listing tool with only three parameters, an output schema, and strong annotations, the description is complete enough for an agent to invoke it correctly. The required tag parameter is identified, pagination is explained, and the output schema covers return-value 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 description coverage is 0%, so the description must carry the parameter semantics. It provides a brief but meaningful gloss for all three parameters: 'tag' as the tag name, 'limit' as results per page, and 'page' as which page to fetch. The definitions are not deep, but they cover every parameter and add value beyond the raw 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 explicitly names the verb 'Get' and the resource ('artists most associated with a tag'), which clearly distinguishes it from sibling tools like get_tag_top_albums or get_user_top_artists. The tag scope is front and center, so an agent can tell what this tool does at a glance.

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?

There is no explicit guidance about when to use this tool versus alternatives such as get_chart_top_artists or get_user_top_artists. The intended context is only implied by the description, and no exclusions or preferred-use conditions are stated.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no notable behavioral traits beyond 'most associated with a tag' and does not disclose rate limits, auth needs, or ranking behavior, but it does not contradict the annotations.

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 one-sentence purpose is front-loaded and the Args list is compact and free of filler. It is slightly redundant with the schema property titles, but the added per-parameter explanations justify the 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 read-only, idempotent tag lookup with a simple three-parameter schema and an output schema, the description covers the core invocation details: what is returned and how pagination works. The absence of usage-vs-sibling guidance is the main gap, but that is already scored separately.

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 0%, so the Args section is the only parameter documentation. It clarifies that tag is the tag name, limit controls results per page, and page selects which page to fetch, which is enough for basic invocation. It does not explain defaults, ranges, or ordering 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 first sentence states a specific verb and resource: 'Get the tracks most associated with a tag.' The phrase 'most associated with a tag' scopes the operation to tag-derived rankings and distinguishes it from sibling top-track tools that are user-, chart-, artist-, or geo-based.

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?

There is no guidance on when to use this tool versus alternatives such as get_chart_top_tracks, get_user_top_tracks, get_artist_top_tracks, or get_tag_top_albums. No exclusions, preconditions, or alternative routing are provided.

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?

Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, which already signal a safe, non-destructive, and possibly cacheable operation. The description adds little beyond restating the purpose; it doesn't mention pagination, response size, or any edge cases (e.g., empty list if no charts exist). Given the annotations cover safety, the description's transparency is adequate but not enhanced.

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 concise, front-loading the main purpose in the first line. The parameter documentation is minimal but structured as a list. There are no wasted words; however, the parameter description is overly terse and repeats the schema's property name without adding 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?

The tool is simple (one parameter, no nested objects), and the annotations and output schema likely provide sufficient information about return values. The description clearly states the return concept (week ranges) and the parameter. For such a simple tool, the description is adequate, though it could benefit from mentioning that it might return an empty list for unknown tags.

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 0%, meaning the description is the only source for parameter semantics. However, the description merely states 'tag: The tag name.' without adding any details like format (e.g., URL-encoded, case sensitivity) or examples. It doesn't compensate for the lack of schema descriptions, which is a significant gap for a purely tag-based query.

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's purpose: to get the week ranges for which a tag has weekly charts. It specifies the resource (tag) and the action (get week ranges), which is reasonably specific. However, it doesn't explicitly differentiate from the similarly named sibling get_user_weekly_chart_list, but the tag vs user context 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that sibling tools like get_tag_top_artists or get_user_weekly_chart_list might be more appropriate for other needs, nor does it explain typical use cases or prerequisites (e.g., tag must exist).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scoping ('across all of Last.fm') but does not disclose response ordering, limits, or aggregation details beyond what the output schema likely provides.

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 is immediately informative, front-loads the action and resource, and contains no filler or repetition.

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 no-parameter read-only tool with an output schema and full annotation coverage, the description is complete enough for an agent to select and invoke it correctly. The global scope is clearly stated, and no additional prerequisites or side effects need disclosure.

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 tool has zero parameters, so the description does not need to explain parameter meaning. The baseline of 4 applies because there is no parameter burden for the agent.

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 a specific verb ('Get') and resource ('tags used most') and clarifies the scope as 'across all of Last.fm,' distinguishing it from user-specific and chart-specific siblings like get_user_top_tags and get_chart_top_tags.

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 phrase 'across all of Last.fm' provides clear context for when to use this global aggregate tool rather than user- or tag-scoped alternatives. However, it does not explicitly state when not to use it or name 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds little beyond autocorrect behavior and lookup semantics, but it does not contradict the annotations and is adequate for a simple read-only fetch.

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 purpose is front-loaded in a single clear sentence, followed by a compact Args block with no filler. Every sentence adds useful information and the structure 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?

With an output schema present, return-value details do not need to be repeated. The description covers purpose and all parameter semantics sufficiently for a read-only lookup; the main gap is explicit usage guidance relative to sibling tools, but that is not required 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 0%, so the description must carry parameter semantics, and it does. It explains artist/track requiredness unless mbid is given, identifies mbid as a MusicBrainz ID, notes username includes playcount/loved status, and clarifies autocorrect behavior.

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?

States a specific verb ('Get') and resource ('track metadata'), followed by a concrete list of returned fields: duration, listeners, playcount, album, tags, wiki. This clearly differentiates it from sibling track tools like get_track_correction or get_track_tags.

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 gives parameter-level guidance such as artist/track required unless mbid is given, but provides no explicit statement of when to choose this tool over related track or user lookup tools. No alternatives or exclusions are named.

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?

Annotations already cover readOnly/openWorld/idempotent/non-destructive, so the description only needs to add behavioral context. It adds the core behavior (returns canonical spelling for a misspelled query) but does not disclose edge cases such as what happens when no correction exists. 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.

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

The description is two sentences plus a clean argument list with no filler or redundancy. The purpose is front-loaded, and each line 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?

For a simple read-only, two-string-parameter lookup with an output schema and rich annotations, the description covers the essential intent and input semantics. No additional return-value explanation is necessary because an output schema exists.

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 0%, so the description bears the responsibility for parameter meaning. The 'as written' clarifications for artist and track add real semantic value beyond the bare schema property names, though they are terse and lack examples.

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?

States a specific verb ('Get'), resource ('Last.fm's canonical spelling'), and domain ('misspelled artist and track'). The wording clearly differentiates from sibling get_artist_correction by requiring both artist and track, so agents can select the right correction endpoint.

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?

Implies use when an input has a non-canonical spelling and a canonical version is needed, and the argument labels 'as written' reinforce that. However, it never explicitly contrasts with get_artist_correction or other track retrieval siblings, and there is no 'when not to use' 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context beyond the annotations: the user defaults to the authenticated account, and autocorrect lets Last.fm fix misspelled names. No contradiction with annotations exists.

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 concise and well-structured: a clear one-sentence summary followed by a compact argument list. Every line adds necessary information, and the conditional requirements are communicated without unnecessary prose.

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 output schema exists and the annotations cover safety traits, the description is complete for practical invocation. It explains all parameter roles, the mbid-or-name tradeoff, the authentication default, and autocorrect behavior, so an agent can call this tool correctly without guessing.

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?

With 0% schema description coverage, the description carries the full burden for parameters, and it does so thoroughly. Each of the five parameters is explained with meaningful semantics, including the conditional requirement linking artist/track to mbid, the default for user, and the meaning of autocorrect.

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 and resource: 'Get the tags one user applied to a track.' This precisely identifies what the tool does and naturally distinguishes it from get_track_top_tags, which would return aggregate top tags rather than one user's applied tags.

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 clearly establishes context: it reads a specific user's tags on a track, which is distinct from the many top-tag or tag-search siblings. It also gives concrete parameter usage rules like 'Required unless mbid is given,' but it does not explicitly name alternatives or state when not to use this tool.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond annotations by specifying that results are community-sourced and ordered by popularity, which helps set expectations about the data returned.

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 front-loaded with the core purpose in one sentence, followed by a compact and scannable Args list. Every component earns its place; there is no redundant wording or 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?

The description fully explains the input parameters and their relationships, and there is an output schema available so return values do not need to be described. Given the read-only, idempotent nature and moderate complexity, nothing critical is missing for an agent 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 descriptions are completely absent (0% coverage), but the description's Args section fully documents each parameter, including the conditional requirement relationship: artist and track are required unless mbid is given, autocorrect is explained, and mbid is identified as a MusicBrainz ID. This compensates entirely for the schema gap.

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 ('Get') and resource ('the tags the community applied to a track, by popularity'), which clearly defines the tool's purpose. It differentiates from sibling tools like get_track_tags by noting 'community' and 'by popularity', making its scope distinct.

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 phrase 'community applied' and 'by popularity' clearly indicates this is for community tag data rather than user-specific tags, providing useful context for selecting this tool over get_track_tags or get_user_top_tags. It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide an informed agent.

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?

Annotations already cover read safety (readOnlyHint, idempotentHint, non-destructive), so the description adds value by explaining that user defaults to the authenticated account and that recenttracks enriches the response. It does not disclose auth requirements, rate limits, or error behavior, but these are less critical given the strong annotation coverage.

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 one-line purpose followed by a compact Args block. Every sentence contributes operational detail, and there is no fluff or repetition of schema 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 read-only tool with annotations and an output schema, the description is complete: it covers purpose, all parameters, defaults, pagination, and the one optional behavior flag. Nothing essential for invoking the tool correctly is 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 description coverage is 0%, so the description carries the full burden for parameter meaning. It documents all four parameters in plain language: user scope, pagination fields, and the recenttracks enrichment flag. It does not give constraints like ranges, but the schema provides types and defaults.

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 and resource: 'Get a user's friends.' This distinguishes it from sibling tools that fetch tracks, albums, tags, or charts, though it does not explicitly call out any sibling alternative.

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?

There is no guidance on when to use this tool versus the 54 sibling get_* tools, nor any mention of exclusions or alternative tools. The argument defaults are helpful, but the agent must infer when this is the right choice from the name alone.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the default behavior of the user parameter, which is valuable. However, it does not mention any authentication requirements or potential errors, which for a read-only profile fetch is a minor gap.

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 extremely concise—two lines with a clear subject-verb-object structure and a parameter definition. The purpose is stated first, and the argument is explained directly after. No wasted words or 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?

The output schema exists, so return values are already documented. The description confirms the fields (playcount, registration date, country, subscriber) and the default parameter behavior. For a simple read operation with one optional parameter, nothing critical is missing. A small omission is the lack of mention of how the 'user' is specified (username vs. ID), but this is minor.

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 0%, so the description must compensate. It does: 'user: Whose profile to read. Defaults to the authenticated account.' This clearly explains the parameter's meaning, its optional nature, and the default behavior. For a single parameter, this is sufficient.

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 fetches a user's profile and lists specific fields (playcount, registration date, country, subscriber). This distinguishes it from sibling tools like get_user_recent_tracks, which focus on other aspects. The verb 'Get' and resource 'user's profile' 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?

The description does not provide guidance on when to use this tool versus the many sibling get_user_* tools. It only mentions the default behavior (defaults to authenticated account), but offers no explicit context or exclusions. For example, it doesn't state that other tools are for recent tracks or loved tracks.

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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the 'most recent first' ordering and the default-to-authenticated-user behavior, which are not visible in annotations or schema. 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.

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

The description is concise and front-loaded with the core purpose, followed by a compact Args list. Every sentence adds value, and the readable multi-line format keeps the parameter semantics scannable.

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 read-only paginated list tool with an output schema present and rich annotations, the description covers the essential aspects: resource, ordering, defaults, and pagination. Nothing critical is missing for an agent to select and invoke this 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 coverage is 0%, so the description carries full responsibility for parameter meaning. It explains user ('Whose loved tracks to read. Defaults to the authenticated account.'), limit ('Results per page'), and page ('Which page of results to fetch'). This fully compensates for the schema's lack of 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 states a specific verb ('Get') and a clear resource ('the tracks a user has loved') with ordering ('most recent first'). This cleanly differentiates it from sibling tools like get_user_recent_tracks or get_user_top_tracks without needing to open the schema.

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 intended use is clear: read a user's loved tracks with pagination and a default to the authenticated account. It does not explicitly name sibling alternatives or state when not to use it, but the resource name 'loved tracks' makes the usage context unambiguous.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a default for the 'user' parameter (authenticated account) but does not disclose pagination behavior, rate limits, or the exact response format. Given the annotations, this is adequate but not rich; it meets the minimum bar without adding significant behavioral context.

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, purposeful sentence followed by a clean parameter list. There is no filler or redundancy. The primary action is front-loaded, and each line adds value, making it highly efficient for an agent 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?

For a read-only tool with 5 parameters and an existing output schema, the description covers the purpose and all parameters clearly. It does not mention edge cases or prerequisites, but given the annotations and output schema, it is reasonably complete. The lack of any note about how 'everything' is paginated (limit/page) is slightly missing, but the parameters themselves imply it.

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?

With 0% schema coverage, the description fully compensates by explaining all five parameters: tag, tagging_type, user, limit, and page. It gives meaningful descriptions (e.g., 'What was tagged -- artist, album or track') that clarify the schema's bare titles. However, it does not provide enums or constraints (e.g., valid values for tagging_type beyond the examples) or elaborate on pagination, so it is strong but not exhaustive.

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's action ('Get everything a user tagged with one tag') and identifies the resource (user's tagged items) and the filter (one tag). It distinguishes itself from global tag tools like get_tag_top_* by explicitly mentioning 'a user tagged', but it does not directly reference sibling tools, so it loses a point for not being more explicit about differentiation.

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?

There is no guidance on when to use this tool versus alternatives. The description only explains the purpose and parameters; it does not mention that this is for personal tags as opposed to global tags, nor does it suggest conditions for choosing it over get_tag_top_* or get_*_tags tools. The usage context is only implied by the parameter list.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: results are ordered most-recent-first, a currently playing track appears first with a nowplaying flag and no play date, and the user defaults to the authenticated account. This goes beyond the schema and enriches the agent's expectation of output and side effects.

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 well-structured: a concise opening statement, a brief usage gloss, a key behavioral note, and an organized Args block. The 'This is the tool for' sentence adds slight redundancy with the first sentence but is short and reinforces usage. Every sentence earns its place; the structure is front-loaded and scannable.

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?

With 6 optional parameters, an output schema, and safe read-only annotations, the description covers all necessary usage: ordering, nowplaying flag, pagination (limit, page), time filters, extended flag, and default user. It does not need to explain return values because an output schema exists. No critical operational detail is missing for correct invocation.

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 0% (no descriptions in the schema), so the description must fully explain parameters. It does: each parameter in the Args list has a clear, concise explanation (e.g., user: 'Whose history to read. Defaults to the authenticated account.'; extended: 'Also return artist images and whether you loved each track.'). It also specifies the maximum limit value (200). No parameter is left ambiguous.

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 clear verb-resource pair: 'Get a user's listening history, most recent first.' It then adds a user-oriented gloss ('what have I been listening to') and a specific ordering detail (nowplaying flag first). This unambiguously distinguishes it from siblings like get_user_loved_tracks and get_user_top_tracks, which serve different 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?

The phrase 'This is the tool for...' gives strong contextual guidance on when to use it, and the note about the nowplaying flag clarifies a key behavioral nuance. It does not explicitly list exclusions or name alternative tools for related queries (e.g., loved tracks), but the purpose is clear enough that an agent can route correctly without confusion.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context that the user defaults to the authenticated account and enumerates allowed periods, but it does not reveal additional behavioral traits such as pagination limits or sort algorithm details.

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 concise and front-loaded with a one-sentence summary, followed by a clean Args block. Every sentence adds value, with no redundant 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?

For a simple, read-only list tool with an output schema, the description covers all input parameters and their semantics. The output schema handles return values, and annotations cover safety, making the description complete enough for an agent to call 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 0%, but the description compensates fully by explaining every parameter: user defaults to the authenticated account, period lists all valid values, limit is results per page, and page indicates which page to fetch. This adds substantial meaning beyond the raw 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 clear action and resource: 'Get a user's most played albums over a period.' It distinguishes from sibling tools like get_user_top_tracks or get_user_top_artists by naming 'albums' explicitly, though it does not directly reference 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?

Usage context is implied: this tool is for reading a user's most played albums within a time period. However, it does not explicitly state when to prefer this over get_user_top_tracks, get_user_recent_tracks, or other siblings, nor does it provide exclusions.

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?

Annotations already convey read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context beyond that, such as 'Defaults to the authenticated account' and the pagination semantics for limit and page. No contradiction exists.

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 concise: a one-sentence summary followed by a compact Args block. Every line contributes necessary information, and the main purpose is front-loaded with 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?

For a read-only 4-parameter tool with an output schema and strong annotations, the description covers the essential invocation details: user default, period choices, and pagination. Nothing needed to call it correctly is 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 description coverage is 0%, but the description fully compensates by explaining each parameter: user's default, the allowed period values, limit as results per page, and page as which page to fetch. This is meaningful guidance beyond the bare 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 opens with a specific verb and resource: 'Get a user's most played artists over a period.' It explicitly names 'artists', which distinguishes it from sibling tools like get_user_top_albums, get_user_top_tracks, and get_user_top_tags.

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 gives no guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference siblings such as get_user_top_tracks or get_chart_top_artists. The use case is implied by the name and wording, but not explicitly compared.

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?

Annotations already declare this as read-only, idempotent, non-destructive, and open-world, so the bar is lower. The description adds the default-user behavior, which is useful beyond the schema, but doesn't disclose additional behavioral traits such as ordering guarantees beyond 'most'.

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 short, front-loaded with the core purpose, and uses a clean Args block with no filler. Every sentence 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?

For a two-parameter read-only tool with an output schema, the description covers the essentials: what is returned conceptually and both parameter roles. It could mention ordering/ranking semantics more explicitly, but 'most' plus the output schema cover most of the needed context.

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 input schema has no property descriptions (0% schema coverage), but the description compensates by explaining both parameters: 'user' determines whose tags are read and defaults to the authenticated account, and 'limit' controls count. This adds real semantic value over the bare 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 uses the verb 'Get' with the specific resource 'tags a user uses most', which is clear and distinguishable from the sibling tools. It doesn't explicitly name a sibling alternative, so it loses the last point on differentiation.

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 is provided about when to choose this tool over similar siblings like get_user_personal_tags or get_top_tags. The only context is parameter-level ('Defaults to the authenticated account'), not tool-selection 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the period options and default user behavior ('Defaults to the authenticated account'), which is useful. However, it does not disclose pagination behavior, rate limits, or what happens when the user is not found. With annotations covering the core safety traits, a 3 is appropriate.

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 compact and front-loaded with the core purpose in the first sentence. The parameter list is terse and scannable. It earns a 4 because it is efficient, though the parameter explanations are slightly repetitive of the schema names.

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 an output schema, so return values are covered elsewhere. The description covers the main parameters and the default user behavior. However, it does not mention pagination behavior, error cases, or how 'overall' period differs from the others. For a read-only list tool with an output schema, this is adequate but not 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 description coverage is 0%, so the description must compensate. It does explain all four parameters: user, period, limit, page. However, the explanations are minimal—'Results per page' and 'Which page of results to fetch' add little beyond the schema's names and defaults. The period values are enumerated, which is helpful, but the description does not clarify the meaning of 'overall' or the exact format of the user parameter. Baseline 3 is fair.

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 a user's most played tracks over a period.' This clearly distinguishes it from siblings like get_user_recent_tracks (recent, not top) and get_user_top_artists (artists, not tracks). It could be slightly stronger by explicitly naming a sibling, but the core purpose is 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?

The description implies usage context: it is for reading a user's top tracks over a period, with period options listed. However, it does not explicitly state when to use this tool versus alternatives like get_user_recent_tracks or get_user_top_albums. The 'period' parameter explanation gives some context, but no direct when/when-not guidance is provided.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond this by explaining default behaviors (user defaults to authenticated account, timestamps default to most recent week) and the source of timestamp values (get_user_weekly_chart_list). It does not contradict any annotations and provides context that helps an agent understand expected behavior. It does not disclose error handling or response specifics, but the output schema covers that, so the description's additions are sufficient.

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 concise and well-structured: a one-line purpose followed by a clear list of arguments with explanations and defaults. It front-loads the purpose and avoids filler. Every sentence earns its place, and the formatting is easy to scan. This is an exemplary level of efficiency.

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 read-only nature (annotations) and the presence of an output schema, the description covers everything needed to invoke it correctly. It explains the purpose, all parameters, defaults, and the dependency on get_user_weekly_chart_list. There are no missing critical details for an agent to call this tool. The output schema handles return values, so no description is needed there. This is complete for its complexity.

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 0%, so the description must compensate. It does so excellently: each parameter is explained with its purpose and default. 'user' is described as 'whose chart to read' with a default to the authenticated account; 'from_timestamp' is described as 'week start, from get_user_weekly_chart_list' with a default to the most recent week; 'to_timestamp' is described as 'week end, from get_user_weekly_chart_list'. This fully clarifies the semantics beyond the bare schema, which only lists types and null defaults.

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 the specific action: 'Get a user's album chart for one week.' It clearly identifies the resource (user's album chart) and the time scope. It distinguishes from sibling tools like get_user_weekly_artist_chart and get_user_weekly_track_chart by the word 'album' in the description, aligning with the tool name. However, it doesn't explicitly elaborate on what the chart contains beyond the name, so it's clear but not exceptionally detailed.

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 helpful context for when to use this tool: it references get_user_weekly_chart_list for valid timestamps, implying a workflow where the list is fetched first. It also clarifies defaults (authenticated user, most recent week). It does not explicitly mention alternatives or exclusions (e.g., 'use this for album charts, use get_user_weekly_artist_chart for artist charts'), but the tool's name and the description's 'album chart' phrase make the distinction obvious. This is clear context with only a minor omission of explicit alternative routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the defaulting behavior (user defaults to authenticated account, from_timestamp defaults to most recent week), which is useful. It doesn't describe pagination or return format, but the output schema exists and the annotations carry the safety burden.

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 compact and front-loaded with the core purpose in the first sentence. The parameter explanations are brief and useful. It could be slightly more structured, but it earns its place with no wasted words.

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 read-only, idempotent tool with an output schema and only 3 optional parameters, the description covers the essential context: what it returns, how to get the week range, and the defaults. The main gap is not specifying the timestamp format, but the reference to get_user_weekly_chart_list mitigates that. Overall, an agent has enough to call this 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 0%, so the description must compensate. It does explain the meaning of user, from_timestamp, and to_timestamp, including that timestamps come from get_user_weekly_chart_list. However, it doesn't specify the timestamp format (e.g., Unix seconds) or the exact relationship between from and to beyond 'week start' and 'week end'. This is adequate but not rich.

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 ('Get') and resource ('user's artist chart for one week'), which clearly distinguishes it from sibling tools like get_user_weekly_album_chart and get_user_weekly_track_chart. It doesn't explicitly name those siblings, but the resource is specific enough that an agent can infer the distinction.

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 explains that from_timestamp and to_timestamp come from get_user_weekly_chart_list, which provides clear context on how to obtain the week boundaries. It also states defaults for user and from_timestamp. However, it doesn't explicitly say when to use this tool versus alternatives like get_user_weekly_track_chart, though the resource name makes that fairly clear.

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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context about the return format (from/to Unix timestamp pairs) and the default behavior for the 'user' parameter (defaults to authenticated account). This goes beyond the annotations without contradicting them, covering the essential behavioral aspects of the operation.

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 extremely concise—two short paragraphs. The opening sentence states the core function, the second explains the output format, and the Args section defines the parameter. No filler or redundancy. It is well-front-loaded with the primary 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?

For a simple read-only tool with one optional parameter, the description covers all necessary elements: purpose, output structure (from/to timestamps), and parameter semantics. Since an output schema exists (though not shown), the description doesn't need to detail return values beyond what it does. The tool's role as a helper for chart tools is clear, making it complete for an agent to invoke 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 0%, so the description must carry all parameter explanation. It does: 'Whose chart list to read. Defaults to the authenticated account.' This fully explains the single 'user' parameter, including its optionality and default. No further clarification is needed.

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's purpose: 'Get the week ranges a user has weekly charts for.' It specifies the resource (user's weekly chart availability) and the action (get week ranges). It also distinguishes itself from sibling chart tools by noting the output is to be 'passed to the weekly chart tools,' making it a helper rather than a chart-data tool.

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 explicitly says the output is to be used as input to the weekly chart tools, implying the intended usage pattern (get ranges first, then fetch charts). It does not explicitly mention alternatives or when not to use, but the tool's niche is clear from its name and the stated purpose. Sibling tools like get_user_weekly_track_chart would be used after this, which is a reasonable inference.

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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds valuable behavioral detail about defaulting to the authenticated account and the most recent week, which goes beyond what annotations provide. 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.

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

The description is compact and front-loaded with the core purpose, followed by a concise argument list. Each sentence provides necessary information without redundancy or 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 the tool's simplicity, the presence of an output schema, and comprehensive annotations, the description covers all necessary operational context: purpose, parameter meanings, defaults, and where to obtain timestamp values. Nothing essential is 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?

The input schema provides no descriptions (0% coverage), but the description thoroughly explains each parameter: user identifies whose chart, and from/to_timestamp are week boundaries sourced from get_user_weekly_chart_list, with defaults clearly stated. This fully compensates for the schema's lack of documentation.

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 the specific verb 'Get' and the precise resource: a user's track chart for one week. It clearly distinguishes from sibling weekly artist/album charts by specifying 'track' and 'one week'.

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?

Defaults for user and timestamps are provided, and the description points to get_user_weekly_chart_list as the source of week boundaries, giving useful context. However, it does not explicitly state when to prefer this tool over alternatives like get_user_recent_tracks or get_user_weekly_artist_chart, leaving tool selection to inference.

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?

Annotations already convey that the operation is not read-only, is idempotent, and is not destructive. The description adds the useful requirement that authentication is needed, but it does not disclose side effects on the user's loved-tracks collection or clarify that the action can be reversed with unlove_track.

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 short and front-loaded with the core action in the first sentence. The Args section is terse despite being partially redundant with the input schema, and the authentication note is a worthwhile addition.

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 two-parameter mutation with annotations already covering idempotence and destructiveness, the description is mostly complete: it states the action and the key prerequisite of authentication. It could be more complete by mentioning the current authenticated user's library is modified, but that is reasonably implied.

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 0%, so the description must clarify the parameters. It adds the minimal useful detail that artist is 'Artist name' and track is 'Track name,' helping distinguish names from IDs. However, it does not explain matching behavior, formatting requirements, or how these values relate to the authenticated user.

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 ('Mark') and resource ('a track') with the result ('as loved'), making the intent immediately clear. It also naturally distinguishes this tool from the sibling unlove_track and read-only tracking tools like get_user_loved_tracks, even though those alternatives are not explicitly named.

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 only guidance is 'Needs authentication,' which is a prerequisite rather than a usage rule. There is no mention of when to choose this over alternatives such as unlove_track or add_track_tags, nor any exclusion criteria or pairing 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?

The description adds the important behavioral requirement of authentication and clarifies that only the caller's own tags are affected, beyond what the annotations already indicate about destructiveness. It does not detail side effects like what happens if the tag does not exist, but the destructive and idempotent hints cover much of the behavioral profile.

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 compact and front-loaded, stating the core action in the first sentence and following with a concise parameter list. No words are wasted.

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 three-parameter mutation tool with annotations covering destructive, idempotent, and non-read-only behavior, the description is largely complete. It adds authentication and user-scope context. It does not describe response details or error conditions, but an output schema is present and complexity is low.

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 0%, so the description must compensate. It provides a brief semantic for each parameter: artist name, album name, and the single tag to remove. This clarifies the basics but does not add format details, constraints, or edge-case behavior.

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 the specific action 'Remove', the object 'one of your tags', and the target resource 'from an album', making the tool's purpose immediately clear. It is easily distinguished from sibling tools like remove_artist_tag and remove_track_tag.

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 purpose itself implies when to use the tool: whenever a user wants to remove their own tag from an album. However, it does not explicitly mention alternatives, such as remove_artist_tag or remove_track_tag, nor does it state when not to use this tool.

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