Server Quality Checklist

Tool Scores

• log_habitB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states the action but doesn't mention side effects like idempotency, overwriting previous logs, or the special behavior for pullup_gtg requiring rep counts. For a mutation tool, this is a significant gap.

  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 a single, front-loaded sentence with no filler, achieving maximum efficiency. However, it omits important behavioral details that could be incorporated without much length, so it's concise but slightly under-specified.

  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?

  This simple 2-param tool has no annotations and relies on the description for context. The description fails to address idempotency, validation errors, or the conditional nature of pullup_reps, rendering it incomplete for a safe mutation 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 coverage is 100%: both parameters have detailed descriptions, including enum-like values for habit_name and conditional use for pullup_reps. The tool description adds no semantic value beyond restating 'habit', so the baseline 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 a specific verb ('Mark') and resource ('habit as completed for today'), making the tool's core function immediately clear. It also distinguishes itself from the sibling read-only tools (get_today_status, get_streak, get_mission_overview) which are all queries.

  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 on when to use this tool vs alternatives, nor any context about habit validation, prerequisites, or when not to log. The sibling names imply read-only tools, but the description doesn't explicitly exclude or compare, leaving usage to inference.

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

• get_streakA
  3.9/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 indicates a read-only operation via 'Returns' but does not disclose behavior for invalid habit names, missing logs, or timezone calculations. This is adequate for a simple getter but not rich in edge-case context.

  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 one concise, front-loaded sentence that states exactly what the tool does. No wasted words or redundant 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?

  The tool is simple with one parameter fully documented in the schema and an output schema present. The description clearly identifies the purpose, making it sufficient for an agent to select and invoke correctly. No additional context is necessary.

  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 the single parameter 'habit_name' fully described. The tool description adds no additional parameter semantics 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 the tool returns the current consecutive-day streak for a specific habit, using a specific verb ('Returns') and resource. It distinguishes this from sibling tools like log_habit, get_today_status, and get_mission_overview by focusing on the streak metric.

  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 usage is implied: use it when you need a habit's streak. However, there is no explicit guidance on when to prefer this over siblings, nor any exclusions or prerequisites. It is a simple, self-explanatory tool but lacks explicit alternatives.

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

• get_mission_overviewA
  4.3/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 disclosure burden. It clearly indicates a read-only operation via 'Returns' and details the exact computed metrics included. However, it does not explicitly state that the tool has no side effects or mention any prerequisites, which is acceptable for a simple getter but could be slightly more 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 front-loaded with the main purpose and uses three concise bullet points to list key data points. Every sentence earns its place with no redundant fluff, making it easy to parse.

  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 zero-parameter tool with an output schema, the description fully communicates the tool's scope and value. It explains what the overview includes and contrasts implicitly with sibling tools, providing sufficient context for an agent to select and invoke it correctly.

  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?

  This tool has zero parameters, and the baseline for 0-param tools is 4. The description does not need to explain parameter syntax or meaning since there are none, and the schema coverage is trivially complete.

  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 'Returns a full 90-day mission progress overview' and enumerates specific content (days elapsed/remaining, habit completion rates, total GtG reps). This verb+resource phrasing distinguishes it from siblings like get_today_status and get_streak, which focus on narrower scopes.

  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 the tool is for mission-level progress reports rather than daily or streak-specific queries, but it does not explicitly state when to choose this over alternatives or provide exclusions. The context is inferable from the tool name and content list, but explicit guidance is absent.

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

• get_today_statusA
  4.3/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. It is transparent about the today scope and the data returned, and 'Returns' implies a read-only operation. However, it does not disclose response format or potential error cases, though these may be 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 a single sentence that front-loads the action and resource ('Returns a full dashboard') and then enumerates the specific content. Every word earns its place with no redundancy.

  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 zero parameters, an existing output schema, and a simple read-only purpose, the description covers all necessary context. It names the three key data categories and the temporal scope, leaving no significant gaps for an agent.

  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 tool has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter information because none exists.

  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 what the tool does: 'Returns a full dashboard' with specific components (habits done/not done, pull-up GtG reps, mission progress). This distinguishes it from siblings like log_habit (a write action) and get_streak (a single metric).

  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?

  No explicit guidance on when to use this versus alternatives, but the description implies it is the primary tool for a daily status overview. Lacks explicit exclusions or references to sibling tools, but the purpose is clear enough for an agent to infer typical usage.

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