Server Quality Checklist

Tool Scores

• bms_get_moviesA
  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 behavioral disclosure. The description only states that it 'retrieves clean, structured movie listings' and mentions optional filtering, but it does not disclose any non-read behaviors, potential side effects, rate limits, authentication requirements, or response format details. Since it is a read-only operation, the absence of a destructive hint is not an issue, but the description does not add any behavioral context beyond the core retrieval action.

  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?

  The description is concise and well-structured. It opens with a clear summary line ('Get Active Movie Listings in a City') followed by a brief explanation and a structured Args section. There is no fluff or redundancy; every sentence contributes to understanding the tool's purpose and usage. The length is appropriate for a simple read 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?

  The tool is relatively simple, has an output schema (so return values are covered by structured data), and the description covers the primary purpose and all parameters. It does not mention prerequisites like the city needing to come from bms_get_cities, but that is implied by the examples and the overall context. For a read-only listing tool, the description is sufficiently complete to allow an agent to call it correctly without additional clarification.

  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 schema description coverage is 0%, so the description must compensate. The description includes an Args section that explicitly describes each parameter: city (with examples), language (with a list of values), and genre (with a list of values). This adds meaning beyond the schema's basic type definitions and helps an agent understand how to use the parameters correctly. It does not provide exhaustive enumerations but gives clear examples and allowed values, which is sufficient for most cases.

  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 tool retrieves movie listings for a selected city, with optional filtering. It uses a specific verb ('retrieves') and a specific resource ('movie listings'), and the scope ('in a selected city') distinguishes it from siblings like bms_get_movie_details (details for a specific movie) and bms_get_showtimes (showtimes). This is a clear, unambiguous purpose.

  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 explains what the tool does and that it takes a city as a primary argument, but it does not explicitly state when to use this tool over alternatives like bms_get_showtimes or bms_get_movie_details. The usage context is implied by the tool's name and description, but there is no explicit statement of when not to use it or which sibling to choose for other needs. This qualifies as implied usage.

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

• bms_searchA
  3.8/5.0
  Behavior2/5

  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. However, it only states the action (search) and the input constraints; it does not disclose anything about response format, pagination, rate limits, or that it is a read-only operation. For a search tool, being read-only is implied but not stated. This leaves significant behavioral information uncommunicated.

  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?

  The description is extremely concise: a one-line title, a single descriptive sentence, and a compact Args list. It front-loads the purpose and provides parameter examples without any redundant phrasing. Every sentence earns its place, and the structure is clean and scannable.

  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 that an output schema exists (so return values need not be explained) and the description covers both parameters with examples and the operation's scope, the description is fairly complete for a search tool. It mentions 'active' listings and 'selected city,' which are key constraints. Minor gaps like pagination or sorting are not critical for a search tool, so the completeness is strong but not perfect.

  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. It does so by explaining both 'query' as a search keyword and 'city' as a city slug, each with concrete examples. It also clarifies the city is 'selected' and provides example slugs. This adds meaningful semantic context beyond the bare schema titles, though it doesn't mention the default city value (mumbai).

  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 states a specific verb ('Performs a cross-search') and resource ('active movie titles and live event listings'), with a clear scope (a selected city, matching a query term). It distinguishes itself from the sibling tools by explicitly being a cross-search, which sets it apart from bms_get_movies and bms_get_events. This is precise and unambiguous.

  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 clearly implies when to use this tool (when you want results from both movies and events), but it does not explicitly mention alternatives or exclusions. It doesn't say 'for single-category searches, use bms_get_movies or bms_get_events,' so the agent must infer that from the cross-search wording. This is adequate but lacks explicit routing guidance.

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

• bms_get_eventsA
  4.2/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. It discloses it is a retrieval operation ('Retrieves active live events') and lists the returned data fields. However, it does not explicitly state whether it is read-only, whether any authentication is required, or whether there are rate limits or pagination—though these are not critical for a simple listing tool. It gives no details on side effects, which is safe to assume none exist, but the lack of explicit statement keeps it at a modest score.

  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?

  The description is concise: a one-sentence summary plus an Args block that clearly documents both parameters with examples. It front-loads the purpose and avoids fluff. Every sentence earns its place.

  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?

  An output schema exists, so return value details are not required. The description covers both parameters and describes the type of data returned (venue names, dates, category tags). It does not mention pagination or limits, but for a city-scoped event listing, that's likely acceptable. Overall it's adequate and leaves few open questions.

  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 coverage is 0%, so the description must explain parameters, and it does. It gives example city slugs ('mumbai', 'bengaluru', 'delhi') and enumerates allowed category values ('events', 'comedy-shows', 'music-shows', 'sports'), adding context that the schema otherwise lacks. The defaults are in the schema, so the description doesn't need to repeat them. This is a strong compensatory effort.

  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 'Get Live Events & Shows in a City' and enumerates the types of events (comedy, music, sports, etc.), distinguishing it from siblings like bms_get_movies and bms_get_showtimes. It names the target resource (live events) and the verb (get), making its purpose unambiguous.

  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 implies when to use it (when a city's live events are needed) and the parameter guidance narrows the use case, but it does not explicitly name alternative tools or state when not to use it. The sibling list makes it clear that other tools handle movies and showtimes, but this isn't stated in the description itself.

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

• bms_get_venue_detailsA
  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 the full burden of behavioral disclosure. It explicitly lists the data returned (address, coordinates, amenities) and explains the input format for venue_code (code or full URL). It implies a read-only operation but doesn't explicitly state that, though 'retrieves' strongly suggests it. The description adds meaningful context beyond the raw schema.

  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 appropriately sized and front-loaded with a clear title line, followed by a succinct paragraph and then the Args section. There is slight redundancy between the title and the first sentence ('Get Cinema Venue Location & Geo Coordinates' vs 'Retrieves detailed cinema hall/theater metadata'), but the overall structure is efficient and scannable. No unnecessary 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?

  Given the tool has an output schema (presumably describing return fields), the description doesn't need to explain the return structure. It covers the tool's purpose and both parameters adequately. It doesn't mention the default city value, but that's available in the schema. For a relatively simple read tool, the description provides enough context for correct invocation, though it could note that city defaults to 'mumbai' if omitted.

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

  Parameters5/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 fully explain parameters. It does: venue_code is described as a BookMyShow code or full URL with examples, and city is described as a slug with examples. This goes well beyond the schema's minimal title and default value, providing clear, actionable guidance for both parameters.

  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 identifies the tool's function: retrieving cinema venue metadata including address, coordinates, and amenities. The verb 'retrieves' is specific and the resource scope (venue details) distinguishes it from sibling tools focused on cities, movies, events, and showtimes. The tool name and description align perfectly.

  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 usage—when you need detailed venue info, this is the tool—but it doesn't explicitly contrast with siblings or state conditions for when to choose this over others. No alternatives are mentioned, but the narrow scope makes the intent clear enough for an agent to infer.

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

• bms_get_movie_detailsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It explicitly enumerates the return content (poster URLs, trailer links, cast/crew profiles, etc.), which is transparent about what the tool produces. It does not mention side effects, but as a retrieval tool this is sufficient.

  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 front-loaded with a clear title line, then a detailed paragraph. It is structured with an Args section that cleanly lists parameters. Slightly verbose but every sentence adds value; no redundancy.

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

  Completeness5/5

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

  The description is complete for an agent to call correctly: it covers both parameters, explains the output comprehensively, and the presence of an output schema further reduces ambiguity. No missing information needed for invocation is apparent.

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

  Parameters5/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 explain parameters. It does so thoroughly: movie_code is described as a BookMyShow event code with an example format ('ET00378770') or a full URL, and city is described as a slug with a default value. This fully compensates for the schema's gaps.

  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 tool's purpose: 'Retrieves comprehensive movie metadata' and lists specific data types (plot synopsis, duration, ratings, URLs, cast/crew). It distinguishes from siblings like bms_get_movies (list) and bms_get_showtimes (times) by focusing on details for a single movie.

  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 usage when a movie code or URL is known and details are needed, but it does not explicitly contrast with siblings or state when NOT to use it. No alternative tools are mentioned, so the agent must infer the appropriate context from the resource type.

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

• bms_get_citiesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns (regions, cities, codes, slugs) and defines the popular_only parameter's effect (filter to tier-1 cities). This goes beyond the bare schema and gives agents a concrete picture of the result set. While it doesn't mention rate limits or auth, such details are not critical for a simple list endpoint and the output schema likely covers the return structure.

  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?

  The description is compact and efficient. It opens with the action, describes the output, and lists the argument with its effect. There is no redundant filler. The title and body together deliver all necessary information in a few lines, making it easy to parse.

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

  Completeness5/5

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

  For a simple lookup tool with a single optional parameter and an output schema, the description is complete. It tells the agent what data is returned, the parameter's role, and the geographic scope. The output schema presumably defines the structure, so nothing essential is missing. It provides sufficient context for correct invocation.

  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 schema only provides the parameter name 'popular_only' with a title and default, giving no semantic description. The tool description compensates by explaining that setting it to True returns only major popular tier-1 metropolitan cities. This adds meaningful meaning beyond the schema, which is essential given the 0% schema 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 the tool's purpose: 'Get Supported Cities & Regions' and elaborates that it returns all supported regions and major cities in India for BookMyShow, including region codes and URL slugs. This specifies both the verb (get), resource (cities/regions), and the scope (India, BookMyShow). It is easily distinguishable from sibling tools that deal with movies, events, showtimes, etc.

  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 provides clear context for when to use this tool: whenever you need the list of supported cities/regions. It does not explicitly mention alternatives, but the siblings are clearly unrelated, so the usage is evident. There are no exclusions or complex conditions. This meets the 'clear context, no exclusions' criterion.

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

• bms_get_showtimesA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of describing behavior. It clearly states that this is a retrieval operation, enumerates what data is returned, and notes default date behavior. It does not mention error conditions, pagination, or rate limits, but for a read-only 'get' operation the description is sufficiently transparent about the expected outcome.

  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?

  The description is well-organized with a titled overview, a list of returned data, and a structured Args block. It is front-loaded with the core purpose and each sentence earns its place. No fluff or repetition; the formatting makes it easy for an agent to scan.

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

  Completeness5/5

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

  For a tool with 5 parameters and an output schema (though not shown here), the description is exceptionally complete. It covers all parameters, provides defaults, examples, and explicitly lists what the response will contain (formats, prices, mobile ticket flags, seat availability). An agent can call this tool correctly without needing to inspect the schema further.

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

  Parameters5/5

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

  The schema has zero description coverage, so the description must fully compensate. It does: each parameter (movie_code, city, date, language, format) is explained with concrete examples and allowed values (e.g., 'ET00378770', 'mumbai', 'YYYYMMDD', 'tamil'/'all'). This goes well beyond the bare schema and gives the agent everything needed to construct valid calls.

  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 opens with a clear verb + resource: 'Get Cinema Venues & Showtimes' and immediately enumerates the specific retrieval details (formats, price ranges, mobile ticket support, seat availability). It unambiguously distinguishes itself from siblings like bms_get_venue_details (which targets a single venue) and bms_get_movies (which lists movies) by focusing on showtimes for a given movie and city.

  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 makes it obvious when to use this tool: when you need showtimes for a specific movie in a city, with optional filters. It does not explicitly name alternatives or state when not to use it, but the semantics are clear enough for an agent to route correctly. A brief pointer to siblings (e.g., 'for movie listings use bms_get_movies') would have made it a 5.

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