Server Quality Checklist

Tool Scores

• list_screensB
  3.1/5.0
  Behavior2/5

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

  The description does not disclose any behavioral traits beyond the name. Since no annotations are provided, it carries the full burden, but only states the action without mentioning read-only nature, pagination, or return format. The 'list' verb implicitly suggests non-destructive behavior, but no explicit disclosure is given.

  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, focused sentence with no redundant content, achieving maximum conciseness for a tool that requires no parameters.

  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 is adequate for a simple list operation with no parameters or output schema, but it could be improved by mentioning that it returns all screens without any filters or by referencing the get_screen tool for individual screens.

  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?

  There are zero parameters, and the input schema confirms this. The description correctly implies no arguments are needed, so no additional parameter semantics are required.

  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 uses a specific verb 'List' and resource 'DAKboard screens', making its purpose clear and differentiating it from sibling list tools for loops, blocks, devices, etc. It doesn't name alternatives, but the resource is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

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

  No guidance is provided about when to use this tool over alternatives like get_screen or other list tools. The description lacks any context or exclusion criteria.

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

• get_blockB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavior. It only states 'Get detailed information' without specifying what information is included (e.g., block configuration, layout, styling), whether the operation is read-only (though implied by 'Get'), or any error/not-found behavior. This is insufficient for a tool with no structured annotations.

  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, focused sentence with no filler or redundant information. It communicates the core purpose efficiently, front-loading the key verb and resource.

  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 tool is low-complexity with two well-documented parameters, and the description covers the basic action. However, the absence of an output schema means the agent does not know the structure of the 'detailed information' returned. There is also no mention of prerequisites or how this differs from other block-related tools. The description is minimally adequate but leaves notable gaps.

  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 input schema already provides descriptions for both screen_id ('The DAKboard screen ID') and block_id ('The block ID'), achieving 100% coverage. The description adds no extra meaning about parameter usage, formats, or relationships 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 uses the specific verb 'Get' with the resource 'block' and clarifies the scope 'on a DAKboard screen'. This distinguishes it from list_blocks (which lists blocks) and update_block (which modifies), making the purpose immediately clear.

  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 use this tool versus alternatives such as list_blocks for retrieving multiple blocks or get_screen for screen-level details. No context is provided about prerequisites or what to do if the block ID is unknown.

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

• get_metricB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it mention potential side effects, authentication requirements, or response format. The word 'Get' implies a read operation, but this is not 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 a single, concise sentence that is front-loaded with the verb and resource. No unnecessary words or redundancy.

  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 simple one-parameter tool, the description is minimally sufficient, but it lacks details about the return structure, data point formatting, and any limitations. There is no output schema or annotations to compensate, so more context would be helpful.

  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 has 100% description coverage, with metric_name described as 'The metric name'. The description does not add any additional meaning about the parameter's format, allowed values, or relationship to the output. Baseline score of 3 applies given high schema coverage.

  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: retrieving a DAKboard metric along with its data points. The verb 'Get' and specific resource 'metric' distinguish it from sibling tools like list_metrics or create_metric_data_points.

  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 provides no guidance on when to use this tool versus alternatives like list_metrics or get_loop. It simply states what it does, leaving the agent to infer its appropriate usage.

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

• get_deviceB
  3.4/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 of behavioral disclosure. It only says 'Get detailed information' without explaining what 'detailed' includes, whether any side effects exist (though read-only is implied), error conditions, or data format. This is insufficient for a tool with no other metadata.

  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, clear sentence with no redundant words. It is front-loaded and appropriately concise for the tool's simple purpose.

  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?

  With no output schema and minimal description, the agent receives no information about the return structure or what 'detailed information' contains. Combined with no usage guidelines, the tool description is underspecified for an agent to fully understand its behavior and outputs.

  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 input schema is fully documented with device_id described as 'The device ID' (100% coverage). The description does not add extra meaning about the parameter format, usage, or how to obtain it, so it meets the baseline but adds no value beyond the 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 uses a specific verb ('Get') and resource ('specific DAKboard device'), clearly distinguishing it from siblings like list_devices (which lists all) and update_device (which modifies). It unambiguously states the tool's function.

  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 retrieving details of a single device, but it does not explicitly state when to prefer this over list_devices or other sibling tools. No exclusions or alternative suggestions are provided, leaving the agent to infer from the name and context.

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

• list_loopsB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits but does not. It does not explicitly state that listing is read-only, mention side effects, or describe return behavior. While 'List all' implies a read operation, this is not explicitly disclosed, leaving a transparency 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, concise sentence, making it well-structured and easy to parse. However, it essentially restates the tool name without adding extra context, so it is efficient but not maximally informative.

  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 simple list tool with no parameters and no output schema, the description is minimally viable but misses usage context and behavioral transparency. It does not clarify what 'screen loops' are or how this relates to sibling tools, so it leaves gaps that the agent must infer.

  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 zero parameters, so the baseline is 4. The schema coverage is trivially complete, and the description adds no parameter-specific information because there are no parameters to describe. This is appropriate for a parameter-less tool.

  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 'List' and identifies a distinct resource ('DAKboard screen loops'), clearly distinguishing it from sibling tools like 'get_loop' (single item) and 'list_screens' (different entity). This is unambiguous and actionable.

  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 usage guidance is provided. The description does not mention when to choose this tool over alternatives such as 'list_screens' or 'get_loop', nor does it state any prerequisites or context for use. It simply restates the function without situational cues.

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

• create_metric_data_pointsA
  3.5/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 full responsibility for behavioral disclosure. It only states the action and mentions the input shape ('array of values with optional timestamps'), but fails to disclose whether the operation is additive, replaces existing data, requires the metric to exist, or how errors are handled. This is a minimal behavioral description, similar to the MID-level update_drive example.

  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 exceptionally concise, consisting of two short sentences with no filler. It front-loads the core purpose and then provides a brief summary of the input. Every word contributes value.

  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 tool is relatively simple with only two parameters and no output schema. The description covers the basic purpose and input shape, but given there are no annotations, it could be more complete by mentioning what happens on success or any restrictions. However, the low complexity and full schema coverage make the description minimally sufficient.

  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 both parameters and their properties described in detail. The description adds little beyond what the schema already states ('values' maps to data_points, and 'timestamps' are mentioned but already documented in the schema). According to the rubric, baseline 3 is appropriate when schema does the heavy lifting.

  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 action ('Create data points') and the specific resource ('DAKboard metric'), making it distinct from sibling tools like 'delete_metric_data_points' or 'list_metrics'. The verb and object 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 Guidelines3/5

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

  The description implies usage (created for adding data points) but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. There is no mention of 'use this when you need to add new data' or contrast with deletion/retrieval tools.

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

• delete_metric_data_pointsA
  3.5/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 of behavioral disclosure. While it names the target resource, it does not disclose whether deletion is permanent, whether all data points at the timestamp are removed, or any side effects. For a destructive operation, 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence of 11 words. Every word earns its place, and there is no redundancy or filler.

  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 simple delete operation with two documented parameters, the core purpose is clear. However, with no annotation and no output schema, the description should address behavior when no matching data points exist, permanence, and the scope of deletion (all points at timestamp vs one). These gaps leave the description only minimally 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 100%, and the description aligns with the timestamp parameter. However, it adds no new meaning beyond what the schema already provides, such as clarifying whether the operation deletes all data points at that timestamp or just one.

  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 'Delete' with a clear resource ('data points from a DAKboard metric') and a precise scope ('at a specific timestamp'). It clearly differentiates from sibling tools like delete_metric (which deletes the entire metric) and create_metric_data_points.

  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 removing specific data points rather than the whole metric, but it does not explicitly state when to use this tool vs alternatives. Sibling names like delete_metric provide context, but the description relies on inference rather than explicit guidance.

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

• list_devicesA
  3.5/5.0
  Behavior2/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 only states 'List all' which implies a read operation but provides no additional context such as whether the response is paginated, how many results are returned, or if any authentication is required. This is a minimal disclosure beyond what the name already suggests.

  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, concise sentence: 'List all DAKboard devices'. Every word is informative, there is no redundancy, and it immediately conveys the operation and scope.

  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 tool is simple with no parameters and no output schema, but the description omits any mention of the return value. An agent might need to know that it returns an array of device objects and what fields are present. While the name implies a list, the lack of output schema or return format description leaves a 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 tool has zero parameters and an empty schema, so there is nothing to explain. The baseline score for 0 params is 4, and the description does not need to detail parameters that do not exist.

  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 'List all DAKboard devices' uses a specific verb ('List') and resource ('DAKboard devices'), clearly distinguishing it from siblings like get_device (single device) and update_device (modify). It leaves no ambiguity about the tool's function.

  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 provides no guidance on when to use this tool versus alternatives. It does not mention that get_device is for a single device or that this is the go-to for retrieving the full list. No exclusions or context are given, leaving the agent to infer from sibling names.

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

• list_metricsA
  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 the full burden of behavioral disclosure. It only states the operation without detailing return format, pagination, ordering, or side effects. While 'list' implies reading, the description does not explicitly confirm read-only behavior or lack of side effects.

  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, concise sentence with no wasted words. It front-loads the action and subject, making it immediately clear.

  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 parameterless list-all tool with no output schema, the description adequately conveys the operation and implies a return of metrics. It could mention the fields returned, but this is not critical for such a simple tool.

  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, so the description does not need to explain parameter syntax. Per the baseline rule for 0 parameters, a score of 4 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 ('List') with a clear resource ('DAKboard custom metrics') and scope ('all'), making the tool's function unambiguous. It distinguishes from sibling tools like get_metric (singular) and create_metric_data_points (write operation).

  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 provides no guidance on when to use this tool versus alternatives such as get_metric for individual metrics. There is no mention of exclusions, prerequisites, or alternative tools, leaving the decision to the agent.

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

• update_screenA
  3.6/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 full responsibility for disclosing behavioral traits. 'Update' implies mutation, but the description does not explain whether the update is partial or full-replacement, whether it affects existing settings not listed, what permissions are required, or what the response format is. This is a significant gap for a mutation 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?

  The description is a single, front-loaded sentence that names the action, the resource, and key settings. Every word is informative, with no filler or redundancy. It is appropriately concise for the tool's purpose.

  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?

  The tool has 7 parameters, no output schema, and no annotations, but the description only states what it updates without explaining the update behavior (e.g., partial vs. full update), potential side effects, or error conditions. While the schema fully documents parameters, the description does not provide enough operational context for an agent to safely invoke the tool in different scenarios.

  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%, meaning every parameter already has a description. The tool description adds a high-level grouping ('dimensions' for width/height) but does not add significant semantic details beyond the schema. The baseline of 3 applies because the schema already provides thorough parameter documentation.

  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 verb 'Update' and the resource 'DAKboard screen's settings', listing specific fields (name, orientation, dimensions, refresh rate). It clearly distinguishes from sibling tools like update_block (different resource) and get_screen/list_screens (read operations).

  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 implies when to use the tool (when updating screen settings) and clearly identifies the target resource, but it does not explicitly exclude alternatives or mention when not to use it. For example, it doesn't state that get_screen should be used for reading or that update_block is for blocks. This context is implicit 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.

• test_dakboard_connectionA
  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 of behavioral disclosure. It only states that it tests the connection and configuration but does not disclose side effects, output format, or behavior on success/failure. For a tool that likely returns a status, this is a notable gap.

  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, concise sentence that front-loads the verb and resource. There is no unnecessary repetition or filler, making it highly efficient.

  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?

  Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimally complete but lacks information about what the test returns or how the agent should interpret the result. It does not explain what 'configuration' encompasses, leaving some ambiguity 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% (empty). The description does not need to explain parameters, and the baseline for 0 params is 4. It correctly adds nothing about parameters since there are none to describe.

  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 a specific verb ('Test') and resource ('DAKboard MCP Server connection and configuration'). It is easily distinguished from sibling tools, which are all CRUD operations on specific resources (screens, blocks, devices, metrics), making this a unique diagnostics 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 (when you need to verify connectivity or configuration) but does not explicitly state when to use this vs. alternatives. There are no exclusions or alternative mentions, so the guidance is only implied by the tool's nature.

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

• update_deviceA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits but only states that settings are updated. It does not mention whether the update is partial or full, any required permissions, side effects, or what happens to existing settings not in the payload. 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.

  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, with a parenthetical listing of key fields. It is concise, efficient, and contains no redundant information.

  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 simple update tool with four schematically defined parameters, the description is adequate but not complete. It provides the core purpose and fields, yet lacks behavioral context (e.g., partial update semantics, prerequisites, or response format) that would be especially important given the absence of annotations and an output schema.

  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 schema already documents each parameter's meaning. The description adds minimal value by listing the fields in parentheses, but it does not provide any additional semantic detail beyond what is in the 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 clearly states the action ('Update') and the resource ('a DAKboard device's settings'), and explicitly lists the specific settings involved (name, IP address, assigned screen). This distinguishes it from sibling tools like update_screen and update_block, which target different resources.

  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 context is clear: use this tool to update device settings. Though it does not explicitly name alternatives or exclusions, the scope is unambiguous given the resource focus and sibling names, providing adequate guidance without needing to spell out when not to use it.

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

• get_loopA
  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 carries the burden. 'Get detailed information' clearly conveys a read-only operation with no side effects, but it does not disclose potential error behaviors, authentication requirements, or return format specifics. It provides basic transparency but lacks depth.

  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 directly states the tool's function without extraneous information. Every word contributes value, making it highly concise and easy to parse.

  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 single-parameter retrieval tool, the description adequately covers the core purpose and one key detail (screen rotation). However, without an output schema, it does not specify the full return structure or error semantics. Still, the description is sufficient for basic selection and 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 coverage is 100% for the single parameter (loop_id) with a minimal description. The tool description adds little beyond the schema, only implying that a loop ID is needed. Since coverage is high, the baseline of 3 applies, and the description does not significantly enhance understanding.

  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 a specific verb 'Get' and resource 'DAKboard screen loop', and distinguishes it from siblings like list_loops (list vs. get) and get_screen (loop vs. screen). The mention of 'screen rotation' adds specific scope, 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 Guidelines3/5

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

  The description implies usage when a user needs detailed loop information, but it does not explicitly compare with alternatives such as list_loops or get_screen. There are no when-not-to-use conditions or named alternatives, so guidance is only implied.

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

• get_screenA
  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 carries the burden. The verb 'Get' clearly implies a read-only operation and 'detailed information including settings' discloses the content of the response. Yet it does not mention potential errors, authentication needs, or the exact structure of the returned data, leaving some behavioral ambiguity.

  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 with no redundancy. It efficiently conveys the action, target, and scope, earning every word.

  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 low complexity (one parameter, no output schema, no annotations), the description covers the core purpose and return scope ('detailed information including settings'). It does not mention how to obtain a screen_id or reference sibling tools, but these are not essential for a simple get-by-ID 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?

  Schema coverage is 100%: the only parameter screen_id is well described as 'The DAKboard screen ID'. The description adds no additional semantic depth beyond calling the screen 'specific', so it neither compensates nor detracts from the schema baseline of 3.

  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 'Get' and clearly identifies the resource as 'a specific DAKboard screen' with added scope 'including settings'. This naturally distinguishes it from sibling tools like list_screens (which lists all screens) and other get_* tools for different entities.

  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?

  Usage context is implied by the words 'specific' and 'including settings' — one should use this when needing details of a single screen. However, there is no explicit when/when-not guidance or named alternatives, leaving the agent to infer when this tool is preferred over list_screens or update_screen.

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

• delete_metricA
  4/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 full burden. It explicitly warns that deletion cannot be undone and that it cascades to all data points, which is critical behavioral context. However, it does not mention permissions, failure behavior, or return values, leaving some 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 two sentences: the first states the action clearly, and the second adds the irreversible warning. No wasted words, and the warning is appropriately prominent.

  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 tool with one parameter and no output schema, the description covers the essential aspects: what it does, the scope, and the irreversible nature. It is complete enough for its simplicity, though it could mention prerequisites or what happens after deletion.

  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 for metric_name is 100% ('The metric name to delete'), so the baseline is 3. The 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 action ('Delete'), the resource ('DAKboard metric'), and the scope ('all its data points'). This distinguishes it from sibling tools like delete_metric_data_points, which only delete individual data points.

  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 when to use this tool (to delete a metric entirely) but does not explicitly mention alternatives or exclusions. For example, it does not say 'Use delete_metric_data_points if you only want to delete specific data points.' Usage context is clear but not explicit.

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

• list_blocksA
  4/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 operation lists all blocks scoped to a screen, which is a behavioral constraint. However, it does not mention response format, pagination, error handling, or permissions, leaving some 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 a single, front-loaded sentence with no unnecessary words. It communicates the essential purpose efficiently.

  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 required parameter, no output schema, no annotations), the description is mostly complete for an agent to understand what the tool does. However, it could benefit from a note about the return type or any default behavior, so it is not a full 5.

  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 input schema covers 100% of the parameter (screen_id with description). The tool description adds no additional meaning beyond the schema, so the baseline score 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 clearly states the tool lists all blocks on a DAKboard screen, using a specific verb ('list'), resource ('blocks'), and scope ('on a DAKboard screen'). This distinguishes it from sibling tools like get_block and update_block, which imply single-block or mutation operations.

  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 this tool—when you need to list all blocks on a specific screen. However, it does not explicitly mention alternatives or exclusions (e.g., use get_block for a single block), so it falls short of a full 5.

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

• visualize_screen_layoutA
  4.2/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 a fallback behavior ('falls back to API coordinates') and clarifies the benefit of using screen_uuid ('accurate CSS-based rendering'). However, it does not explicitly state that the tool is read-only or describe any side effects, though 'visualize' implies a safe operation.

  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 purpose. The second sentence efficiently communicates a key parameter nuance without redundancy. Every word earns its place.

  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 straightforward visualization tool with two parameters and no output schema, the description is sufficiently complete. It covers the purpose, the output format, and the key parameter behavior. It could mention the result format more explicitly (e.g., whether it's a raw string), but the ASCII diagram mention suffices.

  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 already covers 100% of parameters, so the baseline is 3. The description adds value by explaining the consequence of including screen_uuid (CSS-based rendering) versus omitting it (API coordinates), which goes beyond the schema's simple 'for accurate layout' wording.

  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 action ('Visualize the spatial layout of blocks'), the specific resource ('on a DAKboard screen'), and the output format ('as an ASCII diagram'). It distinguishes itself from sibling tools by being the only visualization tool, and the additional detail about screen_uuid adds specificity.

  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 implies when to use the tool (to see spatial layout) and provides a clear usage hint about providing screen_uuid for accurate rendering. However, it does not explicitly name alternative tools or state when not to use it, though the unique purpose makes this less critical.

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

• update_blockA
  4.6/5.0
  Behavior5/5

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

  This is a standout feature. It discloses a non-obvious behavioral quirk: DAKboard uses non-linear per-block coordinate scaling, that API coordinates don't map 1:1 to pixels, and that updating permanently changes the scaling factor. Even with no annotations, this fully warns the agent about side effects and required coordinate conversion, going far beyond a typical update description.

  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 deliver maximum critical information: what the tool does and the non-obvious coordinate scaling warning with a recommended prerequisite. No filler, no repetition of schema details. Every word earns its place.

  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 mutation tool with no annotations and no output schema, this description is nearly complete. It covers the essential action, the critical coordinate caveat, and the prerequisite visualization step. It does not mention return values or error conditions, but given the strong warning and clear input guidance, it fills most of the context 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 schema has 100% parameter coverage, so each parameter is individually described. The description adds crucial cross-parameter semantics by explaining that coordinate values (x, y, w, h) must be specified in rendered pixel values at 1920x1080 design resolution, which is not stated in any single parameter's schema description. This transforms the coordinate parameters from ambiguous into actionable.

  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 updates a block on a DAKboard screen and lists the key attributes (position, size, content, visibility). It distinguishes itself from siblings like get_block and list_blocks by its explicit verb 'Update' and resource 'block'.

  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 pre-usage guidance: 'Use visualize_screen_layout with screen_uuid first to see the actual layout before making changes.' This gives a clear recommended precursor and warns against blind updates, though it does not explicitly say when not to use the tool or mention alternatives like create/delete operations.

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