Server Quality Checklist

Tool Scores

• startA
  3.7/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 discloses key behaviors: async execution, PID return, and pointer to lifecycle tools. But it omits details like error handling, process cleanup, and the exact format of the PID return value. This is adequate but not rich.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the primary action. Every sentence adds value: the action, the async nature, and the follow-up tools. No fluff or repetition.

  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 moderate complexity (4 params, 1 required) and presence of an output schema, the description covers the main use case and points to related tools. It could include parameter details, but the lifecycle guidance and async disclosure make it fairly complete for a start tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not explain the parameters. Only 'command' is implicitly understood, while cwd, env, and shell are left entirely undocumented. The description fails to compensate for the lack of schema-level descriptions.

  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 a specific verb and resource: 'Start a background process and return its PID.' It distinguishes from siblings by emphasizing 'background' and 'asynchronously', which contrasts with the 'run' tool and the post-start lifecycle tools (status, signal, input).

  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?

  It provides clear context: start a background process, then use status(), signal(), and input() for subsequent interaction. It implies this tool is for launching processes, not managing them. However, it doesn't explicitly mention when to use alternatives like run or list_processes, leaving some room for uncertainty.

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

• runA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and discloses key behaviors: synchronous execution, return values (exit code, duration, stdout+stderr), and output bounding via max_output with head+tail capture. It omits timeout behavior and potential side effects, but still provides meaningful transparency.

  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 three tight sentences with no filler. It front-loads the primary purpose and then adds essential return and output-capture details, 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 an output schema exists and the tool is a command runner, the description covers core execution behavior, return values, and output limits. It does not mention timeout semantics or cwd/env/shell usage, but the overall context is reasonably complete for selecting and invoking the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for all six parameters. It only explains max_output and implicitly command, leaving cwd, env, shell, and timeout_ms to rely on schema defaults and names. This is insufficient for a 0-coverage 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 executes a shell command synchronously and waits for completion. This specific verb+resource+mode distinguishes it from siblings like start, send_signal, and list_processes.

  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 'synchronously and wait for completion' phrase implies when to use this tool versus starting a background process, but the description never explicitly names alternatives or states when not to use it. Usage context is mostly implied rather than direct.

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

• send_inputA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses that text is UTF-8 encoded and written to the process's stdin pipe, adding behavioral detail beyond just 'send input'. It doesn't cover error cases, but the core mechanics are transparent.

  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, immediately states the action, and every sentence adds value. There is no fluff or repetition of schema information.

  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 tool is simple with an output schema. The description covers purpose, usage, and behavioral mechanism. It lacks edge-case details (e.g., process not found), but given the simplicity and output schema, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implies that 'stdin' is the text and 'pid' is the target process, but it doesn't explicitly define them. It adds UTF-8 encoding detail for stdin, but leaves pid ambiguous, providing only partial semantics.

  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 'Send text to a running process's stdin', specifying the verb and resource. It distinguishes from siblings like send_signal (sends signals) and start/run (creates processes) by focusing on stdin input.

  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?

  It explicitly says 'Use this for interactive processes (REPLs, prompts)', providing clear context for when to use. It doesn't mention exclusions or alternatives explicitly, but the context is sufficient to differentiate from siblings.

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

• statusA
  4.1/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 discloses the return fields and possible process states (running/completed/timed_out), which goes beyond the schema. It does not mention error behavior, but for a read-only status check, the non-mutating nature is implied.

  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 main verb. The first sentence states the action and object, the second lists key return fields. There is no redundancy or unnecessary detail.

  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 status tool with two parameters and an output schema, the description covers the main behavioral aspects and return values. It omits error handling (e.g., invalid pid) and the precise effect of 'tail_bytes', but these are minor gaps given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions (0% coverage). The description does not explain the 'tail_bytes' parameter or its relationship to output; it only mentions 'tail output' and 'recent output' without connecting them to the parameter. 'pid' is self-explanatory, but 'tail_bytes' is under-specified.

  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 ('Check') and identifies the resource ('background process state, exit code, and tail output'). It also enumerates return values (running/completed/timed_out, duration, total bytes captured, truncation status, recent output), making the tool's purpose unambiguous and distinguishing it from siblings like run, start, send_signal, send_input, and list_processes.

  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 (checking background process status) but does not explicitly mention alternatives or exclusions. Sibling tool names make the differentiation evident, yet there is no direct 'use this instead of that' guidance.

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

• send_signalA
  4.2/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 of behavioral disclosure. It reveals a critical escalation behavior ('SIGTERM → wait 5s → SIGKILL') and enumerates valid signals, which goes beyond the bare parameter names. It could mention error handling or permission requirements, but the key behavioral trait is disclosed.

  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: one sentence stating the core function, plus two short sentences detailing the SIGTERM escalation and valid signals. Every sentence earns its place with 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 simple tool with two parameters and an output schema, the description covers the essential behavioral details: the target (process group), the signal options, and the special SIGTERM handling. It does not discuss return values (handled by output schema) or potential errors, but that is acceptable given the low complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that 'pid' refers to a process group (though the parameter name is 'pid'), and it lists the allowed values for 'sig'. The signal list adds meaningful semantics that the schema lacks.

  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 'Send a POSIX signal to a process group' with a specific verb and resource. It distinguishes from sibling tools like 'send_input' (which sends input) and 'status' (which reports status), 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 for sending signals to process groups and lists valid signals, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, so 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.

• list_processesA
  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 explicitly discloses the output fields (PID, state, exit code, duration, bytes captured, command preview) and the scope ('currently tracked by the server'). It does not mention side effects, but as a list operation none are expected, and the read-only nature is implied by 'List'.

  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 exact purpose and scope, the second enumerates the return payload. No filler, no redundancy, and the most important information is front-loaded.

  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 simple zero-parameter listing tool with an output schema available, the description covers the purpose, scope, and returned metadata. It is complete and does not leave critical gaps for an agent to invoke or interpret results.

  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 cannot add parameter-level detail beyond the schema. Per the baseline, a parameterless tool receives a 4, and the description does not need to explain anything further.

  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 specific verb 'List' with a clear resource ('all managed background processes') and includes the type of data returned. It is easily distinguished from siblings like 'status' (likely single process) or 'send_signal' (mutating action).

  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 clearly implies when to use this tool: to get an overview of all managed background processes. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to recognize it as the appropriate choice for a full listing.

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