Server Quality Checklist

Tool Scores

• run_occA
  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 disclosing behavioral traits. It fails to warn that arbitrary OCC commands can have destructive side effects or require elevated permissions, and it does not mention any safety precautions. The only added context is the container name, which is insufficient for such a powerful execution 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 extremely concise, front-loaded with the main purpose in the first sentence, and the parameter explanation is compact. Every sentence contributes value without redundancy, making it an efficient reference for an agent.

  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?

  Despite having an output schema, the description lacks crucial context for a generic command execution tool: no mention of error handling, exit codes, output format, or the potential for irreversible actions. The guardrails and usage constraints are absent, leaving the agent underinformed for a tool that can execute arbitrary privileged commands.

  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 provides no per-property description (0% schema coverage), but the description compensates by explaining the 'command' parameter as an occ command string with concrete examples like 'status --output=json' and 'app:list'. This adds meaningful syntax guidance beyond the bare schema field.

  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 executes arbitrary OCC commands inside the Nextcloud container, with examples showing command format. It distinguishes itself from specialized sibling tools like get_status or optimize_db by emphasizing 'arbitrary' commands, making it the generic entry point.

  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 guidance is implied by the word 'arbitrary', suggesting it can be used for any OCC command not covered by specialized tools, but it does not explicitly state when to prefer this over its siblings or when not to use it. No alternatives are mentioned, so the guidance remains implicit rather than explicit.

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

• get_statusA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description must disclose side effects. It uses the read-oriented verb 'gets' and specifies a status command, which implies a non-destructive operation, but it does not explicitly state safety, permissions, or potential error conditions. This leaves some ambiguity but not contradictory information.

  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, information-dense sentence that states the purpose and the exact command. Every word is useful and there is 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 zero-parameter tool with an output schema available, the description adequately explains what the tool does and how it works. It could mention prerequisites like OCC availability, but that is not critical for this simple status check. Overall, the description is sufficiently complete.

  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 schema coverage is trivially high. The description adds no parameter details, which is acceptable. Per the guidelines, zero parameters earn a baseline score of 4.

  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 'Gets the Nextcloud system status' and specifies the exact command 'OCC status --output=json'. This is a specific verb+resource that distinguishes it from sibling tools like get_trusted_domains or the generic run_occ.

  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 (checking system status) but does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of exclusions or comparison with the generic run_occ tool, so it relies on inference.

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

• optimize_dbA
  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. It lists the exact commands executed, which is useful, but it does not disclose potential side effects, required permissions, or performance impacts. It provides moderate 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 concise and front-loaded, with a single sentence followed by a clear bulleted list of commands. Every element adds value with no waste.

  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 (no parameters) and the presence of an output schema, the description is largely complete. It could mention prerequisites or outcomes, but the command list provides sufficient context for basic use.

  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%. Per the rule, 0 parameters gives a baseline of 4. No parameter information is needed or missing.

  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 runs database optimization commands on Nextcloud and enumerates four specific commands. This is a specific verb+resource and distinguishes it from generic siblings like run_occ.

  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?

  It implies the tool is for the listed commands but does not explicitly state when to use it over alternatives like run_occ, nor does it mention when not to use it. No exclusions or alternative recommendations are provided.

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

• get_trusted_domainsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. The verb 'Lists' implies a read-only operation, but the description does not explicitly state side-effect-freedom, permission requirements, or return behavior. It adds the underlying OCC command as context, which is helpful but minimal.

  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?

  One concise sentence with no filler. It includes the OCC command as a value-add without extra verbosity.

  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 no-argument listing tool with an existing output schema, the description is sufficiently complete. It explains what it does and how (via OCC), and there are no hidden parameters or side-effect concerns for the agent to worry about.

  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 is fully covered. The description provides no parameter details, but none are needed. Baseline for 0 params is 4.

  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 'Lists' with the resource 'configured trusted domains in Nextcloud' and names the exact OCC command, making the tool's purpose unambiguous and distinguishing it from siblings like add_trusted_domain.

  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 is given about when to use this tool versus alternatives like run_occ. The usage is implied by the name and description (when you need to see trusted domains), but there are no exclusions or alternative recommendations.

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

• add_trusted_domainA
  4.4/5.0
  Behavior4/5

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

  The description discloses a non-obvious behavior: 'First checks current trusted domains to assign the next available index.' This goes beyond a simple statement of purpose. However, it does not mention potential error conditions or side effects like config reload, but with no annotations, this is a reasonable burden.

  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 concise, containing only three sentences. It front-loads the purpose, then adds the index-assignment behavior, and ends with a dedicated Args section. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool, the description covers purpose, behavior, and parameter semantics. The presence of an output schema makes it unnecessary to describe return values. It could be improved by mentioning when to use this versus get_trusted_domains, but that is not critical.

  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 only provides a string parameter with no description. The description adds meaning by specifying 'Domain name or IP address' and giving examples ('cloud.example.com' or '192.168.1.100'), which clarifies the accepted format.

  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 'Adds a new trusted domain to Nextcloud config' with a specific verb and resource. It distinguishes from sibling tools like get_trusted_domains by using 'add' rather than 'get'.

  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 intended use is clear from the description, but it does not explicitly mention alternatives or exclusions. It does not say when to prefer this over get_trusted_domains, though the verb 'add' makes the primary use obvious.

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