Server Quality Checklist

Tool Scores

• update_subcalendarB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations; it doesn't explain the destructiveHint or idempotentHint, nor any side effects like impacts on references or permissions.

  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 clear sentence plus a documentation link, with no filler or redundancy.

  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?

  For a simple rename tool, the description states the core purpose, but it lacks usage guidance and doesn't describe return behavior or side effects. Given no output schema, this leaves some gaps, though the operation is relatively straightforward.

  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?

  The input schema already provides descriptions for both parameters with 100% coverage. The description adds no additional semantic information beyond what the schema offers, so a baseline score of 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 uses the specific verb 'Rename' and clearly identifies the target resource as an existing kalender.digital subcalendar. This distinguishes it from sibling tools like create_subcalendar and delete_subcalendar.

  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, such as prerequisites or when renaming is preferred over create/delete. It only states the action without context.

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

• create_subcalendarA
  3.7/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint=false), and the description is consistent with that. It adds no extra behavioral context such as auth requirements, side effects, or return values. The API documentation link offers some value but is not explicit.

  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 two concise sentences, front-loaded with the purpose and followed by a documentation link. Every word earns its place, with no unnecessary filler.

  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 is simple with only one parameter, but the description does not explain what the call returns (e.g., the created subcalendar ID). The API link provides a path to more details, but the description alone is not fully complete for an agent to know the output.

  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% for the single parameter 'name', and the schema description says 'Name of the new subcalendar'. The tool description does not add further detail beyond what the schema already provides, so the baseline of 3 applies.

  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 kalender.digital subcalendar' with a specific verb and resource. It distinguishes from sibling tools like create_event and update_subcalendar by naming the resource type.

  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 when to use it (to create a subcalendar) but provides no explicit guidance on when not to use it or alternatives. It does not mention prerequisites or differences from update_subcalendar or create_event.

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

• update_eventA
  3.8/5.0
  Behavior4/5

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

  Annotations already flag this as a destructive, non-read-only mutation. The description adds the key behavioral trait of full replacement ('replace all editable fields') and the constraint that all fields must be provided, which is useful beyond the annotations. However, it doesn't discuss side effects or response behavior, keeping it slightly above baseline.

  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 concise, with the purpose front-loaded in the first sentence and an API link for details. However, the misleading 'all fields required' statement reduces its overall value, preventing a perfect score.

  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?

  With 11 parameters, no output schema, and a destructive mutation, the description is too sparse. It doesn't mention return values, error conditions, or clarify the required/optional distinction, and it contains a misleading requirement statement. The API link mitigates but doesn't compensate for these gaps.

  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% (baseline 3), but the description's claim 'All event fields are required' directly contradicts the schema, where only 5 of 11 parameters are required and others have defaults. This is misleading and could cause an AI to think it must supply optional fields, adding harmful semantics 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 clearly states the tool's action: 'Replace the editable fields of an existing kalender.digital event.' The verb 'replace' plus 'existing' differentiates it from create_event (for new events) and delete_event (for removal), making the 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 phrase 'existing event' provides clear context that this tool is for modifying already-created events, implying it should not be used for creation. However, it doesn't explicitly name alternative tools like create_event or state 'use create_event for new events,' so it lacks explicit when-not and alternatives.

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

• create_eventA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate a write operation (readOnlyHint=false) and non-idempotence. The description adds useful context that events can be created in multiple subcalendars, which is beyond the annotations. It does not contradict annotations, though it doesn't elaborate on return values or 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?

  The description is a single sentence that front-loads the primary purpose and includes a helpful API documentation link. It is compact with no filler or redundant information.

  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 10 parameters and no output schema, the description is minimal. It offers a link to API documentation, which may compensate, but the description itself lacks details on return behavior or operational nuances. For a create tool, this leaves some gaps.

  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?

  With 100% schema coverage, the baseline is 3. The description does not add explicit detail on any specific parameter, though it implicitly highlights subCalendars by mentioning 'one or more subcalendars'. No extra semantic meaning is provided 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 the specific verb 'Create' and identifies the resource as an event, while additionally noting it can target 'one or more kalender.digital subcalendars'. This clearly distinguishes it from sibling tools like update_event and delete_event.

  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 use for creating events but gives no explicit comparison to alternatives such as update_event or delete_event, nor does it state when not to use this tool. The API link provides external reference but no direct usage guidance.

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

• delete_subcalendarA
  3.9/5.0
  Behavior3/5

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

  Annotations already flag the operation as destructive, and the description adds 'permanently', clarifying irreversibility. However, it does not disclose critical behavioral details such as whether deleting a subcalendar also deletes its events or whether it fails if non-empty, leaving a gap beyond what annotations provide.

  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 sentence stating the core action, followed by an API documentation link. It is front-loaded, efficient, and free of redundancy.

  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?

  For a simple one-parameter delete tool, the description covers the basic action, but lacks details on side effects (e.g., cascading deletes, prerequisites) and success/failure behavior. Annotations and schema help, but the description alone is minimally 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?

  The schema has 100% coverage and describes subcalendarId as 'kalender.digital subcalendar ID'. The description adds no additional parameter semantics, but this is acceptable given the schema's completeness.

  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 'Permanently delete a kalender.digital subcalendar', specifying the verb (delete), the resource (subcalendar), and permanence. This distinguishes it from sibling tools like delete_event and update_subcalendar.

  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 purpose itself makes the usage context clear: use this when you need to permanently remove a subcalendar. It does not explicitly state when not to use or mention alternatives, but the action is unambiguous and there is no alternative deletion tool for subcalendars.

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

• delete_eventA
  4/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the 'permanently' qualifier, indicating irreversibility, which is useful. However, it doesn't disclose additional behavioral details like auth requirements or error handling.

  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, consisting of a single sentence plus a documentation link. It front-loads the verb and resource, with no unnecessary wording.

  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 low complexity, complete schema, and informative annotations, the description is adequately complete. It mentions the permanent nature and provides a documentation link, though it omits handling of edge cases like missing permissions or non-existent events.

  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?

  The input schema provides 100% coverage for eventId with a clear description ('kalender.digital event ID'). The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.

  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 'Permanently delete a kalender.digital event by ID,' which identifies the verb (delete), resource (event), and scope (by ID). This distinguishes it from siblings like delete_subcalendar and other event operations.

  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 that this tool is for deleting events by ID, which aligns with the title and separates it from subcalendar operations. However, it does not explicitly mention when not to use it or suggest alternative tools for other resource types.

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

• list_eventsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive. The description adds behavioral details: the date range is inclusive and a search query can filter events. It also provides an API documentation link. 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.

  Conciseness5/5

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

  One concise sentence immediately states the verb and scope, followed by a useful documentation link. No wasted words or redundant repetition of schema information.

  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?

  Given the simple read-only nature, full schema coverage, and rich annotations, the description is sufficient. It clearly conveys the core behavior, and the return value (a list of events) is implied by the tool name and description. The API link provides additional detail if needed.

  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 descriptive parameter documentation, so the description does not need to add much. It mentions 'search query' and 'inclusive date range', which align with the query and date parameters, but these are already in the schema. 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 action ('List'), the resource ('kalender.digital events'), and the scope ('within an inclusive date range, optionally filtered by a search query'). This distinguishes it from siblings like get_event (single event) and mutation tools.

  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?

  It provides clear context for when to use the tool (listing events in a date range with optional filtering), but does not explicitly mention alternatives or when-not-to-use, such as using get_event for a single event. The context is unambiguous, so this is above baseline.

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

• get_eventA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it fetches a single event by ID, and provides an API documentation link for further detail, which is useful context beyond the annotations.

  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 concise sentences plus a documentation link, with the primary action front-loaded. No filler or repetition of schema details.

  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 fetch tool with rich annotations and a complete schema, the description covers the core operation and offers an alternative for unknown IDs. It does not detail return format, but this is a minor gap given the tool's simplicity and the external documentation link.

  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 the schema already defines both eventId and timeZone. The description only reinforces the role of eventId, adding no new semantics for timeZone. Thus baseline 3 applies.

  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 'Fetch one kalender.digital event by its event ID' with a specific verb and resource, and explicitly contrasts with list_events, making the tool's purpose unambiguous. The sibling context further distinguishes it from update/delete/create tools.

  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?

  It provides an explicit alternative and condition: 'Use list_events if the ID is unknown', which directly addresses the most common ambiguity. This is clear when-to-use guidance relative to sibling tools.

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