Server Quality Checklist

Tool Scores

• find_common_availabilityB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the burden of disclosing side effects, input requirements, and operational behavior. It only lists parameters and a terse summary, without stating that it reads a poll, what happens with invalid URLs, or any mutation/read-only guarantees.

  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 compact: a one-line summary followed by a bullet-style Args list with no filler. Each parameter line adds distinct information, and the structure is scannable for an agent.

  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 parameter semantics are well covered and an output schema exists, so the agent can understand the return shape. However, the lack of usage guidance and behavioral disclosure (e.g., that this reads a third-party poll, or how failures are handled) leaves meaningful gaps for a tool with five parameters and no annotations.

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

  Parameters5/5

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

  Schema description coverage is ​0%, but the Args block explains all five parameters with meaningful semantics: URL is the when2meet poll, timezone is IANA for slot labels, participant_names is an optional subset, min_participants controls the threshold, and only_marked_participants excludes unmarked users. This goes well beyond the raw 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 states a specific verb-resource pair ('Find times when participants overlap') and identifies the when2meet poll context. It is clear, but it does not explicitly differentiate from sibling tools like compute_availability_from_busy_times, which could also produce availability overlaps.

  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?

  There is no guidance on when to choose this tool over the listed siblings, and no exclusions or prerequisites are stated. The only implicit signal is the 'when2meet poll URL' parameter, which suggests the input context but does not say when this is the right tool.

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

• preview_availabilityA
  3.5/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 discloses that the action validates and previews rather than submits, which implies no mutation, but it does not explicitly state that no poll changes are made or describe invalid-index error 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?

  The one-sentence purpose is front-loaded and the Args bullets are minimal and informative. The arg list duplicates schema names but is warranted because the schema has no field descriptions.

  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 3-param preview tool with an output schema, it covers purpose and all parameter semantics. It is less complete on routing: no explicit relation to submit_availability and no explicit statement that it does not modify the poll, which matters given there are no annotations.

  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 0% schema coverage, the Args block adds valuable meaning: 'Zero-based indices' disambiguates slot_indices, and 'IANA timezone for labels' explains timezone's role. url's meaning is obvious from its name and context but is still included.

  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 opens with a clear verb-resource pair: validate slot indices and preview availability, and the 'before submitting' clause distinguishes it from the sibling submit_availability. It could be stronger by explicitly naming that sibling, but the intended operation is recognizable.

  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?

  'before submitting' gives an implied usage context: call this as a dry-run ahead of submission. It does not name any alternative tools or state when not to use it, so an agent must infer routing from the tool name and sibling list.

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

• compute_availability_from_busy_timesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It does convey that this is a computation ('Compute free slots') and explains key transformations like buffer expansion and daily cutoffs. However, it does not state whether the url is fetched over the network, whether the operation is read-only, or what side effects, if any, occur.

  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 compact and well-structured: a one-sentence purpose statement followed by a tight argument list with no filler. Every line conveys necessary information for invoking the tool correctly.

  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 computation-focused tool, the description covers the core purpose and all parameter semantics, and the presence of an output schema means return values need not be described. It is slightly incomplete only in usage guidance and behavioral side-effect disclosure, which prevents a perfect score.

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

  Parameters5/5

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

  The input schema has 0% description coverage, but the description fully compensates by documenting all eight parameters with types and meanings. It clarifies the ISO-8601 shape of busy_times, the IANA timezone default, the week_start_date inference behavior, all-day dates, buffer_minutes, and daily cutoffs. This exceeds what the schema provides.

  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 clear verb-resource pair: 'Compute free slots from ISO calendar busy intervals.' It also provides a parameter list that reinforces the function's scope. However, it does not explicitly distinguish itself from siblings like find_common_availability or preview_availability, leaving some differentiation to inference.

  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 is given about when to choose this tool over its siblings. There is no mention of alternatives, exclusions, or the specific scenario where computing availability from busy times is preferable to finding common availability or previewing availability. The usage context is only implied by the tool name and description.

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

• get_pollA
  3.9/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 does warn that include_slots can return hundreds of entries and clarifies timezone affects labels, but it doesn't explicitly state that this is a read-only network fetch or describe failure behavior for invalid URLs/polls.

  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 one-line summary is followed by a compact Args block with no redundant prose. Every sentence carries useful information, including the scale warning about slot indices.

  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 all three parameters documented, the description is functionally sufficient to call the tool correctly. It lacks only a brief relationship note to sibling tools and explicit error/network caveats, which keep it from a 5.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the Args section compensates fully: url gets a concrete example, timezone gets an IANA example, and include_slots explains the large-output consequence. This adds real meaning beyond the JSON schema's bare property names and defaults.

  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 first sentence names a specific verb (load) and resource (when2meet poll) and lists the returned data: title, participants, time range, and optional slot grid. This clearly differs from sibling tools that compute or submit availability, so an agent can distinguish it without opening schemas.

  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 sentence states when to call get_poll versus siblings like find_common_availability or preview_availability, nor any prerequisite or exclusion. The only usage signal is the implied retrieval role, which is not enough guidance for tool selection.

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

• fill_from_weekly_scheduleA
  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 full behavioral burden and does well: it discloses dry_run default true for safety, on_name_conflict resolution modes, password requirement when returning to an existing name, and expansion/blocking semantics for buffer_minutes, block_efore, and block_after. It could add more about side effects on repeated calls, but key behaviors are covered.

  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 structured with a concise summary line, a key matching note, and a flat args list. Every line adds information needed to invoke the tool correctly; no filler or repetition. Despite length, it earns its space for an 11-parameter tool.

  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 complex, schema-poor, annotation-free tool, the description is nearly complete: it covers matching logic, all parameters, safety default, and conflict handling. Minor gaps remain around edge cases (e.g., overlapping busy blocks, exact suffix format for alternate_suffix), but an output schema exists and the essential invocation context is present.

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

  Parameters5/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 carry all parameter meaning. It does: all 11 parameters are individually explained with types, defaults, examples, and special values (e.g. on_name_conflict options, buffer, block_cutoffs, agent_name defaulting to env var). This exceeds what the sparse schema provides.

  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 opens with a specific verb+resource: 'Fill a poll from recurring weekly busy blocks' and adds a clear use case ('best for class schedules'). It also distinguishes itself by noting it matches by weekday + local time and needs no week_start_date, cementing its unique role among siblings.

  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 clearly scopes usage to recurring weekly busy blocks and class schedules, and explains the matching mechanism (weekday + local time) rather than dates. It doesn't explicitly name sibling tools as alternatives or list when-not-o-use conditions, so it stops short of full exclusion guidance.

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

• submit_availabilityA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses the safe default with 'dry_run: Preview only (default true for safety)', explains name-conflict behavior, and notes password and timezone handling. It could be more explicit about permanent effects when dry_run is false, but the safety default and conflict behavior are valuable disclosures.

  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 tightly structured as a one-line purpose followed by a compact argument list. Each parameter gets a single useful line, and no filler or redundant prose softens the value. The safety rationale for dry_run is the only extra detail and it earns its place.

  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 an 8-parameter tool with no annotations and zero schema coverage, this description is remarkably complete. It explains all parameters, relevant defaults, conflict handling, and safety behavior. The presence of an output schema means return values do not need to be described here.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description fully compensates. Every parameter is explained in useful terms: 'Zero-based slot indices', 'IANA timezone', 'when password fails for existing name', and the meaning of on_name_conflict values. This far exceeds the bare 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 begins with a specific verb-resource pair: 'Sign in and mark availability on a when2meet poll.' This clearly distinguishes it from sibling tools like get_poll, preview_availability, and find_common_availability, which have different purposes. The additional argument documentation reinforces the operational 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 opening sentence provides clear context: the tool is for marking availability, so an agent can infer when to use it. It does not explicitly name sibling alternatives or state when not to use it, but the purpose is unambiguous enough that the use case is recognizable.

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