Server Quality Checklist

Tool Scores

• delete_eventC
  2.7/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true, which inform the agent this is destructive but idempotent. The description adds nothing beyond restating the action; it doesn't mention that deletion is permanent/irreversible, whether calendar_id affects which calendar the deletion applies to, or what happens to related events/recurring series.

  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 efficient sentence with no waste. It's appropriately minimal, though a bit more behavioral context could be added without harming conciseness.

  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?

  This is a destructive mutable operation with no explanation of consequences, recovery options, or whether recurrence handling applies. The output schema exists but the description doesn't clarify what the response indicates. For a destructive operation annotated as such, more context is needed to help the agent use it responsibly.

  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 100%, so the schema documents both parameters (event_id and calendar_id with a default of 'primary'). The description adds zero parameter information—it's a single generic sentence. With 100% coverage, baseline is 3, but the description contributes nothing and doesn't clarify edge cases like whether event_id is globally unique vs. scoped to calendar.

  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 'Delete a calendar event' uses a clear verb+resource structure. However, it doesn't differentiate from siblings beyond being the obvious delete counterpart; the purpose is clear but with no distinguishing scope or behavior detail beyond what the name already conveys.

  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 when-to-use guidance is provided. There's no mention of when deleting is appropriate, implications of deletion, or distinctions from update_event (modifying instead of removing). The tool name makes the general purpose obvious, but the description offers no context about consequences.

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

• create_eventC
  2.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, correctly implying a non-read, non-idempotent mutation. The description doesn't contradict these but also adds no behavioral context beyond what annotations convey. It doesn't disclose behaviors like whether creating an event triggers notifications, invite emails to attendees, or requires specific permissions—gaps that matter for a write operation targeting a user's calendar.

  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?

  A single, concise sentence that states the core purpose without padding. It's appropriately brief, though under-specification means it doesn't earn a 5 since it conveys almost nothing beyond the tool name itself.

  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?

  With a 7-parameter tool, an output schema, and schema coverage at 100%, the description is minimum-viable but thin. It relies entirely on the schema and annotations for behavioral and usage context. The presence of quick_add as a competing creation tool, without differentiation, leaves the agent with ambiguous selection criteria—an area the description should have addressed.

  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%, with all 7 parameters documented in the input schema. The description itself provides zero parameter information, but given full schema coverage, the baseline of 3 applies. The schema descriptions are adequate (e.g., ISO 8601 format, calendar ID defaulting to primary), so no significant compensation needed from the description.

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

  Purpose3/5

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

  The description 'Create a new calendar event' uses a clear verb+resource structure, identifying it as a creation tool distinct from siblings like update_event, delete_event, and list_events. However, it doesn't distinguish itself from quick_add, which could also create events, and the purpose is fairly generic without specifying scope (which calendar, what fields supported).

  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. quick_add is a sibling that also creates events but the description doesn't differentiate when one should be chosen over the other. No context about prerequisites (e.g., needing to select a calendar first via list_calendars) or scenarios where creating an event is appropriate.

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

• get_eventB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully covers the safety profile. The description adds little behavioral context beyond what annotations provide — it doesn't mention response format (compensated by output schema), error cases, or whether calendar_id affects behavior. With strong annotation coverage, a mid-score is appropriate since the description doesn't contradict annotations but doesn't add substantial transparency either.

  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 with zero waste. It's appropriately front-loaded with the purpose. However, it could arguably have added a bit more value (e.g., distinguishing from get_calendar) without hurting conciseness, which is why it doesn't reach a 5.

  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 read-only nature, 100% schema coverage on 2 simple parameters, strong annotations declaring safety/idempotency, and the presence of an output schema, the description is fairly complete. The main gap is the lack of explicit differentiation from get_calendar sibling. But overall, for a simple read tool, the description plus schema plus annotations cover the essentials adequately.

  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 100%, so both parameters (event_id and calendar_id) are already documented in the schema. The description itself mentions no parameters. Per the baseline rule, with high schema coverage, a score of 3 is appropriate — the schema does the heavy lifting and the description adds no extra semantic context about either parameter.

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

  Purpose3/5

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

  The description states the verb ('Get') and resource ('full details of a single calendar event'), which clearly distinguishes it from siblings like list_events (multiple events) or create_event (mutation). However, it does not explicitly contrast with its closest sibling get_calendar (which likely retrieves calendar metadata rather than an event), so sibling differentiation is only implicit. It's clear but not maximally specific about what 'full details' entails.

  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 this is a read operation for inspecting one event, which distinguishes it from list_events and create/update/delete mutations. However, no explicit when-to-use or when-not-to-use guidance is given, no mention that get_calendar is for calendar-level info, and no exclusions are stated. Usage context is implied by the verb+noun phrasing rather than stated explicitly.

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

• update_eventB
  3.2/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, which covers the safety profile. The description adds the key partial-update semantic ('Only provided fields are changed'), which is beyond what annotations convey. But it doesn't disclose what happens on missing event_id, whether attendees replace or merge, or timezone handling.

  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?

  Two concise sentences that front-load the purpose and add the partial-update semantic. Zero wasted words. Could arguably add a usage hint, but as written it's efficient and clear.

  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?

  An output schema exists, so return values are covered. The partial-update behavior is stated. However, for a mutation tool updating an event, the description doesn't clarify interaction with list_events/get_event for finding the event, doesn't mention timezone handling, and doesn't flag that attendees replacement semantics may be surprising. Could be slightly more complete.

  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 100%, with each parameter having its own description ('New start time (ISO 8601)', 'New event title', etc.). The description emphasizes the 'only provided fields changed' semantics, which clarifies the null/default field behavior encoded in the schema. Baseline 3 is appropriate since the schema carries the load.

  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 uses specific verb+resource ('Update an existing calendar event') and adds value by stating that 'Only provided fields are changed', which clarifies partial update behavior. However, it doesn't explicitly distinguish it from siblings like create_event, though the name and verb largely make this clear.

  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 vs siblings (create_event, delete_event, quick_add). It doesn't mention that the full event object exists elsewhere or that modifications affect only the calendar specified by calendar_id. No exclusions or context for choosing it over alternatives.

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

• check_availabilityA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it returns busy ranges per calendar (a useful behavioral detail beyond what annotations give), but doesn't mention edge cases like overlapping calendars, timezone handling, or empty-result behavior.

  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?

  Two sentences, both informative, no filler. Front-loaded with the core purpose. Could arguably add a usage note but for its length it's efficient and waste-free.

  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?

  With an output schema present and full schema parameter coverage plus comprehensive annotations, the description covers the essential purpose adequately. For a read-only check tool that returns busy ranges, this is reasonably complete given the structured fields carry much of the burden.

  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 all three parameters are documented in the schema itself. The description adds no parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate when the schema fully covers 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?

  Clear verb+resource ('free/busy status for calendars') with a distinctive scope (returns busy time ranges per calendar) that distinguishes it from sibling event/calendar tools. It doesn't explicitly name an alternative but the check/free-busy concept is distinct from list/get/create/update siblings.

  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 it's for checking availability, but doesn't explicitly state when to prefer this over list_events (e.g., for scheduling conflicts rather than enumerating event details). No explicit exclusions or alternatives named. The 'free/busy status' context is clear enough to infer usage but not explicitly stated.

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

• get_calendarA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-established. The description adds no additional behavioral context beyond what annotations provide — it doesn't mention rate limits, auth requirements, or what fields are returned. With strong annotations covering safety, a 3 is appropriate since the description doesn't conflict but also doesn't enrich.

  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 efficient sentence with zero waste. It's appropriately terse for a simple retrieval tool with one parameter. However, it could arguably offer one more detail about what 'details' means to aid selection.

  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 read-only tool with one parameter (fully documented), an output schema present, and comprehensive annotations, the description is largely sufficient. An output schema exists so return values don't need explanation. The main gap is the absence of an explicit note distinguishing it from list_calendars in the description itself, but the overall package is quite complete.

  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%, and the single parameter calendar_id has a clear description ('Calendar ID to retrieve') with a default of 'primary'. The description adds the word 'specific' implying the calendar is targeted by ID, which aligns with the schema. Since the schema fully documents the parameter, baseline 3 is appropriate.

  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 uses a specific verb (Get) and resource (calendar) to state it retrieves details of a specific calendar. It clearly distinguishes itself from list_calendars (which lists calendars) though it doesn't explicitly call out that distinction. It's clear but minimal.

  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 — you use this to get a single calendar's details versus listing all calendars. However, it doesn't explicitly state when not to use it or mention alternatives like list_calendars. No exclusions or explicit guidance on when this is preferred over siblings.

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

• list_eventsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds little beyond that — it mentions the JSON array return type and that it lists events, but doesn't describe pagination behavior, default time range behavior, or ordering nuances. Given the strong annotations, a 3 is appropriate.

  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, zero waste. The description is perfectly concise and front-loaded with the core purpose.

  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?

  With an output schema present, return values need not be explained. However, the description doesn't address behavior like default time windowing (today), how single_events interacts with order_by, or max_results limits — these are in the schema but their interplay isn't explained. For a 7-parameter list tool, it's adequate but not rich.

  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 100%, so all 7 parameters are documented in the schema with default values and meanings. The description adds minimal value beyond the schema — it mentions time-range filtering and JSON array return but doesn't elaborate on any parameter semantics. Baseline 3 is fair given the complete schema coverage.

  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 states a specific verb+resource ('List calendar events') and scopes it to 'within a time range', which is clear. It distinguishes from siblings like list_calendars and get_event. However, it doesn't explicitly differentiate from check_availability or get_event, though the core list-over-range purpose is evident.

  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 (listing events over a time range) but provides no explicit when/when-not guidance or alternative references. Siblings like check_availability and get_event exist but aren't mentioned as alternatives. The description relies on the reader to infer appropriate usage from the purpose.

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

• list_calendarsA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the scope ('all calendars the user has access to') and return format ('JSON array'). No mention of pagination, ordering, or whether deleted calendars are included, but with strong annotations and an output schema present, the bar is lower.

  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 short sentences, zero wasted words. The first sentence states the core purpose, and the second clarifies the return format. Nothing extraneous.

  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 zero-parameter read-only list tool with a strong annotation set (readOnlyHint, idempotentHint, destructiveHint all set appropriately) and an output schema present, the description is complete enough. It communicates scope and return type. Could add return-shape details, but the output schema likely covers that, and the tool is simple.

  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?

  There are 0 parameters and no input schema elements, so the description doesn't need to explain parameters. The description does state that it returns a JSON array, which adds value beyond the schema for the return type. With 0 parameters, a baseline of 4 is appropriate.

  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 verb ('List') and resource ('all calendars the user has access to'), making the purpose clear. It distinguishes from siblings like get_calendar and list_events by specifying it returns all calendars, not a single one. It could further differentiate by mentioning it's the collection-level tool for calendar enumeration.

  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 this is the tool for enumerating all calendars but provides no explicit when-to-use vs alternatives guidance. It doesn't mention 'use this to discover available calendars before querying events' or any exclusion criteria. There's no reference to sibling tools for comparison.

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

• quick_addA
  3.8/5.0
  Behavior3/5

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

  Annotations are all false/default (readOnlyHint false confirms this writes, which aligns). The description discloses the NLP-parsing behavior, which is the key behavioral trait. However, it doesn't mention potential side effects like how the event is committed, whether it's immediate, or what happens to the natural-language string if parsing fails. With no annotations carrying behavioral context, the description carries more burden but provides only modest disclosure.

  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, focused sentence that immediately states the verb (create), the resource (event), and the key mechanism (natural language via NLP parser). Zero waste, perfectly front-loaded with the most important differentiator.

  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 tool with 100% schema coverage, an output schema, and clear annotations, this is reasonably complete. The NLP-parsing behavior is stated. Could benefit from a note about parsing-failure behavior or what structured fields the parser produces, but given the output schema exists and the tool is conceptually simple, this is adequate.

  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%, both parameters (text, calendar_id) are fully described in the schema. The description adds the NLP-parsing context which explains how 'text' is interpreted, but doesn't add meaning beyond what the schema provides for calendar_id. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 creates events from natural language strings using an NLP parser, which distinguishes it from the sibling 'create_event' (which likely takes structured fields). It identifies the key differentiator (NLP parsing) that separates it from sibling tools. However, it doesn't explicitly name the sibling alternative, so it could be slightly stronger.

  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 this is for natural-language input and distinguishes it from structured event creation. It doesn't explicit state 'use create_event for structured input' but the NLP mention strongly signals when this tool is appropriate. The distinction from create_event is clear contextually but not explicitly stated as a when-not rule.

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