Server Quality Checklist

Tool Scores

• sysknife_executeA
  4/5.0
  Behavior3/5

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

  With no annotations, description carries full burden. It discloses the approval receipt requirement and MCP self-approval limitation, but doesn't detail error behavior, idempotency, or side effects. Adequate but not comprehensive.

  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, front-loaded with main purpose, zero wasted words. Every sentence 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?

  Given output schema exists, return values don't need elaboration. One-parameter tool with clear source (sysknife_plan) and approval constraint. Lacks error handling details but otherwise complete for the tool's complexity.

  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% (StepToExecute fully defined). Description adds 'take the steps array from sysknife_plan output' – helpful but minimal beyond schema. 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?

  Description states 'Execute exact steps produced by sysknife_plan' – specific verb+resource, and clearly distinguishes from sibling tools like sysknife_plan and sysknife_audit_verify.

  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?

  Provides critical usage context: each step needs a one-time receipt from CLI 'sysknife approve', and MCP cannot approve its own mutations. No explicit when-not-to-use, but the approval requirement effectively guides appropriate use.

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

• sysknife_audit_verifyA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses read-only safety, the 'without prior plan' requirement, and the exact return values (status, rows_checked, first offending row). It does not cover potential edge cases like permissions or empty logs, but the core behavior is 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?

  Two sentences deliver purpose, safety, return values, and a usage note without any waste. The structure is front-loaded with the action and resource, making it easy to parse quickly.

  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 parameterless tool with an output schema, the description provides complete context: what it verifies, its read-only nature, and what it returns. The output schema covers the detailed return structure, so the description 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 tool has zero parameters, so the baseline is 4. There is nothing for the description to add beyond the empty schema, and the description appropriately avoids invented parameter details.

  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 states a specific verb ('Verify') and a clear resource ('tamper-evident Ed25519-signed hash chain over the audit log'), which unambiguously distinguishes it from sibling tools like sysknife_execute and sysknife_plan. The mechanism and object are named precisely.

  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 explicitly says it is 'Read-only and safe to call without prior sysknife_plan', giving direct usage context and a notable distinction from tools that may require a plan. It doesn't explicitly exclude any scenarios, but the verification purpose is clearly scoped.

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

• sysknife_doctorA
  4.5/5.0
  Behavior4/5

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

  With no annotations, description carries full burden. It discloses read-only nature, pinging behavior, and output details. No mention of potential latency or failure modes, but sufficient.

  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 with zero waste. Front-loaded with purpose and key behavioral traits.

  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 zero parameters and existence of output schema, description thoroughly covers purpose, behavior, and safety. No gaps.

  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?

  No parameters in schema; schema coverage 100%. Description adds no parameter info, but baseline of 4 applies as there are none to document.

  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?

  Description clearly states it diagnoses SysKnife by pinging daemon, reporting provider/model, audit DB path, and chain status. It distinguishes from sibling tools like sysknife_execute and sysknife_plan by emphasizing it's a read-only diagnostic.

  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?

  Explicitly states it's read-only and safe without prior sysknife_plan, providing clear context. Could mention when to use alternatives, but the sibling differentiation is implicit.

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

• sysknife_historyA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so description carries the burden. Notes this is read-only and safe, lists filters and defaults. Could mention ordering or load implications, but sufficient for a simple list 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?

  Three sentences, front-loaded with core purpose. Every sentence adds value; no fluff.

  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?

  Output schema exists, so return values don't need explanation. Covers purpose, filters, safety, prerequisites. Complete for a tool of this 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 coverage is 100%, and description adds example values and defaults for each parameter (status values, action name, timestamp format, limit default). Adds meaning beyond 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?

  Description states 'List past SysKnife audit-log entries' with a clear verb and resource. Distinguishes from sibling tools (sysknife_plan, sysknife_execute, etc.) by focusing on history listing.

  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?

  Explicitly says 'Read-only and safe to call without prior sysknife_plan', providing clear context for when to use. Does not explicitly exclude other scenarios, but the guidance is helpful.

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

• sysknife_planA
  4.5/5.0
  Behavior4/5

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

  Description reveals the output structure (typed steps, risk levels, commands, transaction IDs) and the critical workflow constraint (stop and wait for real terminal approval). No annotations are provided, so the description carries the full burden; it does not contradict any.

  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 concise sentences: the first describes purpose and output, the next two provide essential usage instructions. No redundant information, well 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?

  Given the output schema exists, the description appropriately summarizes return types. The usage workflow is fully explained, and the single parameter is well-covered. No 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 single parameter 'intent' has a complete description in the schema (100% coverage). The tool description does not add additional meaning beyond that, 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 it plans a Linux system administration intent and returns structured steps with risk levels, commands, and transaction IDs. It distinguishes from sibling tools like sysknife_execute and sysknife_audit_verify by focusing on the planning phase.

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

  Usage Guidelines5/5

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

  Explicitly instructs the agent to present the plan, then STOP, and requires the user to run 'sysknife approve' in a terminal. It also warns not to execute from chat approval alone, providing clear usage boundaries.

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