Server Quality Checklist

Tool Scores

• engineering.vps.capacityA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so thoroughly. It discloses determinism, read-only behavior, local OS evidence only, current-state scope, and explicitly states no mutation, shell, SSH, network, or secrets. This gives an agent a complete safety and behavior profile.

  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: it opens with the user's likely question, then gives the result format, scope, and constraints. Every sentence earns its place with no wasted wording.

  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?

  An output schema is present, so the description does not need to explain return values. The description covers purpose, input constraints, safety, and scope thoroughly, making it complete for a zero-input read-only tool.

  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?

  There are zero parameters, so the baseline is 4. The description additionally states 'Input must be exactly {}', which reinforces the schema's empty object requirement and removes any ambiguity about needing arguments.

  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 that the tool returns a deterministic read-only pressure assessment (OK | PRESSURED | UNKNOWN) for CPU load and memory, built from local OS evidence only. It also scopes the behavior to current state and explicitly excludes prediction and upgrade advice, which distinguishes it from the sibling health tool.

  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 question form and exclusions imply this tool is for current capacity checks rather than prediction or upgrade guidance. However, it never explicitly names the sibling tool or states when to prefer one over the other, so usage guidance remains implied rather than explicit.

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

• engineering.app.healthA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels: it declares read-only, deterministic behavior, no mutation/shell/SSH/network/secrets, precisely defines the UNAVAILABLE vs UNKNOWN semantics, and clarifies that evidenceAgeSeconds is factual and never alters the status. The negative list of non-behaviors is unusually thorough.

  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 dense but every sentence earns its place: verdict values, source identity, status semantics, exclusions, and safety guarantees. It is front-loaded with the core purpose. It runs long relative to its simple scope, but given there are no annotations or parameter descriptions to lean on, the length is justified.

  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 zero-parameter, deterministic read tool with an output schema present, the description is complete: it covers the verdict space, source provenance, status meaning, evidence-age semantics, exclusions, input contract, and safety profile. Nothing an agent needs to invoke it correctly is missing.

  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?

  With zero parameters, the baseline is 4, and the description adds meaningful reinforcement beyond the empty schema by stating 'Input must be exactly {}' and explaining why ('no new configuration'), which helps an agent understand there is genuinely nothing to supply.

  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+resource (reports application health state from the configured evidence source) and enumerates the exact verdict domain (HEALTHY | DEGRADED | UNKNOWN | UNAVAILABLE). It explicitly distinguishes itself from siblings by declaring what it does NOT do: probe the application, inspect Docker, call HTTP, infer from deployment status, or diagnose root cause.

  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 positioning it as sharing 'the same source and configuration as engineering.deploy.status' and provides explicit when-not boundaries (not for probing, Docker inspection, HTTP calls, root-cause diagnosis). It falls just short of a 5 because it doesn't explicitly name the alternative tool to use for each excluded case.

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

• engineering.vps.healthA
  4.6/5.0
  Behavior5/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, and it does this well. It states the operation is deterministic, read-only, local-only, and free of mutation, shell, SSH, network, and secrets. This gives the agent a precise and trustworthy safety profile.

  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 with no filler. The question front-loads the purpose, the verdict and evidence source are stated precisely, and the constraints are packed into a single clear list. 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?

  For a zero-parameter tool with an output schema, the description is complete. It covers purpose, input format, safety, and scope. The only minor omission is an explicit pointer to the sibling capacity tool, but that is not necessary for correctly invoking this tool.

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

  Parameters5/5

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

  There are zero parameters, so the baseline is 4, but the description adds explicit clarity by stating 'Input must be exactly {}.' This removes any ambiguity about whether an empty body or no body is expected, which is the only possible parameter-semantics concern for this tool.

  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 is explicit about what the tool does: it returns a deterministic read-only verdict (HEALTHY | DEGRADED | UNKNOWN) based on local OS evidence. This clearly identifies it as a VPS health check, but it does not explicitly differentiate it from the sibling engineering.vps.capacity 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 opening question 'Is my VPS healthy?' provides a clear context for use, and the constraints 'No mutation, no shell, no SSH, no network, no secrets' give the agent strong usage boundaries. However, it does not mention when to prefer this tool over engineering.vps.capacity or state any explicit alternatives.

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

• engineering.vps.why_downA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and fully discloses behavior: deterministic, read-only, no shell/SSH/network probe/Docker socket/logs/secrets/LLM, no mutation, and no selection authority. It also details what it reports (normalized signal names, degraded/unknown/not-observable) and explicitly states correlation is not causation. This is exemplary transparency.

  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 dense but efficiently front-loaded with the purpose question, then method, outputs, and constraints. It is longer than typical, but every sentence adds value given the lack of annotations and the need to set firm expectations. Some minor redundancy exists between 'SIGNALS, not root causes' and 'correlation is never presented as causation', but the structure is logical and scannable.

  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?

  This is a complex diagnostic tool with no annotations, an empty schema, and a rich behavioral profile. The description covers purpose, evidence sources, output signals, known limitations, prohibited actions, and input constraints. Since an output schema exists, return-value details are appropriately omitted. The tool is fully specified and an agent can invoke it without ambiguity.

  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 already documents an empty parameter set with additionalProperties=false. The description reinforces this by stating input must be exactly {} and explains why (the agent can never select a host, application, container, or path). With zero parameters, this goes beyond the schema by clarifying the intent of the empty input, though it largely restates the schema constraint.

  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 opens with a clear question ('Why does the currently configured VPS/application appear unhealthy?') and identifies a specific verb/resource: deterministic read-only diagnostic synthesis of existing evidence. It explicitly distinguishes itself from simpler health or capacity tools by emphasizing normalized signals and explicitly denies root-cause authority, making its role distinct among siblings.

  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 the tool: any time the agent needs a synthesized explanation for why the configured VPS/application appears unhealthy. It provides strong exclusions ('no recovery or deployment authority', 'SIGNALS, not root causes') that guide the agent away from expecting fixes. It does not explicitly name alternative tools for deeper investigation, but the limitations make the decision boundary clear enough.

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

• engineering.deploy.readyA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the burden and does an excellent job. It discloses that the tool is deterministic, read-only, advisory, performs no mutation/shell/SSH/network/secrets access, never changes the verdict based on evidenceAgeSeconds, and explains the UNKNOWN vs UNAVAILABLE distinction. This is far more behavioral detail than typical tool descriptions.

  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 front-loaded with the core purpose and verdict types, then systematically covers evidence source, verdict meanings, and safety limitations. It is longer than strictly necessary and contains some redundancy around being advisory and non-mutating, but every sentence carries meaningful operational information for a deployment-related tool.

  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?

  Despite having zero parameters and an output schema, the tool is safety-sensitive and potentially confusing due to its deployment-related name. The description provides complete context: evidence sources, verdict semantics, advisory scope, input requirements, and explicit non-actions. An agent has enough information to decide whether to call it and what the verdict means.

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

  Parameters5/5

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

  The tool has zero parameters and the schema already reflects an empty object with additionalProperties false. The description adds explicit reinforcement that 'Input must be exactly {}', which removes any ambiguity about whether optional or unexpected fields could be accepted. This fully addresses parameter semantics even without parameters.

  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 opens with a clear, specific question ('does the application satisfy the minimum deterministic prerequisites for attempting a deployment?') and names the exact return values READY | NOT_READY | UNKNOWN | UNAVAILABLE. It distinguishes itself from engineering.deploy.status by explicitly naming it as a sibling using the same evidence source while clarifying this tool is an advisory readiness check.

  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 strong context for when to use the tool: when a deterministic read-only readiness verdict is needed, based on existing evidence, without new configuration. It names engineering.deploy.status as sharing the same evidence source and clearly states exclusions ('does not predict deployment success', 'does not inspect code, migrations or release contents'), though it does not explicitly say 'use X instead' for alternative scenarios.

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

• engineering.deploy.statusA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden. It clearly states the tool is deterministic, read-only, restricted to a single configured JSON source, and performs no mutation, shell, SSH, network, or secret access. It also explains the UNKNOWN/UNAVAILABLE edge semantics and that evidenceAgeSeconds never influences the verdict.

  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?

  Every sentence earns its place: source, verdict semantics, evidence-age behavior, exclusions, input constraint, and side-effect denials. The description is longer than average but tightly packed and front-loaded with its core purpose.

  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 presence of an output schema means return fields need not be enumerated, and the description still covers edge-state semantics, evidence-age behavior, input constraints, and non-effects. An agent has all necessary context to invoke and interpret this tool 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 input schema already exhaustively defines the only valid input as {} with additionalProperties false, so the description adds minimal parameter information beyond restating "Input must be exactly {}." The zero-parameter baseline of 4 applies, as the description confirms the expected empty input.

  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 opens with a precise question—"What deployment state is reported by the configured application/deployment evidence source?"—and enumerates the exact deterministic verdict set. It also explicitly distinguishes itself from siblings by ruling out health, capacity, readiness, and failure-cause assessments.

  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 when-not-to-use guidance by excluding application health, VPS health, readiness to deploy, and failure causes, which map to sibling tools. It also clarifies the meaning of UNAVAILABLE versus UNKNOWN to aid interpretation, though it stops short of naming alternative tools explicitly.

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

• engineering.docker.healthA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full behavioral disclosure. It explicitly states read-only determinism, the absence of socket/CLI/probe access, no mutation or recovery authority, no root cause inference, and the exact meaning of UNKNOWN vs UNAVAILABLE. It even clarifies that absence of evidence is never read as HEALTHY. This is exceptionally transparent.

  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 longer than minimal but every clause earns its place by constraining an agent's behavior around a nuanced read-only tool. It is front-loaded with the core purpose and statuses, then systematically lists exclusions. The no-shell/no-SSH/no-network/no-secrets enumeration is slightly redundant as a group but serves as a strong safety reminder.

  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 zero-parameter tool with an output schema, this description is complete: it defines the evidence source, status semantics, exclusions, and input constraint. The output schema covers return values, so no additional description is needed there. Nothing an agent needs to correctly select and invoke this tool is missing.

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

  Parameters5/5

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

  The schema has zero parameters, so the baseline is already high, and the description strengthens it by stating the input must be exactly {} and that the agent can never select a container, host, path, or socket. This prevents hallucinated parameter usage better than the schema alone.

  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 opens with a direct question and immediately states the tool returns a deterministic advisory verdict from a specific evidence source. It clearly distinguishes Docker/container health from its siblings by explicitly stating it does not access the Docker socket, run the Docker CLI, or probe containers. The status vocabulary (HEALTHY | DEGRADED | UNKNOWN | UNAVAILABLE) and the resource scope are unambiguous.

  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 that this tool is for operator-configured Docker health evidence only and explicitly lists what the tool does not do (no shell, no SSH, no network, no mutation). It does not name sibling tools or provide explicit conditions for when to choose this tool over engineering.vps.health or engineering.app.health, but the boundaries are strongly implied.

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

• engineering.vps.what_changedA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so admirably. It discloses stateful behavior (first call creates baseline, server restart resets history), explicitly states no mutation, shell, SSH, network, or secrets, and even mentions the BASELINE_CREATED signal. This is outstanding 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?

  Every sentence earns its place: the purpose is front-loaded, the scope is clarified, exclusions are explicit, and constraints are listed compactly. No filler or redundancy.

  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 tool's simplicity (0 params, output schema present), the description covers everything needed for correct invocation: what it does, how state is managed, what it does not cover, and input constraints. There are no meaningful 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?

  The tool has zero parameters and the schema coverage is effectively 100%. The description reinforces the contract by stating 'Input must be exactly {}', which aligns with the schema. Per the baseline for 0-param tools, a 4 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 opens with a specific question, 'What changed since the previous observation made by this MCP process?', and then details exactly what is compared (uptime, CPU count, load, memory). It explicitly excludes deployment, file, service, and container history, which distinguishes it from sibling tools like engineering.deploy.status and engineering.docker.health.

  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 states the session/process scoped behavior and the baseline-creation pattern, giving the agent a concrete idea of when to use it. It provides exclusions ('does NOT provide deployment, file, service or container history') but does not name alternative tools explicitly, stopping just short of full routing guidance.

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

• engineering.logs.explainA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden and does so admirably. It explicitly states the tool is deterministic, read-only, advisory, has no shell/SSH/child processes/network/LLM/mutation/recovery authority, never touches the Docker socket, and reports unclassifiable signals as UNKNOWN while never returning evidence messages. This goes far beyond what annotations typically provide and leaves no hidden behavior.

  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?

  Although the description is long, every sentence contributes distinct information: purpose, source, exclusions, taxonomy, advisory nature, and input constraint. It is well-structured and front-loaded with the core purpose, then layers constraints and exclusions logically. There is no filler or repetition, making the length justified.

  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 description covers the tool's purpose, operational source, possible classification labels (EXPLAINED | UNKNOWN | UNAVAILABLE), deterministic taxonomy categories, all behavioral constraints, and the exact input shape. Since an output schema exists, it need not detail return structures. An agent has everything needed to invoke this tool correctly without guessing.

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

  Parameters5/5

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

  The input schema is an empty object with zero properties, so the baseline is 4. The description adds crucial semantic clarity by stating 'Input must be exactly {}' and explicitly enumerating what the agent can never select (path, file, container, service, journal, query, time range). This prevents an agent from hallucinating parameters that the schema alone might not fully convey for such a constrained no-input tool.

  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 opens with a clear question defining the tool's purpose: 'What do the currently configured operational log signals mean?' It further specifies deterministic read-only advisory explanations and explicitly distinguishes itself from a log browser by stating what it never does (never reads raw logs, never tails files, never runs grep/journalctl/docker logs). This makes it distinct from all sibling tools and leaves no ambiguity about its scope.

  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 strong contextual guidance: explanations are computed only from a fixed operator-controlled JSON file of normalized log signals, not from raw logs. It clearly states exclusions ('NOT a log browser'), which tells the agent when not to use this tool, but it does not explicitly name a sibling alternative. Still, the boundary is clear enough for practical selection.

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

• engineering.vps.incident.summaryA
  4.8/5.0
  Behavior5/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 so thoroughly: it discloses determinism, local evidence, the shared session-history side effect (counts as one observation), the output categories, fixed limitations, and explicit no-mutation/no-shell/no-SSH/no-network/no-secrets guarantees.

  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 purpose is front-loaded in the first clause, and every subsequent sentence adds necessary context: output categories, side effects, scope limits, input constraint, and safety guarantees. Dense but not wasteful.

  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 zero-parameter compositional tool with an output schema, this describes the semantic composition, return categories, side-effect coupling, and non-observations fully. Nothing needed for correct invocation is missing.

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

  Parameters5/5

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

  There are zero parameters, and the description still clarifies that the input must be exactly {}, reinforcing the schema's empty-object contract. This is more than the schema alone provides and removes any temptation to pass arguments.

  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 ('combines') and resource ('VPS') and states the deliverable: NORMAL, ATTENTION, or UNKNOWN with factual notes. It also distinguishes itself from siblings by explicitly excluding applications, services, containers, deployments, and logs, making its scope unmistakable.

  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?

  Clear context is provided: use this for a deterministic composition of health, capacity, and change observations on a VPS right now, not for root-cause claims. It gives exclusions (no apps/services/containers/deployments/logs), though it does not explicitly name which sibling should be used instead.

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