Server Quality Checklist

Tool Scores

• read_health_dataA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden. It clearly indicates the operation is a read from a local database, implying no mutation, and enumerates the data domains. It does not disclose potential behaviors like pagination, empty-result handling, or timezone assumptions, but output schema plus 'read' cover the essential safety profile.

  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 single, front-loaded sentence states the operation, source, and the complete list of metrics with units. There is no filler or repetition of schema details.

  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 read tool with no required parameters, a rich input schema, and an output schema, the description is nearly complete: it identifies the source and the returned metric categories. The main missing piece is explicit routing guidance versus siblings, which was already penalized under usage guidelines.

  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% and the start_date/end_date parameters have detailed descriptions including format, defaults, and the ~10-year restriction. The tool description itself adds no parameter-level information, 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 uses the specific verb 'Read' with a clear resource, 'daily health metrics from the local database', and lists the exact metrics included. This differentiates it from the write/delete siblings log_daily_metric and clear_metric.

  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?

  The description gives no explicit guidance on when to choose this tool over its siblings, such as 'use for retrieving metrics as opposed to logging or clearing them.' Although the name implies a read operation, no when-to-use or exclusion criteria are stated.

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

• clear_metricA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It clearly communicates the mutation ('blank out'), the exact scope (one metric, one day), and the guarantee that other metrics are untouched. It could add permanence or no-op behavior details, but the core destructive semantics are clear.

  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 front-loaded with the action and scope. The examples are meaningful and help clarify intent without 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?

  For a two-parameter tool with full schema coverage and an output schema, the description covers the operation's purpose, scope, and usage context. Nothing essential is missing for correct invocation.

  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 input schema already documents date formatting and the allowed field values. The description adds contextual examples but no new parameter-level semantic detail, 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 ('Blank out (set to null)') and names the exact resource: a single metric for a single day. It also explicitly distinguishes itself from log_daily_metric, making the tool's 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly frames this tool as the counterpart to log_daily_metric for undoing bad values, with concrete examples. This gives clear when-to-use guidance and implies the alternative for normal metric logging.

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

• log_daily_metricA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden and succeeds: it discloses row creation, partial-write semantics, and the fact that nulls are untouched. This is exactly the kind of behavioral context an agent needs before calling a mutating 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?

  Three sentences with no filler. The core purpose is front-loaded, and every sentence contributes either behavioral semantics or usage guidance. The description is compact yet rich.

  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 has an output schema (per context), so return-value prose is unnecessary. The description covers creation, partial updates, null behavior, and the correct sibling for undo. Nothing an agent needs to call this correctly is missing.

  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 the baseline 3, but the description adds meaningful parameter behavior beyond the schema: only passed metrics are written, nulls are not touched, and at least one metric is implied. This improves the agent's understanding of how the nullable parameters actually behave.

  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 and resource: 'Record one or more health metrics for a single day.' It also distinguishes itself from siblings by explicitly naming clear_metric for undo operations, so an agent can tell logging from reading or clearing without ambiguity.

  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?

  It clearly states when to use the tool (logging metrics for a day) and when not to ('To undo a value logged by mistake, use clear_metric'). It also explains the partial-update behavior, which prevents agents from thinking they must re-send all values.

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