Server Quality Checklist

Tool Scores

• get_category_breakdownA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions what data is shown (categories with time and productivity classification) but doesn't disclose important behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, or what happens with invalid dates. The description doesn't contradict annotations since none exist.

  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 appropriately sized and front-loaded with the core purpose. The parameter documentation is structured clearly with 'Args:' section. While efficient, the second paragraph about categories could be more tightly integrated with the main purpose statement.

  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 moderate complexity (single parameter, categorical analysis), the presence of an output schema, and the description's good parameter coverage, this is reasonably complete. The description explains what the tool returns (categories with time and productivity classification), which complements the output schema. However, more behavioral context would improve completeness.

  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?

  With 0% schema description coverage and only 1 parameter, the description fully compensates by providing complete parameter semantics. It explains the date_str parameter's purpose, format options ('today', 'yesterday', or 'YYYY-MM-DD'), and even provides a default value. This adds significant value beyond the bare 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 clearly states the tool's purpose: 'Get time spent by category' with specific resource (time) and classification (by category). It distinguishes from siblings by focusing on categorical breakdown rather than hourly data, trends, or summaries. However, it doesn't explicitly contrast with each sibling tool.

  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 through the parameter explanation and examples of categories returned, but doesn't explicitly state when to use this tool versus alternatives like get_hourly_productivity or get_productivity_trend. No exclusions or prerequisites are mentioned.

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

• get_hourly_productivityA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'Shows when during the day you were most/least productive' which gives some behavioral context about the output format. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, what permissions might be required, whether data is real-time or cached, or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps.

  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 perfectly structured and concise. It begins with the core purpose, provides parameter documentation in a clear 'Args:' section, then adds usage context. Every sentence earns its place, with no wasted words or redundant information. The information is front-loaded with the most important details first.

  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 that there's an output schema (which handles return values), 1 parameter, and no annotations, the description does a reasonably complete job. It explains the tool's purpose, documents the parameter, and provides usage context. The main gap is the lack of behavioral transparency about permissions, data freshness, or operational constraints, which would be important for a productivity tracking tool.

  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 description explicitly documents the single parameter 'date_str' with its allowed values ('today', 'yesterday', or 'YYYY-MM-DD'), which adds crucial meaning beyond the schema's 0% description coverage. However, with only 1 parameter total, the baseline expectation is higher. The description compensates well for the schema's lack of documentation but doesn't provide additional context about parameter behavior beyond the basic format.

  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's purpose: 'Get productivity breakdown by hour' specifies the verb ('Get') and resource ('productivity breakdown by hour'). It distinguishes from siblings like 'get_today_summary' by focusing on hourly granularity rather than daily summaries, though it doesn't explicitly contrast with all siblings like 'get_category_breakdown' or 'get_productivity_trend'.

  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: 'Useful for identifying peak productivity hours and scheduling deep work.' This gives practical application guidance. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which would be needed for a perfect score.

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

• get_productivity_trendA
  3.6/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 tool 'Shows the daily productivity pulse with visual bars and calculates averages,' adding behavioral context about output format and calculations. However, it lacks details on permissions, rate limits, or data sources, which are important for a tool with no annotation coverage.

  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 appropriately sized and front-loaded, starting with the core purpose, followed by parameter details and usage context. Each sentence adds value: the first defines the tool, the second explains the parameter, and the third describes output and utility. There's minimal waste, though it could be slightly more structured with bullet points.

  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 has one parameter, no annotations, but an output schema exists, the description is fairly complete. It covers the purpose, parameter semantics, and output behavior ('Shows... visual bars and calculates averages'). The output schema likely handles return values, so the description doesn't need to detail them. However, it could improve by addressing sibling tool differentiation or authentication needs.

  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?

  The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'days' parameter as 'Number of days to look back' with a default and max value, clarifying its purpose and constraints. Since there's only one parameter, this compensates well for the schema gap, though it could mention data types or validation rules.

  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's purpose: 'Get productivity pulse trend for the last N days.' It specifies the verb ('Get') and resource ('productivity pulse trend') with a temporal scope ('last N days'). However, it doesn't explicitly differentiate from sibling tools like 'get_hourly_productivity' or 'get_today_summary' beyond mentioning 'daily' productivity pulse.

  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 by stating it's 'Useful for identifying patterns and trends over time,' which suggests when to use this tool. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'get_today_summary' or 'get_hourly_productivity,' nor does it mention any exclusions or prerequisites.

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

• get_today_summaryA
  3.7/5.0
  Behavior2/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 describes what the tool returns (productivity pulse, total time, breakdowns, percentages), which adds useful context beyond the input schema. However, it lacks details on behavioral traits such as authentication needs, rate limits, or whether it's a read-only operation, leaving gaps for a mutation tool with zero annotation coverage.

  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 appropriately sized and front-loaded, starting with the main purpose and followed by a clear list of return values. Every sentence earns its place by providing essential information without waste, making it highly efficient.

  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 complexity (simple read operation), 0 parameters, and the presence of an output schema, the description is mostly complete. It explains the return values in detail, which compensates for the lack of annotations. However, it could be more complete by addressing potential behavioral aspects like data freshness or limitations, but the output schema likely covers return structure, so it's not a critical gap.

  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?

  The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description doesn't need to add parameter information, and it doesn't introduce any confusion, making this appropriate for a no-param tool.

  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's purpose with the verb 'Get' and resource 'today's complete RescueTime productivity summary.' It distinguishes from siblings by specifying 'today's complete' summary rather than activity data, category breakdowns, hourly productivity, or trends. However, it doesn't explicitly contrast with each sibling tool, so it's not a perfect 5.

  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 with 'This is the recommended daily check-in tool,' which indicates when to use it. It implies usage for daily productivity overviews but doesn't explicitly state when not to use it or name alternatives like the sibling tools for more specific data, so it falls short of a 5.

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

• get_activity_dataA
  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 discloses that the tool shows 'specific applications and websites you spent time on, ranked by duration' and includes 'productivity classification for each,' which adds behavioral context about output format and ranking. However, it doesn't mention permissions, rate limits, or data freshness, which are gaps for a tool with zero annotation coverage.

  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 well-structured and front-loaded with the core purpose, followed by parameter details and additional context. Every sentence adds value: the first states the purpose, the Args section clarifies parameters, and the last two sentences explain output details. No wasted words or 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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, parameter semantics, and output behavior (ranking, productivity classification). The output schema likely handles return values, so the description doesn't need to detail them. Minor gaps include lack of error handling or data source context.

  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 description coverage is 0%, so the description must compensate. It adds meaningful semantics for both parameters: date_str specifies allowed values ('today', 'yesterday', or 'YYYY-MM-DD') and limit explains its purpose ('Maximum number of activities to show') with a default. This goes beyond the schema's basic type/default info, though it doesn't cover all possible edge cases.

  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 with specific verbs ('Get top activities/applications by time spent') and resources ('activities/applications'). It distinguishes from siblings by focusing on specific applications/websites ranked by duration, unlike category breakdowns, hourly productivity, trends, or summary tools.

  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 through its purpose statement but doesn't explicitly state when to use this tool versus alternatives like get_category_breakdown or get_today_summary. No explicit when-not or alternative guidance is provided, leaving usage context inferred rather than clearly defined.

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