Skip to main content
Glama
vmware-skills

io.github.zw008/vmware-debug

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

case_grade

Compute and record the investigation conclusion grade for a VMware case from the evidence ledger, returning grade, direction, and hypothesis statuses to guide next diagnostic steps.

Instructions

[WRITE] Compute and record the conclusion grade — steps 07/08.

WHEN: when you think the investigation has reached a conclusion, or to record where it stands before handing it over.

There is deliberately NO parameter for the grade. You cannot state a conclusion level; it is recomputed from the ledger on every call. If you disagree with the result, change the ledger — submit the evidence that is missing, or record the gap that is blocking it.

The levels: Candidate (a hypothesis exists); Probable (at least two INDEPENDENT sources agree — two calls to the same skill are one source — and nothing outstanding could overturn it); Confirmed (that, plus a decisive item: a direct hardware diagnostic, a version-checked knowledge-base entry, or a vendor SR, and no gap left open); Excluded (an observation that actually rules the hypothesis out — "we looked and found nothing" is a gap, not an exclusion). Exclusion is per hypothesis, counting only sources that falsify THAT hypothesis; the case is Excluded only when every registered one is. A hypothesis contradicted but not yet ruled out holds the case at Candidate. Otherwise the grade counts only evidence that falsifies nothing.

RETURNS: {grade, previous, direction, reasons, ceiling, ceiling_reasons, rules_source, rules_origin, hypotheses}. hypotheses lists every registered hypothesis as {id, status: open|excluded}. direction is initial/up/down/unchanged — grades may go DOWN, and the history records it when they do.

GOTCHAS: on a stock install ceiling is "probable", because Confirmed needs a decisive source and there is neither a hardware-diagnostic channel nor a knowledge library mounted yet. That is a real limit, not a caution. Every grading is appended to conclusion.md and none is ever rewritten.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
case_idYesThe case to grade (from case_open/case_list). This is the only parameter — see above for why there is no grade parameter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.13.0
    • changedInput schema / title
      Previous value: -"_case_grade_implArguments"New value: +"case_gradeArguments"
  2. Addedv1.11.1

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses rich behavioral traits beyond the annotations: the grade is recomputed from the ledger, there is deliberately no grade parameter, grades may go down, every grading is appended to conclusion.md and never rewritten, and stock-install ceiling is 'probable.' This goes far beyond the minimal annotation hints.

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 average but is well-structured with WHEN, RETURNS, and GOTCHAS sections, and the content is substantive. The unexplained 'steps 07/08' reference and the lengthy level definitions add some bulk, but the sections make it scannable and front-loaded with the 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?

Given the single parameter and no output schema, the description is remarkably complete: it defines all grade levels, explains the ceiling edge case, details the return fields including direction and hypotheses, and notes the append-only recording behavior. An agent has everything needed to call it 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?

The input schema already documents case_id fully, including its source ('from case_open/case_list') and the absence of a grade parameter. The description reinforces this but does not add substantially new parameter-level meaning beyond what the schema covers, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Compute and record the conclusion grade.' It also ties the action to workflow steps (07/08) and explains what the tool is not doing (accepting a grade parameter), which distinguishes it from evidence-submission and gap-recording siblings.

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?

The 'WHEN' section explicitly states the invocation condition: when the investigation has reached a conclusion or before handover. It also gives alternative actions when the agent disagrees with the computed grade—'submit the evidence that is missing, or record the gap that is blocking it'—which routes the agent away from the wrong tool.

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

Deploy Server

Other Tools