Server Quality Checklist

Tool Scores

• get_current_statusA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden for behavioral disclosure. The verb 'Show' implies a read-only operation, but the description does not explicitly state that no state changes occur or describe any edge cases like empty results. It does add useful context about the scope ('currently running or paused') and output ('elapsed time').

  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 containing only essential information. It is front-loaded with the verb and object, and every word adds value. No redundancy or filler.

  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 (one optional parameter, no output schema, no annotations), the description adequately conveys the core purpose. It does not detail return structure or behavior when no activities are active, but it covers the essential information for a status query.

  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 provides a full description for the single 'timezone' parameter (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already 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 clearly states the tool's function with a specific verb ('Show') and a specific resource ('currently running or paused activities with elapsed time'). This clearly distinguishes it from sibling tools like start_activity or time_report, which have different purposes.

  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 checking current activity status, but does not explicitly state when to use this tool versus alternatives such as time_report or list_intervals. No alternatives are named or excluded, leaving the usage context somewhat inferred.

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

• log_intervalA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It adds useful context about wall-clock times and the user's timezone, and the 'yyyy-MM-dd HH:mm' format. However, it does not state whether the operation is idempotent, what happens on success, or any permission requirements, leaving gaps in behavioral transparency.

  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, front-loaded sentence that conveys essential information without any fluff. It is concise yet informative.

  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?

  Despite having 7 parameters and no output schema or annotations, the description provides only the core purpose and time format. It omits details about return values, parameter dependencies, and error conditions. For a tool of this complexity, the description is insufficiently 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 71%, so the baseline is around 3. The description clarifies the time format and timezone, which adds meaning to the from, to, and timezone parameters. It does not clarify the relationship between type_id and type_name, nor the semantics of tags and comment, so it doesn't fully compensate for the uncovered parameters.

  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 purpose: to retroactively log a completed time entry for an activity type. The verb 'log' combined with 'retroactively' distinguishes it from sibling tools like start_activity and stop_activity, which handle current sessions.

  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 'retroactively log a completed time entry' provides clear context: this tool is for past entries, not current tracking. It implies when to use it, but it does not explicitly name alternatives or exclusions. The context is strong enough that an agent would understand when to invoke this tool.

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

• time_reportA
  3.8/5.0
  Behavior3/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 the return format ('overall totals plus per-DAY/WEEK/MONTH buckets') and implies read-only behavior via 'Returns', but it does not describe filtering behavior, timezone handling, or potential edge cases. It adds some value beyond the schema's parameter descriptions.

  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, compact sentence that is front-loaded with the core purpose and output summary. Every phrase earns its place, with no fluff or repetition.

  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 absence of an output schema and annotations, the description gives a clear high-level picture but omits details like filtering options (tags, type_ids) and period alternatives. However, since the input schema has exhaustive descriptions for all 8 parameters, the description doesn't need to list them. It is complete for the tool's primary role as a summary report.

  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 baseline is 3. The description does not add significant parameter semantics beyond the schema; it reiterates the grouping concept ('per-DAY/WEEK/MONTH') which is already in the group_by enum description. It provides no new details on format or relationships.

  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: 'Aggregated time statistics per activity type for a date range' and specifies the output structure ('overall totals plus per-DAY/WEEK/MONTH buckets'). This distinguishes it from sibling tools like list_intervals or start_activity, which handle raw data or actions.

  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 getting summaries vs raw intervals ('Aggregated' vs list_intervals), but it does not explicitly state when to use this tool over alternatives or mention any exclusions or prerequisites. No direct comparison to siblings is provided.

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

• pause_resume_activityA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It states the core state transition (running to paused, paused to running) but does not disclose edge cases, prerequisites (e.g., needing a currently active activity), or any potential side effects like what happens if no matching activity exists.

  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, front-loaded sentence that says everything essential in nine words. No wasted words or filler, ideally concise.

  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 state-toggle tool with one required enum parameter and two well-described optional disambiguators, the description plus schema is sufficient to guide invocation. It lacks explicit return-value or error information, but given the tool's low complexity, this is a minor gap rather than a critical omission.

  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 already provides descriptions for type_name and activity_id (67% coverage), and the tool description reiterates the pause/resume distinction that maps to the action enum. However, the description adds no new parameter-level detail beyond the schema, so it does not significantly compensate for the undocumented action 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 uses specific verbs ('Pause', 'resume') with a clear resource ('activity') and target state ('running', 'paused'). It unambiguously distinguishes this tool from the sibling start_activity and stop_activity tools by focusing on pause/resume semantics.

  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 conditions for use: pause a running activity or resume a paused one. It does not explicitly mention alternatives or exclusions, but the conditional phrasing gives clear context for when to invoke the tool.

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

• list_activity_typesA
  4.1/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. It discloses that the output is a tree structure with names and internal ids, and implies a read-only operation. However, it does not mention whether only active types are returned by default, how archived types are handled (though the schema covers that), or any other behavioral nuances like authentication or error conditions. Acceptable but not rich.

  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, compact sentence that immediately states the core purpose and output format. It adds usage guidance in the second half without any waste. Every word 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 a simple read-only listing tool with one optional parameter and no output schema, the description fully covers what the tool does, what it returns, and how to use its results. It is complete in context, especially given the sibling tools are action-oriented and this one serves as a lookup.

  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 single parameter include_archived is fully documented in the schema with a default value and description. The tool description adds nothing beyond the schema, but since schema coverage is 100%, 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 uses the specific verb 'List' and identifies the resource as 'the user's activity types', while clarifying the output format as a tree with groups and children. This clearly distinguishes it from siblings like start_activity or get_current_status, which perform actions or retrieve different data.

  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 guidance on when to use this tool: to get names and ids. It also tells the user how to use the output ('Use the names when talking to the user; use the ids for exact targeting in other tools'), which effectively communicates its role among other tools. It doesn't explicitly state when not to use it, but the context is strong.

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

• start_activityA
  4.2/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. It does disclose the fuzzy matching behavior for type_name and the backdating capability via `at` or started_minutes_ago, which is useful. However, it does not disclose what happens if an activity is already running (e.g., whether it is replaced or rejected), nor any side effects or preconditions, leaving gaps in transparency.

  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 primary action, and each phrase contributes meaning (fuzzy matching, list_activity_types pointer, backdating options). No filler, ideal conciseness.

  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 description covers the main usage patterns effectively: how to specify the activity type and how to backdate. Minor gaps exist, such as not explicitly stating mutual exclusivity between type_name and type_id, and not clarifying behavior when called during an active activity. Given the tool's simplicity, it is mostly complete.

  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?

  Schema coverage is 100%, giving a baseline of 3. The description adds value by introducing the "fuzzy matched" behavior for type_name (not present in schema), explicitly framing type_name and type_id as alternatives, and clarifying that `at` is wall-clock. This goes beyond schema 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: "Start tracking an activity" with specific methods (by type name or type_id). It distinguishes itself from siblings by focusing on the start action and references list_activity_types for type resolution, 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 description provides clear context for when to use the tool: to begin tracking an activity. It also points to list_activity_types as a prerequisite for type_name, which helps the agent. However, it does not explicitly mention alternatives like stop_activity or log_interval or exclusions, so it lacks the explicit when-not guidance of a 5.

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

• stop_activityA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It reveals the ambiguity-resolution rule for type_name and the backdating options, but does not state side effects (e.g., whether this ends the interval permanently), permissions, or 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.

  Conciseness5/5

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

  Two sentences, front-loaded with the core action, no filler. Every clause adds operational insight.

  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 5 parameters fully documented in the schema and the absence of an output schema, the description covers the main action, backdating, and the conditional type_name behavior. It is sufficient for correct invocation, though it leaves edge-case behavior (multiple active activities without type_name) implicit.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by linking `at` and `stopped_minutes_ago` as alternative backdating methods and clarifying when type_name is optional, which goes beyond the schema 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 specifies the action ('Stop') on the resource ('activity') and extends to both running and paused states, clearly differentiating from siblings like pause_resume_activity or start_activity. The verb and resource are specific and 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?

  It provides context that type_name can be omitted when exactly one activity is active, guiding conditional parameter handling, but does not explicitly compare to pause_resume_activity or log_interval, so exclusions are 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.

• list_intervalsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, description discloses key behaviors: grouping, paging, and maximum range. It gives meaningful operational context beyond just saying 'list intervals'. Could be richer but sufficient for a read-only listing tool.

  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 front-loaded with purpose and paging detail. Every word earns its place with no waste.

  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 9 parameters, no output schema, and no annotations, the description gives the core behavioral model (grouped, paged, max range). It's adequate for a developer to infer usage, though a bit more on period vs from/to interaction would push it higher.

  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?

  Schema already provides 100% coverage for all 9 parameters. Description adds context about 'max 100 days' and 'paged by day' that ties into from/to and page/size, enhancing understanding without duplicating schema 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?

  Description clearly states the tool lists raw time entries (intervals) grouped by day for a date range, with a specific verb and resource. The 'raw' qualifier distinguishes it from sibling tools like time_report or log_interval.

  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?

  Provides clear usage context: date range limited to 100 days and paging by day. Does not explicitly mention alternatives or when not to use, but the distinction from siblings is implied by 'raw'.

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