Server Quality Checklist

Tool Scores

• execute_commandC
  2.8/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. It mentions 'security validation' but does not elaborate on what that entails, potential side effects, failure modes, or resource impact. This is a significant gap for a tool that executes arbitrary commands, which is inherently risky.

  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, direct sentence with no redundancy. It efficiently communicates the core action. However, it is so brief that it omits crucial behavioral and usage details, which reduces its overall effectiveness. The brevity is not inherently flawed, but it sacrifices needed context.

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

  Completeness1/5

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

  Given the tool's complexity and risk (command execution with security validation), the description is grossly incomplete. It fails to explain return values, timeout behavior, working directory effects, security levels, or any failure handling. With no annotations and no output schema, this description carries the full burden and falls far short.

  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 provides complete descriptions for all four parameters, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already defines, and it doesn't clarify how 'security validation' relates to the security_level parameter.

  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 clearly states the tool's function: executing a command in the terminal. This is a specific verb+resource pairing. While it doesn't explicitly distinguish from siblings, the sibling tools (monitor_processes, validate_security, plan_workflow) serve obviously different purposes, so no ambiguity arises.

  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 prerequisites, exclusions, or scenarios where another tool would be more appropriate. For a command execution tool, this lack of context leaves the agent without clear selection criteria.

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

• monitor_processesC
  2.8/5.0
  Behavior1/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 fails to mention that monitoring is likely a read-only operation, whether any side effects occur, permission requirements, or return format. The description only states the basic action without any behavioral nuances.

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

  Conciseness3/5

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

  The description is a single sentence with no fluff, making it concise. However, it is under-specified for a 3-parameter tool and lacks structure. It is average: not overly verbose but also not providing enough useful content to be considered well-structured.

  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?

  Given no annotations and no output schema, the description must provide more context. It does not explain what the tool returns, how filtering works, or any limits on duration or metrics. The description is incomplete for a tool with three parameters.

  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 baseline is 3. The description adds no additional meaning beyond the schema; 'collect metrics' relates to the metrics parameter but does not enrich understanding of filter or duration parameters. The schema already documents each parameter adequately.

  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 specific verbs 'monitor' and 'collect' and identifies the resource as 'running processes' and metrics. It distinguishes itself from sibling tools like execute_command and validate_security, which have different purposes.

  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. The description is purely declarative and provides no context about appropriate scenarios, prerequisites, or situations where other tools should be preferred.

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

• plan_workflowB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It does not explicitly state whether the tool executes commands or merely returns a plan, nor does it mention side effects or safety characteristics. The verb 'plan' implies non-execution, 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 sentence with no filler, directly stating the core purpose. It is appropriately concise and front-loaded.

  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?

  Given the nested dependencies parameter, lack of output schema, and presence of execution siblings, the description is too sparse. It does not explain return behavior, the dependencies field, or how planning relates to execution, leaving critical gaps for effective usage.

  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% parameter description coverage, so the description does not need to add parameter details. It doesn't add extra meaning beyond the schema, which is the baseline for full 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 provides a specific verb ('plan') and resource ('multi-step terminal workflow'), clearly distinguishing it from sibling tools like execute_command, which executes commands rather than plans them.

  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 offers no guidance on when to use this tool vs alternatives such as execute_command. It does not mention prerequisites, conditions for planning versus executing, or any exclusions.

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

• validate_securityB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the command is actually executed, how risk is assessed, or what side effects might occur. The agent is left with only a high-level purpose.

  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, front-loaded with the primary verb and object, containing no fluff or redundant details.

  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 no output schema and no annotations, yet the description says nothing about return values, error conditions, or behavioral caveats. For a security validation tool, this is insufficient for an agent to anticipate results or side effects.

  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 both parameters already have descriptions. The tool description adds no extra meaning beyond the schema, such as how 'context' influences validation or expected command formats. Baseline 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 a specific verb ('validate') and names the resource ('command security') plus an outcome ('assess risk level'), making its purpose clear. It naturally distinguishes from sibling tools like execute_command and monitor_processes.

  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, when not to, or what alternatives exist. It simply states what it does without contextualizing its placement among siblings.

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