Server Quality Checklist

Tool Scores

• find_theatresB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It mentions return fields but omits details like sorting, pagination, or whether all theatres are returned. Basic transparency only.

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

  Conciseness5/5

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

  Two sentences: one for purpose and inputs, one for outputs. No wasted words, highly efficient.

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

  Completeness4/5

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

  For a simple 3-parameter query tool with no output schema, the description adequately explains inputs and outputs. Could mention default radius or result ordering, but overall sufficient.

  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 provides full parameter descriptions (100% coverage). The description adds the return fields (id, name, address, distance), which is valuable context beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool finds Cineplex theatres near a location using lat/lon and radius, and lists the return fields. It does not explicitly distinguish from sibling tools like find_movie, but the purpose is specific enough.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives like find_movie or get_optimal_seats. No mention of prerequisites or exclusions.

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

• find_optimal_showtimesA
  3.7/5.0
  Behavior4/5

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

  With no annotations, the description takes on the full burden. It transparently discloses key behaviors: seat quality filters (exclude front rows, side seats, require contiguous block) and default values for format, front rows, side seats, and contiguous seats. This goes beyond basic purpose.

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

  Conciseness4/5

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

  The description is a single sentence of 35 words, front-loading the core action. It is efficient and avoids fluff, though it could be slightly more concise by splitting into two sentences.

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

  Completeness2/5

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

  No output schema is provided, and the description does not clarify the return format (e.g., list of showtimes with seat availability markers). For a tool with 7 parameters and complex logic, this omission leaves the agent uncertain about what to expect. Some return details are essential for correct usage.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all parameters. The description summarizes the seat logic but adds only modest extra context (e.g., 'good seats' definition). It does not introduce new parameter meanings beyond what the schema provides. Baseline 3 is appropriate.

  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 action: given a movie, theatre, and date, find showtimes matching a format and check for good seats. It uses specific verbs ('find', 'check') and resources ('showtimes', 'seats'). The purpose is unambiguous and distinguishes it from sibling tools like find_theatres and find_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 context (when you have movie, theatre, date) but does not explicitly compare with sibling tools like get_optimal_seats or render_seat_map_html. No when-not-to-use advice or alternative recommendations are provided.

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

• get_optimal_seatsA
  3.9/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 says 'fetch and score' which implies a read operation, but does not disclose details like authentication requirements, rate limits, or scoring algorithm. Moderate transparency.

  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?

  A single, well-structured sentence that is front-loaded with the essential information. No wasted words.

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

  Completeness3/5

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

  The tool has 5 parameters but no output schema. The description does not explain the return value (e.g., seat scoring details). While the context signals and sibling tools provide some background, the description itself could be more complete for a tool with moderate complexity.

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

  Parameters3/5

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

  Schema coverage is 100%, so the input schema already describes each parameter's purpose. The description adds minimal extra meaning beyond stating that theatreId and showtimeId are from find_optimal_showtimes. Baseline 3 is appropriate.

  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 function: given a theatre ID and showtime ID, it fetches and scores seat maps. It also references the sibling tool find_optimal_showtimes, which distinguishes it from other tools like render_seat_map_html.

  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 explicitly mentions that theatreId and showtimeId can come from find_optimal_showtimes, guiding the agent to use this tool after finding showtimes. It does not explicitly state when not to use it, but 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.

• find_movieA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses fuzzy matching and paging through all results, but does not explicitly state that it is a read-only operation or discuss potential performance impacts. More transparency about safety (non-destructive) would improve the 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 a single, well-structured sentence that front-loads the primary action. No extraneous information; every part is meaningful and 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?

  Given the simple parameter set (one required) and no output schema, the description covers the essential behavior, including the fuzzy matching and page-through mechanism, and explains the tool's relevance to the workflow. It could be slightly more explicit about return format, but this is a minor gap.

  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?

  With 100% schema description coverage, the description adds value by explaining that the title is fuzzy-matched and that the result is the best match, which is not evident from the schema alone. This provides context beyond the parameter's type and description.

  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 action: fuzzy-match a movie title against Cineplex's current catalog. It specifies the resource (movie titles, Cineplex catalog) and output (best match with movie ID). It distinguishes from sibling tools like find_theatres.

  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 that the tool is a preliminary step to obtain a movie ID for other tools, but it does not explicitly state when to use it versus alternatives or when not to use it. No direct usage guidelines beyond inferred context.

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

• render_seat_map_htmlA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description must disclose behavior. It explains the HTML content and constraints (inline rendering, no modification). However, it lacks details on failure modes or data freshness. Overall, it provides key behavioral context.

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

  Conciseness4/5

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

  The description is a single paragraph but front-loads the core purpose. Every sentence adds value, though it could be more structured. It is concise enough for the complexity involved.

  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 10 parameters and no output schema, the description covers output format (HTML widget), usage constraints, and parameter hints. It lacks error handling details, but overall provides a solid understanding of the tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so description adds limited semantic value. It mentions passing theatreName/theatreAddress/distanceKm from prior results, which adds usage context, but does not elaborate on parameter meanings beyond schema.

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

  Purpose5/5

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

  The description clearly states the tool returns an HTML page visualizing seat availability, specifying the inputs (movie, theatre, date) and the output (self-contained widget). It distinguishes from siblings like find_theatres or find_movie by focusing on rendering a visual widget.

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

  Usage Guidelines5/5

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

  Explicit instructions are given: render inline via show_widget, never save to file, do not modify code. Also advises passing theatreName/theatreAddress/distanceKm from find_theatres to avoid extra lookups. This clarifies when and how to use the tool.

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