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

With no annotations, the description carries the full burden. It implies a read-only operation but does not explicitly state that no modifications occur or describe side effects. Minimal transparency.

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

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

The description is a single concise sentence, efficient and free of unnecessary information. It gets directly to the point.

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 tool, the description gives a basic understanding of its function, but lacks details on output format, error handling, or parameter specifics. It is adequate but leaves some gaps.

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

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

The single parameter 'album' is mentioned by name only, with no explanation of format, usage, or how it affects the output. The description indirectly suggests that providing an album yields a tracklist, but this is not explicit.

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

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

The description clearly states the tool lists albums or the tracklist of a single album, using the specific verb 'list' and a clear resource. It is distinct from sibling tools focused on shows, songs, or venues.

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 on when to use this tool over alternatives. It does not reference any sibling tools or specify conditions that would make this tool preferable.

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 does not disclose any side effects, permissions, or whether the operation is read-only. With no annotations available, the description carries the full burden, and it fails to mention these aspects.

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, concise sentence that efficiently conveys the core function and optional filtering. There is no unnecessary verbosity or structural complexity.

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 provides basic context but omits details such as return format, pagination behavior, or how results are ordered. It is adequate for a simple tool but leaves some gaps for an agent unfamiliar with the domain.

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 description explains the 'person' parameter as an optional filter but does not clarify the 'limit' parameter. Schema coverage is partial (1 of 2 parameters mentioned), and the description adds some meaning but is incomplete.

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: retrieving guest sit-ins or musician appearances, with an optional filter by person. It is concise and unambiguous, though it does not specify the exact output format.

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 on when to use this tool versus alternatives like search_shows or song_history. The description lacks any mention of distinct use cases or relationships to sibling 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool returns conceptually; it does not mention whether the call is read-only, what happens when no show exists for the date, or how include_related affects behavior.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently conveys the core purpose and date format in minimal space.

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 tool with no annotations, two parameters, zero schema descriptions, and several sibling tools, this description is too sparse. It covers the required date format but leaves usage boundaries, the optional parameter, and edge-case behavior unaddressed.

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 adds useful date-format guidance (YYYY-MM-DD), but it completely omits include_related, leaving its meaning and effect unexplained.

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 operation and resource: retrieving a Goose setlist for a specific date. The date-scoped lookup is distinct in spirit from siblings like random_show or latest_show, but it does not explicitly differentiate itself from search_shows or other date-oriented 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 phrase 'for a given date' implies use when an exact date is known, but there is no explicit guidance on when to choose this over search_shows, latest_show, or this_day_in_history. 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?

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only listing, but does not explain what 'notable' means, how results are sorted, the effect of the limit parameter, or any potential side effects. The lack of detail 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.

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

The description is a single, concise sentence with no filler. It front-loads the core purpose (notable jams) and includes the optional filter. Efficient and to the point.

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 (content unknown), but the description is too sparse. It fails to explain the limit parameter, the meaning of 'notable', or any usage context. For an agent to invoke this correctly, it would need more details about the output and default behavior. The description is inadequate for a tool with only two optional parameters.

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 for the schema's lack of explanatory text. It only hints at the song filter ('optionally filtered to one song') but does not name the parameter or explain the limit parameter. The description adds minimal value beyond 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 clear verb (list) and resource (ElGoose jam charts), and mentions optional song filtering, which distinguishes it from siblings like song_history and song_stats that focus on a specific song's history. However, it doesn't explicitly name alternatives, so it's not a perfect 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?

There is no guidance on when to use this tool versus the sibling tools. The description does not mention alternatives, when not to use, or any selection criteria. The agent is left to infer usage from the name and description 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?

There are no annotations, and the description does not disclose behavioral traits such as whether the operation is read-only, requires authentication, has rate limits, or returns partial data. It also does not state what the output format is beyond 'setlist,' so side effects and response structure are opaque.

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

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

The description is a single sentence with no fluff or redundancy. It is efficiently worded and front-loaded with the core action ('most recent show's setlist'), though it omits important details that would not compromise conciseness.

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 optional parameter and lack of output schema details, the description is incomplete. It does not explain the parameter's meaning, describe the expected output structure, or clarify the domain-specific notion of a 'show,' leaving critical gaps for an agent trying to use the tool correctly.

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

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

The only parameter, include_related, is not explained in the description or schema. With 0% schema description coverage, the description's failure to elaborate on 'related' leaves the parameter's purpose completely ambiguous, making it impossible for an agent to decide whether to set it to true or false.

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 returns the most recent show's setlist, which is a specific and unambiguous purpose. It distinguishes itself from sibling tools like random_show or search_shows by using 'most recent,' though it does not define what constitutes a 'show' in this context.

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 explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or conditions under which latest_show is preferred, leaving the agent to infer usage solely from the phrase 'most recent show's setlist.'

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool performs a health check and provides a manifest, but it does not state whether it is read-only, what the output structure is, or whether there are side effects. The behavior is under-specified for a tool that could return sensitive capability information.

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 states the primary action ('Health check') and the secondary purpose ('manifest'). There is no waste, and the structure is easy to scan. It earns its place fully.

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 is minimal but functional. It does not explain what the manifest contains (e.g., a list of tools, capabilities) or what the health check response looks like, though an output schema exists. For a simple tool, this is adequate but leaves room for richer context, especially given the number of sibling tools the manifest might enumerate.

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 there is nothing to describe beyond the schema. The description adds no parameter meaning, but per the rubric, a baseline of 4 is appropriate for 0-parameter tools since no semantic gap exists.

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 ('Health check') and a resource ('good_honker'), and adds a unique second purpose ('manifest of what good_honker can do'). This clearly differentiates it from sibling tools that perform domain-specific lookups (e.g., search_shows, venue_info). The purpose is unambiguous and not a tautology.

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 for health checks and capability discovery but does not explicitly state when to use it vs. alternatives. There are no exclusions or prerequisites mentioned. For a simple tool with no parameters, the implied context is adequate, but it leaves the agent to infer that this is the go-to connectivity test.

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

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

No annotations exist, but the description clearly indicates a read-only retrieval operation (returning a show). It does not mention side effects, which is acceptable given the nature of the tool.

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, succinct sentence that conveys the core functionality without unnecessary details 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?

The description provides all necessary context: what the tool returns (a random show with setlist), its purpose (discovery), and implicitly that no input is 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 parameter semantics are not applicable. The baseline of 4 is appropriate since no ambiguity exists.

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 returns a random Goose show with its full setlist, and the phrase 'Great for discovery' distinguishes its purpose from sibling tools like search_shows or get_setlist.

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 for discovery and random selection, but does not explicitly state when to avoid using it (e.g., when a specific show is needed). Still, the intent is 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?

No annotations are provided, and the description does not explicitly state whether the tool is read-only or destructive. Although 'find' implies a non-mutating operation, the lack of explicit side-effect information or mention of rate limits/pagination leaves behavioral transparency incomplete.

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 to the point, avoiding unnecessary words. It fits in one sentence and clearly lists the main search criteria without fluff.

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

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

The description lacks critical operational details such as whether at least one criterion is required, how multiple criteria are combined (the 'and/or' is ambiguous), and what happens when no criteria are provided. Although an output schema exists, the search behavior is not fully specified, which is essential for correct use.

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

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

The description only mentions year, city, state, and venue name, omitting 'limit' and 'include_related'. It does not explain parameter interactions (e.g., AND/OR logic), defaults (like limit=25), or the meaning of 'include_related'. Schema coverage is 0%, so the description fails to clarify these 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 purpose: finding shows based on specified criteria like year, city, state, and venue name. It uses a specific verb 'find' and identifies the resource as 'shows', which is unambiguous in the context of music-related sibling 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 provides no guidance on when to use this tool versus sibling alternatives like 'random_show', 'latest_show', or 'get_setlist'. It does not mention any prerequisites or typical use cases, leaving the agent uncertain about selecting this tool over others.

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

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

No annotations are present, and the description is a noun-phrase definition rather than an action statement. It does not explicitly disclose read-only behavior, side effects, authentication needs, or rate limits, so the invocation behavior is not clearly transparent.

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

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

The description is a single short sentence with no unnecessary words or redundant information. It is well-structured and easy to parse.

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

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

The description is adequate for a simple one-parameter tool, but it lacks the date format, return structure, and usage context. It is not severely incomplete, but it is not fully self-sufficient for an agent deciding whether and how to invoke 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?

The only parameter, date, is referenced as 'a given date', giving some context that it is the show date. However, the description does not specify the expected date format or any constraints, leaving some ambiguity beyond the schema's basic string type.

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 resource being accessed (poster art, images, and external links attached to a show) and references the date parameter. It is distinguishable from sibling tools by focusing on show extras rather than setlists, history, or stats, though it lacks an explicit verb such as 'retrieves' or 'lists'.

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 use this tool versus the sibling tools, or when not to use it. The description only states what content is involved, not the circumstances under which the tool 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?

The description gives no indication of side effects, read-only nature, or any behavioral constraints. With no annotations to supplement, the agent has no basis to infer whether this is a safe query or if it might trigger mutations or external calls.

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, but it is a sentence fragment lacking a subject and verb, making it structurally incomplete. While conciseness is valued, the brevity here sacrifices clarity and does not form a coherent instruction.

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 apparent purpose (listing a song's play history) and multiple parameters, the description is drastically incomplete. It omits the input requirement, output format, pagination (via 'limit'), and the effect of 'include_related', leaving an agent without essential context to invoke the tool correctly.

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

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

The description does not mention any of the three parameters ('song', 'limit', 'include_related'), and the schema itself lacks descriptions for them. The agent cannot infer what values are appropriate for 'limit' or the meaning of 'include_related', nor confirm that 'song' expects an exact title, ID, or other identifier.

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 'Every time a song has been played (most recent first).' is a fragment that fails to clearly state the tool's function. It does not explicitly say it retrieves a song's performance history, nor does it mention the required 'song' input or what output to expect. This is ambiguous and insufficient for an agent to understand the tool's purpose.

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 on when to use this tool compared to siblings like 'song_stats' or 'search_shows'. The description does not distinguish its unique role (e.g., historical list of performances) from alternatives, leaving the agent without criteria for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists the output fields and does not mention that this is a read-only operation, any potential side effects, rate limits, or the format of the response. It also does not state whether include_related changes the behavior.

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

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

The description is a single concise sentence with no filler, front-loading the purpose and key outputs. It is efficient, though it omits critical details about parameters and usage, which would not hurt conciseness if added.

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 (not shown) and no annotations, so the description must provide enough context for correct invocation. It fails to explain the include_related parameter, offers no usage guidance, and does not describe behavioral traits. For a 2-parameter tool, this is incomplete.

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 implies the 'song' parameter is the identifier but does not explain it beyond 'for a song'. The 'include_related' boolean is completely undocumented in the description, leaving the agent to guess its meaning and effect.

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: 'Summary stats for a song' and lists specific output fields (times played, debut, last played, jamchart count). It distinguishes itself as a stats aggregator from siblings like song_history or jam_chart, though it does not explicitly name them. The verb is implied but the resource and fields are specific.

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 on when to use this tool versus alternatives such as song_history or jam_chart. It does not state any exclusions or prerequisites. The description leaves it to the agent to infer that this is the go-to for aggregate statistics rather than detailed history.

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 conveys a read-only behavior with no side effects, but lacks detail on authentication, rate limits, or the effect of the optional include_related parameter. Without annotations, the agent is left with an incomplete behavioral model.

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, concise sentence that directly conveys the core functionality without unnecessary verbosity or redundancy. It is well-structured and easy to parse.

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

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

The description provides the basic query parameters and their ranges, but it does not describe what the returned data contains (e.g., show details, venue, date). Even though an output schema is indicated, the agent lacks a clear expectation of the response structure, making the call less predictable.

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 description only clarifies that month must be 1-12 and day 1-31, but does not explain the meaning or purpose of include_related. With three parameters and zero schema descriptions, the coverage is minimal, leaving a required parameter undocumented in terms of impact.

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: retrieving every show played on a given calendar day across years. The verb 'played' implies a read operation, and the scope (month/day, all years) is unambiguous, distinguishing it from other tools like search_shows or random_show.

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 for a calendar-day lookup across years, but it does not explicitly state when to prefer this tool over siblings (e.g., search_shows). No conditions or alternatives are mentioned, leaving the agent to infer appropriate use.

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?

There are no annotations to indicate side effects (e.g., read-only), and the description does not disclose any behavioral details beyond listing shows. Since the description carries the full burden without annotations, it lacks transparency about whether this operation modifies data or has other 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 a single sentence, extremely concise, and front-loaded with the core purpose. Every word serves a functional role, with no redundant phrasing or filler. It is appropriately sized 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?

The description provides basic scope (upcoming shows with dates on/after today) but lacks essential context, particularly the meaning of the include_related parameter. While output format is not required (schema exists), the missing parameter explanation leaves a significant gap for an agent to correctly invoke the tool with the desired behavior.

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 only parameter, include_related, is not explained in the description or schema. Schema coverage for parameters is 0%, and the description fails to compensate by defining what 'related' means or how this boolean affects results. The agent is left guessing at its purpose.

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 tool's function: listing shows that have been announced and that occur on or after today. It distinguishes itself from sibling tools like search_shows (searching), random_show (random selection), and latest_show (most recent).

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 rather than explicit. The description suggests it is for upcoming shows, but it does not explicitly state when to prefer this tool over alternatives like latest_show or search_shows. No clear 'use this when' or 'use that instead' 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?

With no annotations provided, the description carries the full burden. It states the output (metadata + play count) but does not disclose error behavior, case sensitivity, or whether the venue parameter expects an exact match or partial. It also does not mention if the tool is read-only, though that is implied. For a simple info tool, more transparency about input format would be expected.

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

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

The description is a single sentence that directly states what the tool does. It is perfectly concise with no filler, and the key information (venue metadata and play count) is front-loaded. It earns a top score for 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?

For a simple tool with one parameter and an output schema present, the description is minimally sufficient. It explains the purpose and the output. However, it lacks guidance on venue name format and does not clarify how this tool fits among the many siblings. The presence of an output schema reduces the need to explain return structure, but the description is still thin for a tool that an agent may need 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 coverage is 0%, so the description must compensate. The description mentions 'venue' as the resource but does not add any detail about the parameter's format, required exactness, or examples. The schema only provides the name 'venue' as a string, and the description adds nothing beyond that. Given a single trivial parameter, a score of 2 reflects the lack of helpful clarification.

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

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

The description clearly states the tool returns venue metadata and a play count for Goose at that venue. The verb 'has played' implies retrieval, and the resource 'venue' is specific. It distinguishes from siblings like album_info or song_history by focusing on venue-level data, though it could be more explicit about what 'metadata' includes.

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 on when to use this tool versus alternatives. It does not mention when to prefer venue_info over, say, show_extras or get_setlist, nor does it state any prerequisites like needing an exact venue name. The agent is left to infer usage from the tool name and description.

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