Server Quality Checklist

Tool Scores

• listening_find_dormantB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions it makes '2 llamadas a MusicBrainz por artista' indirectly through the parameter description of with_art, disclosing rate-limit behavior (1 req/seg), which is useful transparency. However, the main description does not disclose data freshness, whether it's read-only, or scope limitations beyond what the parameter hints at.

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

  Conciseness4/5

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

  Two concise sentences that efficiently communicate purpose and use case, with engaging marketing-oriented framing. No wasted words, though the description could have used the space to add more operational detail given it's the only narrative text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is moderately complex with 3 parameters documented in the schema, and the description provides strong conceptual framing for the use case. Given that parameter semantics are handled by the schema, the description focuses on the 'why' which it does well. No output schema exists, so return format isn't documented, but the tool's purpose implies a list of artists. With no annotations, slightly more behavioral context would be ideal, but overall complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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, but each parameter already has a meaningful description in the schema itself (limit, with_art with MusicBrainz rate limits, min_dormant_years). The description reinforces the tool's intent but doesn't add semantic detail about parameters beyond what the schema already provides. Since the parameters are self-documenting, the description's minimal contribution is acceptable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly defines the purpose: finding artists that were listened to attentively (high completion, several themes) and then abandoned for X years. It uses specific verbs and criteria ('escuchados con atención', 'abandonados hace X años') that distinguish this from a generic search tool. However, it doesn't explicitly differentiate from siblings beyond the operational criteria.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description conveys implied usage context ('el lead clásico de lo probé, me gustó, corté el hábito') which hints at a marketing/retention use case. However, it doesn't explicitly state when to use this vs alternatives like listening_query, nor when NOT to use it. The guidance is contextual but not explicitly comparative.

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

• listening_year_in_reviewB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full behavioral burden. It does not disclose whether this is read-only, the output format, rate limits, or auth requirements. The with_art parameter description (in schema) reveals rate-limit info, but the main description doesn't disclose behavioral characteristics like return shape or 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.

  Conciseness5/5

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

  Two short sentences with zero waste. Front-loaded with the core purpose then immediately a usage rationale. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a relatively simple tool (a year-based top-artists query) with no output schema and no annotations, the description is somewhat lean. It doesn't describe return values, ordering guarantees beyond minutes, or how pagination/limit works. The with_art parameter in schema adds useful latency context, but the description itself is incomplete for a data-read tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 description mentions 'minutos escuchados' and 'temas distintos' which adds meaning about what the tool computes, but doesn't elaborate on the parameters (year format, limit semantics, with_art behavior). It partially compensates but leaves gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it returns top artists of a specific year by minutes listened with distinct tracks. The verb 'Top...por minutos escuchados' is specific and the resource (artists per year) is clear. It doesn't explicitly distinguish from siblings like listening_top_albums, but the year-based scope is fairly distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description provides use context ('Para ver qué dominó tu año o comparar la evolución entre años') which implies when to use it, but it doesn't explicitly exclude alternatives or note comparable sibling tools. The use case is implied rather than exhaustively stated.

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

• listening_expand_artistA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal rate-limit implications via the with_art parameter note (2 calls per candidate at 1 req/seg), which is useful. But the description itself doesn't disclose side effects, data source freshness, what happens with unknown artists, or response shape. For a tool making external API calls with real behavioral constraints, this is a significant gap.

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

  Conciseness4/5

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

  The description is a compact two-sentence block in Spanish that states purpose and use case efficiently. It front-loads the core function and adds the practical value proposition. Slightly verbose phrasing but no wasted sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and 0% schema coverage at the top level, the tool requires more context than provided. The with_art schema description helps with rate-limit awareness, and the overall purpose is clear. But missing details like response format, error cases for unknown artists, and explicit alternatives among siblings leave gaps for an agent deciding when and how to invoke this.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for parameter meaning. The with_art parameter description in the schema adds meaningful behavior (rate-limit trade-off, faster response without images), and include_labels explains the precision/recall trade-off. However, the tool description itself doesn't mention parameters at all; the semantic value comes from the schema parameter descriptions rather than the main description. With 0% coverage and 1 required param, this lands between baseline 3 and higher.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Expande') and resource ('artista semilla vía MusicBrainz'), naming the mechanism (members, collaborators, optionally label-mates) and the goal (finding new music connected to what one already likes). It distinguishes itself somewhat from siblings by emphasizing MusicBrainz expansion vs Spotify algorithms, though the sibling differentiation isn't explicit by name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description conveys when to use it ('para encontrar música nueva conectada a lo que ya te ha convencido... no solo lo que el algoritmo de Spotify sugiere'), giving clear context for the use case. However, it doesn't explicitly state when NOT to use it or name alternative sibling tools like listening_artist_profile or listening_query.

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

• listening_artist_profileA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of disclosing behavior. It describes WHAT fields are returned but doesn't disclose whether this is a read-only operation, performance characteristics, what happens if the artist has no listening data, or how the 'convicción' score is computed. For a data-retrieval tool with zero annotation coverage, this is a notable gap.

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

  Conciseness5/5

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

  Single, dense sentence that front-loads the core purpose ('Perfil de escucha completo de un artista') and then enumerates the returned fields efficiently. Zero waste, no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has a simple input (1 string param), so the description is largely sufficient. However, no output schema exists, and the description only partially enumerates expected returns. It covers the key fields well enough for an agent to understand what it will receive, though edge-case behavior (empty data, unknown artist) is undocumented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but there's only a single 'artist' parameter whose meaning is self-evident. The description lists the rich output fields (plays, minutes, tracks, top album cover) which effectively compensates for the lack of schema documentation. With just one simple parameter, the description's value-add is adequate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clear purpose: 'Complete listening profile of an artist' listing specific fields (plays, minutes, distinct tracks, albums explored, time range, conviction score, cover art of top album). The verb 'Profile de escucha completo de un artista' is specific and distinguishes this from siblings like listening_top_albums or listening_query.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies this is for getting a comprehensive single-artist listening summary. However, no explicit guidance is given on when to choose this over siblings (e.g., listening_expand_artist for artist relationships, listening_query for flexible queries). The distinction from siblings is implicit rather than stated.

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

• listening_top_albumsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. The description discloses the tool returns albums with total minutes and play counts, which is useful. However, it doesn't disclose rate-limit behavior, pagination, or data freshness characteristics. The with_art parameter hints at MusicBrainz calls (in schema), but the description doesn't elaborate on behavioral nuances beyond grouping.

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

  Conciseness4/5

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

  Two concise sentences, clean and front-loaded. It states purpose first, then eliminates confusion with the sibling. The Spanish language is used consistently. Could arguably be a 5 but the with_art caveat about MusicBrainz rate limits lives only in the schema, not reinforced in the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, so the description should explain what the return value looks like. It mentions 'minutos totales' and play counts but doesn't detail the output structure (artists included, album names, ordering). For a tool with no output schema and no annotations, some additional return-format details would help. The sibling differentiation is strong, mitigating the gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description should compensate. However, the description itself doesn't explain the parameters. The schema does document limit (default 15) and with_art (including the MusicBrainz rate-limit caveat), so the parameter semantics are well covered by the schema itself. The description adds no additional parameter meaning beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it returns top albums by play count with total minutes, and explicitly distinguishes itself from listening_year_in_review which groups by artist. It even gives the use case verbatim (''qué disco he escuchado más''). Specific verb+resource+scope with sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description contrasts this tool against listening_year_in_review, giving clear guidance on when to use which (by album vs by artist). However, it doesn't mention other siblings like listening_query or listening_expand_artist, or state explicit conditions for choosing this tool over them.

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

• listening_queryA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It explicitly states it is read-only ('solo lectura') and that it rejects non-SELECT queries, which are critical safety and execution behaviors. The description also gives performance/usage context by pointing to listening_schema as a prerequisite. It doesn't describe return format, but the output schema exists to cover that.

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

  Conciseness5/5

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

  Two concise sentences with zero waste. The first states the core purpose (read-only SQL query against listening history), and the second provides a critical constraint (rejects non-SELECT). Every word earns its place; the Spanish language is efficient and direct.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 1-parameter tool with an output schema, the description is largely complete. It covers the purpose, the critical constraint (SELECT-only), and points to the prerequisite schema tool. The output schema handles return-values documentation, so the description doesn't need to. Minor gap: it doesn't mention error behavior beyond rejection, but this is adequately implied by the SELECT constraint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but there's only 1 parameter (sql) which is self-evident. The description confirms the SQL must be SELECT, adding the only meaningful behavioral constraint beyond the raw schema. The schema itself also provides the helpful note about using listening_schema first, which partially compensates for low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it executes a read-only SQL query against the listening history, using a specific verb (ejecuta) and resource (historial de escucha). It distinguishes itself from siblings like listening_find_dormant and listening_expand_artist, which are more specific analytical tools, by being a general-purpose SQL query interface.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

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

  The description states the tool is read-only and rejects anything not starting with SELECT, which gives clear constraints. It also references listening_schema as a prerequisite companion tool ('Usa listening_schema antes si no conoces las columnas'), providing context on when it's appropriate to use. However, it doesn't explicitly exclude alternatives like the sibling analytical tools beyond the implied read-only distinction.

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

• listening_schemaA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. However, this is a read-only schema inspection tool with zero parameters and no obvious side effects, so behavioral disclosure is minimally necessary. The description adds the 'call first' context which implies a safe, non-mutating operation.

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

  Conciseness5/5

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

  Two short, focused sentences with zero waste. The first states the purpose, the second gives usage guidance. Perfectly front-loaded and appropriately sized for a no-parameter introspection tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given there's an output schema (which takes care of documenting return structure), no parameters, and a simple, clear purpose, the description is largely complete. The guidance to call first when writing SQL provides key context. Slight gap: doesn't explain what the schema output looks like, but the output schema compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% (trivially, since there's nothing to document). With 0 parameters, the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb (Devuelve/Returns) and specific resource (database schema with tables and columns). It's unambiguous and distinguishes the schema tool from the other sibling query/analysis tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  The description explicitly states when to use it: 'Llama esto primero' (call this first) whenever writing SQL by hand with listening_query. This provides direct, actionable guidance for tool selection.

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