Server Quality Checklist

Tool Scores

• clean_empty_data_filesA
  3.6/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. 'Limpa' (cleans) is vague and does not explicitly state that files are deleted. The schema parameter 'dry_run' reveals deletion when false, but the tool description itself fails to mention the destructive nature or any safety details, leaving the agent to infer behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the main purpose and key details (file types, directory, criterion). 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.

  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 an output schema, the description provides adequate context: file types, target directory, and the criterion for 'empty'. The only weakness is the lack of explicit mention of deletion, but the schema partially compensates and the tool is not complex.

  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 single parameter dry_run has a clear description explaining list vs. delete behavior. The tool description itself adds no parameter-level information, so baseline 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's function: identifies and cleans JSON/CSV files without valid data points in the ./data directory. The verb 'identifica e limpa' is specific, the resource (JSON/CSV files) is explicit, and it is clearly distinguished from sibling tools which are all about reading/scanning fitness data.

  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 usage context (cleaning data files) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. However, the tool's purpose is sufficiently distinct from siblings, so the lack of explicit guidance is a moderate gap.

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

• get_workout_logsA
  3.8/5.0
  Behavior3/5

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

  The description adds a behavioral detail beyond the name: it ignores empty files and specifies which folders are scanned. However, with no annotations, it does not disclose output format or other behavioral aspects, though the read-only nature is implied by 'get'.

  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 efficiently conveys the tool's function and a key behavioral detail. 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 parameterless read tool with an output schema, the description is adequately complete: it identifies the source folders and empty-file handling. It lacks usage guidance, but that is a minor gap given the simplicity of the 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 schema trivially covers 100% of parameters. The baseline for 0 params is 4; the description does not need to explain parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Extrai' (extracts) and identifies a precise resource: records from folders 'Atividades', 'Todas as sessões e segmentos de atividade física'. This clearly distinguishes the tool from siblings like get_sleep_records or get_daily_activity.

  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 about when to use this tool versus alternatives. There are no explicit when-to-use/when-not-to-use instructions or mentions of sibling tools.

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

• read_fitness_fileA
  3.8/5.0
  Behavior3/5

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

  The description discloses that it reads raw or parsed content and restricts to the ./data folder, which is a useful behavioral trait. However, it does not mention error behaviors (e.g., missing files, binary content) or permissions, and with no annotations provided, the description carries the full burden for behavioral disclosure. The existence of an output schema mitigates some return-value 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, concise sentence that directly communicates the tool's purpose without extraneous detail. It is front-loaded and 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 simple file-read tool, the description and schema provide sufficient context for an agent to invoke it correctly. The output schema covers return values, and the tool's scope is clearly limited to ./data. It lacks explicit usage comparisons with siblings, which is a minor gap, but overall it is adequately 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?

  The schema description for file_path covers its meaning (relative path within ./data) completely, and the description only repeats this without adding additional nuance. Since schema coverage is 100%, the description adds no extra parameter semantics 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 clearly states the tool reads raw or parsed content of any file inside ./data, with a specific verb ('Lê') and resource ('qualquer ficheiro dentro da pasta ./data'). This distinguishes it from sibling tools that focus on higher-level derived data (e.g., get_daily_activity), making its purpose unmistakable.

  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 accessing raw data files, which is distinct from the sibling tools, but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no guidance on when to prefer this over get_daily_activity or scan_google_fit_data, leaving the usage inference to the agent.

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

• get_sleep_recordsA
  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 burden of behavioral disclosure. It does disclose a behavioral trait: ignoring empty files. However, it does not mention read-only nature, return format, pagination, or any side effects. The description adds some value but leaves significant behavioral context undisclosed.

  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 core action. Every word earns its place, providing essential information about the source and the empty-file filtering without unnecessary padding.

  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 no parameters and an output schema exists (so return values need not be described), the description is reasonably complete. It specifies the source file and a key processing detail. It could mention broader usage context, but for a simple extraction tool, it covers the essentials.

  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 takes zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and per the baseline for 0-param tools, a score of 4 is appropriate. The description adds no parameter-specific semantics but none are needed.

  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 extracts sleep data and schedules from the specific derived_com.google.internal.sleep files. It uses a specific verb ('extrai') and resource, and the sibling tools (get_daily_activity, get_workout_logs) indicate this is the sleep-specific option, distinguishing it from alternatives.

  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 sleep data from a specific source, but does not explicitly state when to use this tool over siblings or provide exclusions. There is no mention of alternatives or contextual guidance beyond the source file, so the usage context is only implied.

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

• scan_google_fit_dataA
  4.1/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 explains the tool's behavior: scanning the ./data folder, detecting specific Google Fit export folder names, and listing files. This conveys a read-only, non-destructive operation. It does not explicitly say 'does not modify file contents' but 'lists the files' strongly implies a safe, scan-only action.

  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 sentence that efficiently conveys the tool's purpose and scope. It is front-loaded with the action and location, and lists the specific export folder types. It is slightly verbose with the long list, but it earns its place by clarifying what is detected.

  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 scan/list tool with zero parameters and an output schema present, the description is sufficiently complete. It details the folder detection logic and implies a read-only operation. The only missing element is an explicit connection to how the returned file list is used with sibling tools, but that is more of a usage guideline than a completeness 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, so the baseline is 4. The description adds useful context about the folder structure and detection criteria, which is not captured by the empty input 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 tool's function: it scans the ./data folder, identifies Google Fit export folders (Activities, Daily activity metrics, All sessions, All data), and lists files. This specific verb+resource combination distinguishes it from sibling tools that read specific data types (e.g., get_daily_activity, read_fitness_file).

  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 as a discovery step before reading specific files, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. The sibling tools are for reading, not scanning, so the use case is reasonably clear but lacks explicit guidance.

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

• get_daily_activityA
  4.5/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 transparently discloses that the tool extracts summarized metrics and specifically 'ignores empty files', which is a useful behavioral trait. It does not mention side effects or permissions, but as a read-only data retrieval tool, this is adequate.

  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 primary action and includes a relevant caveat ('ignoring empty files'). Every word earns its place with no redundancy or unnecessary detail.

  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 the tool's simplicity (0 parameters) and the presence of an output schema, the description is complete enough for an agent to understand its purpose and behavior. It covers what is extracted and a key edge case, and the output schema handles return value details.

  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, which sets a baseline of 4. The description adds meaning by explaining what data will be returned (steps, calories, active minutes, distance), going beyond the empty schema. Since there are no parameters, no parameter-level clarification is needed.

  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 'Extrai' (extracts) and specifies the resource: daily activity metrics including steps, calories, active minutes, and distance. This distinguishes it from sibling tools like get_workout_logs and get_sleep_records, which focus on different data types.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool (to retrieve daily activity totals) but does not explicitly mention alternatives or when not to use it. It implies usage for daily metrics, which is a sufficient context signal given the sibling tool names.

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