LONG Events

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 discloses that the tool returns a profile, upcoming dates, and recent history, plus the acceptable identifier types. However, it doesn't mention any auth requirements or potential limitations, but for a read-only profile fetch, 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 two sentences, front-loaded with the action and resource, and includes practical examples. 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?

Given the tool's simplicity and 100% schema coverage, the description sufficiently explains the return content and usage context. It could mention the output structure, but the absence of an output schema is mitigated by the clear description of what is returned.

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 cover all three parameters, so the baseline is 3. The description adds value by clarifying that artist_id, slug, or name are alternative ways to specify the artist, which is not explicitly stated in the schema. This helps the agent know any one can be provided.

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 specifies 'Get one artist's profile with their upcoming dates and recent history,' which clearly distinguishes it from sibling tools like get_artist_events or search_artists. Examples of natural language queries reinforce the 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?

It states when to use it via examples ('Use this to answer...'), but does not explicitly mention when not to use or point to alternatives like get_artist_events for event-only queries. Still, the context 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, so the description carries full responsibility for behavioral disclosure. It does add useful context by mentioning that each performance includes ticket_url (the resolved closest-to-purchase link) and the raw source page URL, which hints at the return structure. However, it omits critical behavioral facts: it does not mention that an artist identifier (name, slug, or artist_id) is required despite the schema listing all parameters as optional, nor does it explain default behaviors like upcoming_only=true. These are significant oversights for a tool with zero annotation support.

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 sentences with no wasted words. It front-loads the primary purpose, then provides a concrete example, and ends with a valuable detail about the return data (ticket_url). Each sentence adds essential information without redundancy, making it efficient 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?

While the description includes an example and a return data hint, it fails to specify that an artist identifier is effectively required even though all schemas are optional. Without that explicit guidance, an agent might call the tool without any filter and get unexpected results. Additionally, there is no output schema, so the description should outline the standard fields or note pagination behavior more explicitly. These gaps prevent it from being fully 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 100%, so every parameter already has a description. The tool description adds only general context about filtering and pagination, which does not go beyond what the schema provides. Since the description does not elaborate on parameter formats, interdependencies, or selection criteria, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'List one artist's performances with filtering and pagination.' It uses a specific verb and resource, and provides a concrete example ('Where is Peggy Gou playing in Europe next month?') that distinguishes it from broader search tools. The scope is unambiguous and immediately separates it from sibling tools like search_events which cover multiple artists.

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 explicit usage examples ('answer this question' or 'page through a touring artist's full schedule'), which strongly implies when to use it. However, it does not mention alternatives or explicitly state when not to use it, such as for cross-artist searches. This is a minor gap since the examples clarify the intended use case.

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, so the description carries the full burden. It hints at output contents ('statistics like total events and recent activity') but does not disclose behavioral details such as read-only nature, error handling, rate limits, or ordering. Some transparency but significant gaps.

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

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

Two sentences, front-loaded with the core purpose. No unnecessary words; every sentence adds value.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description provides a high-level purpose but lacks details on what 'statistics' specifically include, how parameters affect output, or ordering. Adequate but not fully complete for an agent to use optimally.

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

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

Schema coverage is 100% with parameter descriptions already provided. The tool description adds no additional meaning to the parameters (limit, country, min_events), so it does not improve upon 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?

Description clearly states the tool lists cities with events and includes statistics like total events and recent activity. It distinguishes from sibling tools by focusing on cities rather than specific events or venues, though it does not explicitly contrast with siblings.

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?

Description provides a use case ('help users discover active event scenes') but does not specify when to use this tool over alternatives like search_events or get_venues. No exclusions or context for selection are given.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully reveals that the response includes untruncated descriptions and specific detail fields. However, it does not mention potential error cases, response structure, or confirm read-only/idempotent behavior beyond the obvious 'get' 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 a single front-loaded sentence with a compact list of return contents. Every phrase adds information, and there is no redundant or filler wording.

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 tool with no output schema, the description sufficiently indicates what response content is returned and which key is needed. It stops short of describing error behavior or format-level details, but the tool's simplicity makes that a minor 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?

The schema already documents event_id as a UUID, and schema description coverage is 100%. The description merely references 'by its ID' and does not add new semantic detail about the parameter, which matches the baseline for fully covered 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 uses a specific verb ('Get'), names the exact resource ('event by its ID'), and details the returned content (description, venue, timezone, lineup, ticket URL). This distinguishes it clearly from sibling tools like get_event_week_details or search_events.

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 context is clear: use this when you already have an event ID and need complete details for that single event. It does not explicitly name alternatives or exclusion conditions, but the purpose is specific enough for an agent to route appropriately.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool returns, but does not mention any side effects, authentication needs, rate limits, performance expectations, or error handling (e.g., if event not found). For a read operation, basic transparency is lacking.

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 long, with the first sentence stating the core purpose and the second providing example usage. It is front-loaded, efficient, and contains no filler, making it easy for an AI agent to parse quickly.

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 absence of output schema and annotations, the description covers the basic return types (set times, stages, artists) and parameter filters. However, it does not clarify that all parameters are optional, how event identification works (event_id vs event_name), or the structure of the response. It is adequate but not fully comprehensive.

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?

All four parameters have descriptions in the input schema (100% coverage). The description text adds minimal value beyond the schema; it does not clarify the trade-off between 'event_id' and 'event_name' or provide additional usage context. Baseline 3 is appropriate since schema already covers 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 tool's purpose: 'Get the DJ/artist schedule for a festival or party event. Returns set times, stages, and artists.' It uses a specific verb ('Get') and resource ('schedule'), and distinguishes from siblings like 'get_event_details' and 'search_events' by focusing on schedule retrieval. Including example questions further clarifies the intended use.

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 includes example questions ('What time does ANOTR play?', 'What's happening at AYA on New Year's Eve?'), which imply when to use this tool. However, it does not explicitly state when not to use it or provide alternatives among siblings, leaving some ambiguity for edge cases.

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

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

No annotations provided, so description carries full burden. Describes basic behavior but does not disclose ordering, pagination, definition of 'upcoming', or whether data is real-time.

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

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

Two sentences, front-loaded with action and purpose, 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?

Tool is simple with no parameters, but lacks output schema or description of return format (e.g., list of city names with count values). Could be more complete for agent usage without 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?

No parameters, so schema coverage is 100%. Description does not need to add param info; baseline of 4 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?

Clearly states it lists cities with upcoming event weeks and their counts. Distinguishes from sibling 'get_cities' by focusing on cities with events, but could be more explicit about what 'counts' refers 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?

Suggests use case ('discover where major conferences are happening') but does not provide when-to-use vs alternatives like 'get_cities' or other 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?

No annotations are provided, so the description carries full burden for behavioral transparency. It states the tool returns 'full details' and 'side events,' but does not disclose any behavioral traits such as rate limits, authentication needs, or whether it is idempotent. The lack of detail on what constitutes 'full details' leaves the agent guessing about the response structure.

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 consists of two sentences that efficiently convey purpose and usage guidance. Every sentence adds value with no unnecessary words 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 tool has 3 parameters (all optional, 100% schema coverage) and no output schema. The description explains it returns 'full details and side events' but does not specify the exact fields returned (e.g., dates, venues, organizers). For a detail-retrieval tool, more information about the output structure would improve completeness.

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

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

Schema description coverage is 100%, meaning all three parameters (slug, week_id, event_week_id) are described in the input schema. The description does not add any extra meaning beyond what the schema provides, e.g., which parameter to prefer or any constraints. Baseline score of 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?

Description clearly states 'Get full details for a conference week including all its side events.' This provides a specific verb and resource, and the inclusion of side events distinguishes it from tools like get_event_weeks (which lists weeks) and get_event_details (single event).

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 second sentence, 'Use this to help users see everything happening during a major conference,' gives context for when to use the tool. It does not explicitly state when not to use or mention alternatives, but the sibling tool names imply alternatives for listing weeks or single events.

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 says it lists 'upcoming' events, implying a time filter, but does not explain default behavior (e.g., include_past param) or response format. No annotations are provided, so the description bears the burden but gives only basic 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?

Two concise sentences with no waste. The purpose and a sample use case are presented clearly and front-loaded.

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

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

Given 5 parameters and no output schema, the description could explain return structure or defaults. However, the tool seems intended for listing summaries, and companion tools (get_event_week_details) exist for details. It adequately covers the core use case.

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

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

Schema coverage is 100%, so the description does not need to add parameter details. The description does not mention any parameters, which is acceptable given full schema 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 clearly states the tool lists upcoming conference weeks, festivals, and multi-day event series, with specific examples (ETH Denver, Devconnect, Token2049). It distinguishes from siblings like search_event_weeks by using 'list' rather than 'search'.

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

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

The description provides a usage hint: 'Use this to help users plan trips around major conferences.' However, it does not specify when not to use it or contrast with alternatives like search_event_weeks.

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?

Without annotations, description carries full burden. It describes a read operation with no side effects, but doesn't discuss authentication, rate limits, or empty results. Acceptable for a simple 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?

Two concise sentences, front-loaded with action. Zero waste, every word adds value.

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

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

Adequate for a simple listing tool with no parameters. Lacks explicit return format, but context is mostly complete given no 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?

Zero parameters, baseline 4. Description adds value beyond empty schema by specifying 'all tags' and 'counts', clarifying what the tool returns.

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

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

Description clearly states the verb 'List' and resource 'tags used in event weeks' with specific details (counts). It differentiates from sibling tools like get_cities and get_event_details by focusing on 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?

Provides context 'discover types of conferences available', implying usage for overview. Does not explicitly exclude alternatives, but given sibling tools cover specific entities, the guidance is adequate.

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

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

No annotations provided, so description must disclose behavior. It mentions returns live stage information but does not clarify how 'current' is determined (e.g., real-time vs schedule-based) or any 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?

Two concise sentences front-loading the core purpose and ending with example use cases. 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?

Given the tool's simplicity and no output schema, the description sufficiently explains return value (stage info, current artists). Sibling tools are listed for 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?

Schema coverage is 100%, so parameters are well-documented. Description does not add additional semantics beyond the schema, meeting the baseline.

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 it gets what's currently playing at festival/party events with live stage info and current artists. Clearly differentiates from sibling tools like get_event_schedule.

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

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

Explicitly provides use cases: answering 'What's on now?' or 'Who's playing right now at AYA?'. Does not exclude any scenarios, but context 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 only states the action (listing) without disclosing any behavioral traits such as side effects, authentication needs, rate limits, or read-only nature. The description carries the full burden but adds 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 two sentences with no wasted words: one for function, one for usage. It is appropriately front-loaded. Could be slightly more explicit about 'event history' but overall 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?

For a simple tool with 2 parameters and no output schema, the description covers the basic purpose and use case. However, it lacks details on return format (e.g., what fields, pagination) and does not mention siblings for disambiguation, leaving some context gaps.

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

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

Schema coverage is 100%, meaning the schema already documents both parameters (city, limit). The description does not add new meaning beyond naming 'city' in the first sentence. Baseline of 3 is appropriate.

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

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

The description clearly states the verb ('List') and resource ('venues in a city'), and distinguishes from sibling tools that focus on cities or events. The phrase 'with their event history' adds context, though slightly vague.

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 a general use case ('find popular venues or discover new spots') but does not explicitly guide when to use this tool versus alternatives like get_event_details or search_venues. No exclusions or competing tools are mentioned.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the ordering behavior ('Ordered by how many performances we track') and optional scoping, which adds value. It does not mention pagination, limits, or error behavior, but these are visible in the schema and are typical for a read-only list 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 efficient: two sentences with a clear verb + resource + key behaviors, plus example questions. No wasted words; it front-loads the most important 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 list tool with 8 optional parameters, the description provides a solid high-level overview and use cases, but does not explain how parameters interact (e.g., upcoming_only default behavior with city/country). The schema covers the specifics, and the output schema is absent, so the description is reasonably complete for a browse operation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific semantics beyond the schema; it references city/country but does not explain parameters like query, source, min_events, or upcoming_only. The schema already documents these, so no deduction is warranted.

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 browses artists with optional city/country scoping, uses a specific verb and resource, and differentiates from siblings via its 'browse' positioning and ordering by tracked performance count. The example queries reinforce its 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?

Provides clear use cases with example questions ('Who is playing in Berlin this month?' or 'Which artists tour most?'), which imply when to use this tool. However, it does not explicitly mention alternatives or when not to use it (e.g., exact artist lookup via get_artist or full-text search via search_artists).

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

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

No annotations are provided, so the description carries the burden. It adds useful behavioral context like 'across all sources' and 'every performance we know about,' but it does not disclose pagination, default behaviors (e.g., upcoming_only defaults to true), or potential limitations. This is adequate 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?

Three sentences: definition, usage, and example queries. Every sentence earns its place, and the most important information is front-loaded. No fluff 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 covers the core use case with examples and clarifies the scope ('every performance'). It doesn't explain return value structure or edge cases, but for a search tool with 7 params and no output schema, it is reasonably complete. The lack of alternative guidance is the main 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides; it only hints at typical use cases (e.g., 'where' maps to city/country, 'when' maps to dates).

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

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

The description clearly states the tool searches artists by name and returns every known performance across all sources. It distinguishes from siblings like list_artists or get_artist_events by emphasizing the comprehensive performance lookup, making the purpose specific and unambiguous.

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

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

Explicitly provides when to use the tool ('Use this to find when and where a specific artist is playing') and gives concrete example queries. It lacks explicit exclusions or alternatives, but the clear usage context earns a 4 rather than a 5.

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, so the description carries the burden of behavioral disclosure. It usefully explains that descriptions come from the organizer or are generated, and that lineup is ordered with the headliner first. It still does not address what happens when neither city nor coordinates are provided, or whether city and coordinates conflict.

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

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

Two sentences with no filler. The core action is front-loaded, and the second sentence packs useful behavioral detail about descriptions and lineup without unnecessary explanation.

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 explains key return semantics, but for a 9-parameter search tool with no output schema and no annotations, it leaves the interaction between city, latitude, longitude, and radius_km ambiguous. It also doesn't state sorting or default behavior when location filters are absent.

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 covers 100% of the 9 parameters with meaningful descriptions, so the description is not required to re-explain each one. It conveys only a high-level 'near a location' framing, providing baseline value without adding syntax-level 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?

States a specific verb and resource: 'Search for events near a location with optional filters.' The final sentence reinforces its intended use for finding events in a city or near coordinates, making it clear which of the siblings (get_event_details, search_event_weeks, etc.) this tool belongs 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?

Provides an explicit direction: 'Use this to help users find events in a city or near coordinates.' It does not, however, mention when not to use it or point to alternative tools such as get_artist_events or search_event_weeks, so the routing is good but not exhaustive.

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

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

Without annotations, the description carries full burden for behavioral traits. It only states the search capability, omitting details like read-only nature, pagination (limit parameter implied but not explained), or error handling. No contradictory statements.

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 at two sentences, front-loading the core action. It wastes no words, though it could be slightly more structured with explicit parameter references.

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 (2 params, no output schema), the description is adequate for basic usage. However, it does not cover return format or selection criteria among siblings, which a more complete description would address.

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

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

Schema coverage is 100% with descriptions for both query and limit. The description adds value by confirming that query matches name, description, or city, but does not add new semantics 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 clearly states it searches event weeks by name, description, or city, which is a specific verb-resource combination. It also mentions 'conferences or festivals' as examples, but does not explicitly differentiate from sibling tools like get_event_weeks.

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 suggests using the tool to find specific conferences or festivals, providing context. However, it lacks explicit when-not-to-use instructions or mention of alternative tools like get_event_weeks for listing all.

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 provides some behavioral detail by listing return fields, but it does not explicitly state side effects (e.g., read-only, no modifications) or authentication needs.

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

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

Single sentence is concise and front-loaded with purpose. Could be slightly improved by noting the default limit, but that is captured in 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 no output schema, the description lists return fields adequately. However, it lacks guidance on ordering, pagination, or when to apply filters, which would help complete the picture for the agent.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds context about return fields but not additional parameter meaning 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 clearly states it searches organizer profiles with enriched event data and lists the specific return fields (names, source, website, etc.), distinguishing it from sibling tools like search_artists or search_events.

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 (e.g., search_artists, search_events). Usage context is only implied by the resource type.

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