Server Quality Checklist

Tool Scores

• get_eventB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, setting baseline expectations. The description adds 'complete details', which implies all available fields are returned, but does not elaborate on behavior like pagination, formatting, or potential errors. No contradiction with annotations.

  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 concise sentence of few words. It is appropriately short for a simple tool, though it could be structured with bullet points for clarity.

  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?

  Given the tool has one parameter, no output schema, and annotations present, the description is incomplete. It does not describe what 'complete details' means in terms of return values or any edge cases (e.g., invalid event_id). The agent would lack information on what to expect as output.

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

  Parameters1/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 not explain the purpose or format of 'event_id', leaving the agent to infer from the parameter name alone. This is insufficient for a required parameter.

  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 action: 'Get complete details for one Luma event.' It uses a specific verb ('Get') and resource ('Luma event'), and by naming 'one event', it differentiates from siblings like list_events (which returns multiple events).

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., event_id must exist) or when to prefer other tools like list_events or registration_summary.

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

• create_eventB
  3.1/5.0
  Behavior2/5

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

  With annotations already indicating readOnlyHint=false, the description adds only the action 'Create' without disclosing behavioral details such as side effects, auth requirements, or error scenarios. The description does not contradict annotations but adds minimal value beyond them.

  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 very concise with two sentences and no wasted words. However, for a tool with 15 parameters, it could be more informative while remaining concise.

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

  Completeness1/5

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

  Given the complexity (15 parameters, nested objects), low schema coverage (7%), and no output schema, the description is severely incomplete. It lacks details on input formatting, return values, and error handling, making it insufficient for correct invocation.

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

  Parameters1/5

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

  Schema description coverage is only 7% (only 'confirmed' has a description). The tool description does not add any parameter-specific meaning, leaving many parameters unclear. It mentions 'event name, date/time, timezone' but does not map them to specific parameters or provide format details.

  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 'Create a Luma event', which is a specific verb+resource. It distinguishes from siblings like get_event and update_event by focusing on creation. The additional condition about user confirmation further clarifies the scope.

  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 states when to call the tool: 'only after the user has explicitly confirmed the event name, date/time, timezone, and supplied details.' This provides clear context. However, it does not mention when not to use it or provide alternatives, missing some opportunity for guidance.

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

• list_guestsB
  3.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds important behavioral context: guest data may include personal information and must be used only for user-requested operations. This goes beyond annotations by disclosing data sensitivity and usage restrictions.

  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 with no redundancy. First sentence states the action; second adds critical privacy instruction. Every word earns its place.

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

  Completeness3/5

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

  Given 4 parameters, no output schema, and existing sibling tools, the description covers the basic purpose and a warning, but omits details on pagination, filtering, output shape, and relationship to siblings. It is minimally adequate but not comprehensive.

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

  Parameters1/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 clarify parameter meaning. It does not mention any parameter (event_id, approval_status, pagination_limit, pagination_cursor). The description adds no value for parameter semantics.

  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?

  Purpose is clearly stated as 'List guests for an event.' The verb 'list' and resource 'guests' are specific. It distinguishes from siblings like list_events (events vs guests) and get_event (single event), but does not explicitly differentiate from registration_summary.

  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 explicit guidance on when to use this tool vs alternatives. The only usage note is a privacy caveat ('use only for event operations requested by the user'), but no context for when to choose this over sibling tools like registration_summary or list_events.

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

• get_guestA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare the tool as read-only and open-world. The description adds that the response contains personal and ticket-order details, which provides some behavioral context beyond annotations. However, no mention of permissions, data sensitivity limitations, rate limits, or potential side effects.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action and resource, every word adds value. No redundancy or verbosity.

  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 description mentions the kind of data returned (personal info, ticket-order details) but is vague. With no output schema, more detail would help. It does not explain the purpose of event_id or provide examples. For a two-parameter tool with moderate complexity, it is minimally complete.

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

  Parameters2/5

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

  Schema description coverage is 50%: the 'id' parameter has a description that is already clear, but the description does not add extra meaning beyond the schema. The 'event_id' parameter has no description in the schema, and the description does not explain what event_id is or how to find it. No value added over 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 uses a specific verb ('Get') and resource ('complete details for one event guest') and lists multiple identifiers (guest ID, ticket key, guest key, or email), making the purpose clear. It distinguishes from sibling 'list_guests' which returns multiple guests.

  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 for retrieving a single guest's details, but does not explicitly state when to use this tool versus alternatives like 'list_guests' or 'registration_summary'. No when-not-to-use or exclusions are provided.

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

• list_eventsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description confirms it lists events (read-only) and adds context about the calendar attachment but does not disclose any additional behavioral traits like pagination limits or default status.

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

  Conciseness5/5

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

  Single sentence, 12 words, no redundancy. The core action 'List events' appears first.

  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 no output schema, the description adequately states the tool's purpose and data source. It omits return format details but the schema and tool name imply a list of events. Annotations cover safety. Minor gap: no mention of pagination or status defaults.

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

  Parameters3/5

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

  Schema description coverage is high (80% of parameters have descriptions), so the description need not add parameter details. The tool description provides no additional parameter context beyond the 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 uses a specific verb 'List' and resource 'events' with a clear source 'calendar attached to the configured API key'. It distinguishes itself from siblings like get_event (single event) and create_event (write operation).

  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 versus siblings (e.g., get_event for a single event, registration_summary for attendee counts). The description only states what it does, not when it should be preferred or avoided.

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

• registration_summaryA
  4.3/5.0
  Behavior4/5

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

  Adds constraints like 'across all guest pages' and 'without returning guest identities' beyond annotations (readOnlyHint, openWorldHint). No contradiction.

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

  Conciseness5/5

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

  Single sentence, front-loaded with key action and scope, no wasted words.

  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 tool with one parameter and no output schema, the description sufficiently covers behavior, scope, and privacy constraints.

  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?

  Event_id parameter lacks explanation in schema (0% coverage); description implies it identifies the event but doesn't specify format or required constraints beyond required field.

  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 counts guest approval states and check-ins across all guest pages, distinguishing it from siblings like list_guests which returns identities.

  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?

  Implies use for aggregate statistics without privacy-sensitive data, and contrasts with list_guests for identity retrieval. Could explicitly state when not to use.

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