Server Quality Checklist

Tool Scores

• get_event_detailsA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry behavioral disclosure. It only states 'Get details,' which implies a read operation, but it doesn't disclose any potential errors, permissions, rate limits, or scope of returned details. The description adds little beyond the tool name.

  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 sentence of 9 words, front-loaded with the core action. No wasted words.

  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 simple (get by ID), the schema fully documents parameters, and an output schema exists to explain return values. However, the lack of any usage guidance relative to siblings or any behavioral caveats leaves the description slightly under-specified, though adequate for a basic read operation.

  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 both event_id and locale having descriptions. The description's phrase 'by its ID' generally maps to event_id but adds no additional meaning 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 ('Get') and identifies the resource ('details for a specific event') and the unique accessor ('by its ID'). This distinguishes it from sibling tools like search_events (searching) and get_event_stats (statistics).

  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 gives no explicit when-to-use or alternative guidance. However, the event_id parameter in the schema references 'from search_events results,' implying usage after searching. This is implied rather than stated.

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

• get_event_statsA
  4.1/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden. It discloses a performance characteristic ('Uses the API facets for fast, accurate counts') and a prerequisite (list_filters). However, it does not cover error conditions, authentication, or response structure, though the latter is likely covered by the output schema.

  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 sentences: the first front-loads the purpose, the second adds usage guidance and an efficiency note. 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?

  With only two optional parameters and an output schema provided, the description adequately covers purpose, a key dependency, and implementation detail. It does not need to explain return values because the output schema exists. Complete for its 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 description coverage is 100%, so the baseline is 3. The description adds 'Use list_filters first' (already echoed in the schema) and implies filter categories, but adds marginal value beyond the structured parameter descriptions.

  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: 'Get statistics about events' with specific dimensions ('counts by format, topic, product, region, etc.'). This distinguishes it from siblings: search_events (lists events), get_event_details (single event), and list_filters (returns filter categories).

  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 direct usage context: 'Use list_filters first to discover valid filter values' and notes the efficiency of 'single API call'. It lacks explicit when-not-to-use guidance compared to alternatives, but the context is clear and actionable.

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

• search_eventsA
  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 adds valuable context by stating the exact-match requirement for filter values and the mandatory prerequisite of calling list_filters. This goes beyond what the schema alone explains, though it doesn't mention read-only status 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?

  The description is exceptionally concise: two sentences with a clear purpose and an important usage note highlighted with 'IMPORTANT'. Every sentence earns its place, and the structure front-loads the core function without any redundancy.

  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's simplicity, a complete schema (100% parameter coverage), an output schema, and the description's focus on the key prerequisite and filter behavior, the description is sufficiently complete. Minor gaps include no explicit mention of the default locale or that filters are entirely optional, but these are already covered in the schema.

  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 detailed descriptions for all 3 parameters, including defaults, examples, and the directive to use list_filters. The description reinforces the filter exactness but doesn't add new parameter-level meaning beyond the schema, so the 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 clearly states the tool's function: 'Search Microsoft Events with optional filters and free-text query.' This is a specific verb (search) with a resource (Microsoft Events) and scope (optional filters, free-text). It also distinguishes itself from sibling tools like get_event_details and list_filters, making it 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 provides explicit usage guidance: 'Before searching, call list_filters first to discover the available filter categories and their exact values.' It also warns against guessing filter values, with an example. This gives clear context for when and how to use the tool, though it doesn't explicitly list exclusions for alternatives like get_event_details.

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

• list_filtersA
  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 transparency burden. It discloses that the tool returns event counts and exact accepted pairs, implying it is a read-only enumeration tool. It does not explicitly mention side effects, but none are expected. The behavioral context is useful beyond the name itself.

  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 sentences, front-loaded with the main purpose, and the second sentence provides essential usage guidance. Every sentence is purposeful and there is no redundant or verbose language.

  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 list tool with one optional parameter and an output schema, the description fully covers what the tool does, when to use it, and what it returns. No additional detail about return formatting is needed since an output schema exists.

  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 covers the only parameter (locale) with a description and default. The tool description does not add parameter-specific meaning, but since schema coverage is 100%, the baseline of 3 applies. The description does not need to elaborate further.

  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 lists all available filter categories with their exact values and event counts. This specific verb ('list') and resource ('filter categories') distinguishes it from siblings like search_events and get_event_details, which focus on different operations.

  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?

  Explicitly instructs to call this tool first before using search_events or get_event_stats with filters, and notes it returns the exact category:value pairs the API accepts. This gives clear when-to-use guidance and differentiates it from sibling tools.

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