Server Quality Checklist

Tool Scores

• docker_dbA
  3.8/5.0
  Behavior4/5

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

  The annotations already signal destructiveHint=true, and the description adds meaningful behavioral context: destructive statements require # CONFIRMED-DESTRUCTIVE, databases that refuse return their exit code instead of a failed call, and the client comes from the image. This does not contradict the annotations and helps the agent anticipate failure modes and safety gates.

  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 short, front-loaded with the core query/status distinction, and every sentence earns its place. It avoids restating schema details and packs essential behavioral facts into four efficient sentences.

  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 complex 9-parameter schema and the presence of an output schema, the description covers the most decision-relevant aspects: what the tool does, supported engines, destructive-statement handling, and error semantics. It leaves profile/project/compose_path selection behavior to the already-rich schema, which is acceptable.

  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 parameters are already well documented in the schema. The description adds value by clarifying the query/status behavior and the destructive-confirmation convention, but it does not provide additional parameter-level meaning beyond what the schema already states.

  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 states specific verbs and objects: 'query runs a statement against a database container' and 'status asks the database about itself'. It also names the supported database types, giving a clear resource scope. It does not explicitly differentiate this tool from sibling tools such as docker_db_admin, so it stops short of a 5.

  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 gives clear context for choosing between the query and status actions, and notes the destructive-confirmation requirement. However, it does not say when to prefer this tool over alternatives like docker_exec or docker_db_admin, nor does it state exclusions or prerequisites such as needing a running container. The guidance is 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.

• docker_healthA
  3.8/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses that 'healthy' is branch-specific, that every answer explains its own verdict, and that services without a healthcheck are reported as 'none' rather than sick. This materially reduces the risk of misinterpreting results.

  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 short sentences cover the branches, the core ambiguity, and the no-healthcheck edge case with no filler. The most decision-relevant nuance—'healthy means something different in each branch'—is front-loaded.

  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 read-only health tool with an output schema and fully documented parameters, the description supplies the key behavioral caveats. It is complete enough to invoke correctly, though it could be slightly stronger with an explicit statement that it performs no container changes.

  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 already describes all five parameters with 100% coverage, including the meaning of each action value. The description adds only a small amount of context about the healthcheck interpretation, so it does not need to compensate for missing schema details.

  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 names the three actions and what each reports: container healthchecks, server health, and configured Docker hosts. It is clear, but it never explicitly contrasts itself with sibling tools like docker_container_control or docker_logs, so some differentiation is left to inference.

  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 action descriptions imply this is the tool for health and status checks, and the description warns about the different meanings of 'healthy.' It does not state when to prefer this over a control or log sibling, nor does it give explicit when-not-to-use guidance.

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

• docker_db_adminA
  4.1/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description reveals important behavioral traits: restore overwrites data, is refused without confirm, backup verifies by reading back, and the result must name a file of known size. This materially helps an agent understand what to expect and demand from the 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?

  Two dense sentences with no filler. The actions are front-loaded, and every clause adds either behavioral guidance or a verification requirement that an agent would otherwise miss.

  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 complex 14-parameter tool, the description covers the critical safety and verification behaviors while relying on the richly documented schema for parameter details. It is missing only an explicit distinction from docker_db, but otherwise gives sufficient context.

  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 structured schema already documents all parameters. The description adds useful context around confirmation and output verification, but does not add parameter-specific semantics beyond what the schema provides.

  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 names specific actions ('backup takes a dump of a database container, restore fills the database from one') and the resource being operated on. It clearly distinguishes the two modes, though it does not explicitly differentiate this tool from the sibling docker_db.

  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 gives clear operational context: restore is destructive, requires confirmation, and should be preceded by a backup ('take a backup here first'). It does not explicitly state when to choose this tool over docker_db, so it stops short of full alternative routing.

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

• docker_composeA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark the tool readOnlyHint=true, and the description adds meaningful behavioral context: it reads files, not a running process, and values reflect declared state rather than current container state. This clarifies the tool's semantics beyond the structured hint without contradicting it.

  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 tightly written sentences, front-loaded with the core purpose and then the key distinction from the runtime tool. Every sentence earns its place with no filler or restatement of schema details.

  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 a rich 7-parameter schema, complete schema descriptions, an output schema, and read-only annotations, the description covers the essential conceptual gap: declared config vs actual running state. It could have explicitly referenced the resolve-cost or project-label edge cases, but those are already handled in the schema.

  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 every parameter is already documented. The description mostly mirrors the schema's action enum wording ('config', 'env') rather than adding new parameter-level meaning. It earns the baseline score for not undermining the schema, but adds little beyond it.

  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 opens with a specific verb and resource: 'Reads what the project declares', then names the two actions (config, env) and explicitly distinguishes itself from docker_container. An agent can tell exactly what this tool accesses and how it differs from related tools.

  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 clearly frames the tool as the read-only declarative view of a compose project and points to docker_container for what is actually running. It gives useful context for when to pick this over the runtime-oriented sibling, though it does not enumerate exclusions for every sibling like docker_compose_control.

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

• docker_containerA
  4.3/5.0
  Behavior4/5

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

  Annotations already mark the tool as readOnlyHint=true, and the description adds meaningful behavioral detail beyond that: unknown project names are refused with existing names, an empty list means the host runs nothing under compose, and compose_path is used when no container carries the project label. This gives the agent context about edge cases without contradicting annotations.

  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 with no filler. The primary functions are stated first, then a useful edge-case clarification, then the sibling routing. Every sentence earns its place and the structure is easy to scan.

  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?

  With an output schema present and a readOnlyHint annotation, the description covers all essential guidance for both actions: what list returns, what stats measures, project name refusal behavior, empty-list meaning, and compose_path usage. Nothing critical is missing for an agent to select and invoke this tool correctly.

  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 input schema already documents all five parameters thoroughly. The description adds contextual color around project name refusal and compose_path, but it does not significantly extend parameter-level meaning beyond what the schema provides. 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 names the resource (docker containers of a project) and the specific actions: listing state/health/published ports and measuring current resource consumption via stats. It also distinguishes itself from docker_container_control by noting that moving containers between states belongs to that sibling tool.

  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 gives solid guidance on when to use this tool: for read-only listing and stats measurement. It explicitly refers moving containers between states to docker_container_control, which prevents misuse. It does not discuss other sibling tools like docker_logs or docker_health, but the main read-oriented selection is clear.

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

• docker_resourceA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already establishes safety, so the description adds meaningful extra context: an empty list means the query ran and found nothing rather than never having been executed. It also clarifies the semantic difference between listing resources and measuring disk usage.

  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 tightly written sentences convey purpose, scope, empty-list semantics, and the sibling alternative with no wasted words. The core distinction is front-loaded and every sentence earns its place.

  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?

  With a full input schema, a readOnlyHint annotation, and an output schema present, the description covers the key behavioral nuance and the main alternative tool. Nothing an agent needs to select and invoke this tool correctly is missing.

  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 schema already documents both the action enum and profile parameter. The description adds little beyond the schema for parameters, which matches the baseline of 3.

  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 for each action: images, volumes, and networks list what the host holds, while disk measures usage. It also explicitly distinguishes itself from the docker_container sibling by noting that current running-container consumption belongs to docker_container with stats.

  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 gives clear context on what the tool is for and explicitly points to docker_container as the right tool for live container consumption. It does not enumerate every sibling alternative, but the main decision boundary is stated clearly.

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

• docker_logsA
  4.4/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, and the description goes well beyond that: empty list means empty window, not failure; dropped lines are counted, not silently lost; stream and timestamp are returned per line. This is exemplary behavioral disclosure.

  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, no filler. The main action is front-loaded and every sentence adds either purpose or behavioral nuance. It earns its length.

  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?

  The output schema covers return values, annotations cover the read-only safety profile, and the schema covers parameter meanings. The description fills the remaining gaps: empty-vs-failure semantics, dropped-line accounting, and window-vs-count guidance. Nothing essential is missing for an agent to call it correctly.

  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 covers all eight parameters with individual descriptions, earning the baseline 3. The description adds a non-obvious parameter relationship — 'Narrow the window with since and until instead of raising the count' — which gives agents useful decision logic beyond the schema.

  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 states a specific verb and resource: 'Reads what a container printed, line by line.' It also adds useful detail about line content (stream and timestamp). However, it doesn't explicitly distinguish itself from sibling tools like docker_container or docker_exec, so it misses the top bar.

  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 makes the use case clear (reading container output) and even gives strategic advice: narrow with since/until rather than increasing the line count. It doesn't name alternative tools or say when not to use this tool, so it's clear context without exclusions.

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

• docker_container_controlA
  4.5/5.0
  Behavior4/5

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

  Annotations already flag idempotent and destructive. The description adds meaningful behavior beyond that: it returns the previous and current states, uses 'changed' to signal whether the call did anything, and explains that a timed-out stop surfaces as killed with its exit code, not a clean stop.

  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 dense sentences with no filler; the core operation and scope appear first, and the key edge-case behavior follows. Every sentence adds information.

  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 a 100%-covered schema, an output schema, and annotations for idempotency/destructiveness, the description covers the important runtime semantics (state reporting, changed flag, timeout kill behavior) and the sibling alternative. Nothing essential is missing.

  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 applies. The description does not expand on individual parameters; the schema already documents action values, timeout default, profile/project defaults, and compose_path behavior.

  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 names the exact operation ('Moves one service between states'), lists the three actions, and clarifies scope ('one service') while pointing to docker_compose_control for the whole stack. This distinguishes it from siblings immediately.

  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?

  It explicitly states the single-service scope and names the alternative for whole-stack operations: 'The whole stack at once is docker_compose_control.' This is direct routing guidance with the closest sibling, so an agent can decide correctly.

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

• docker_execA
  4.5/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description explains that destructive commands are refused until they carry '# CONFIRMED-DESTRUCTIVE', and clarifies the exit_code null and empty stdout semantics. These are meaningful behavioral details not present in the annotations or schema.

  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 compact and front-loaded with the core action and result, then covers output semantics, safety, and alternatives in a few tight sentences. Every sentence earns its place with no redundant filler.

  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 high schema coverage, the output schema, and annotations, the description covers the essential non-obvious context: exit code null meaning, empty stdout meaning, the destructive-command guard, and the boundary with sibling tools. No critical gap remains for a tool this 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 description coverage is 100%, so the schema already documents all parameters. The description adds general behavioral context about commands and output, but it does not materially deepen parameter-level meaning beyond what the schema provides. 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 names a specific verb ('runs a command'), a specific resource ('inside a service container'), and its key outcome ('brings back its exit code, with stdout and stderr apart'). It also differentiates from siblings by pointing out that logs, database queries, and dumps have dedicated tools.

  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 gives useful context for when to use this tool versus alternatives: reading logs, asking a database, and taking dumps are explicitly routed elsewhere. It also explains the destructive-command refusal mechanism. However, it does not name the exact sibling tools or spell out a crisp when-not-to-use condition beyond those categories.

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

• docker_compose_controlA
  4.6/5.0
  Behavior5/5

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

  Beyond the destructive and idempotent hints, the description reveals critical behaviors: it reports daemon truth rather than compose intent, it fails loudly on partial stack bring-up, and volume deletion requires confirmation. This gives the agent important operational context that annotations alone do not provide.

  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 only three sentences but packs in the core action, the critical reporting behavior, and the destructive edge case. Every sentence earns its place, 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.

  Completeness4/5

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

  For a complex tool with 11 parameters and nested objects, the description stays focused on the operational essentials and leaves parameter-level details to the well-covered schema. It is complete enough for an agent to invoke correctly, though it does not explicitly guide selection versus sibling tools.

  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%, so the baseline is 3, but the description adds meaningful behavioral semantics around parameters like volumes and confirm by explaining the destructive consequence and the refusal without confirmation. It also clarifies that results reflect daemon state, which helps interpret the action parameter's effect.

  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 names the exact operation on a specific resource: bringing a compose stack up or down. It also distinguishes its reporting behavior from compose's own description by saying it reads actual daemon state, which separates it from sibling tools like docker_compose.

  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 makes clear it acts on the whole stack and reports real container state, so an agent can infer this is the stack-level control tool rather than a single-container tool. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for correct selection.

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