Skip to main content
Glama
vmware-skills

io.github.zw008/vmware-debug

case_timeline

Correlate submitted case evidence into a reproducible timeline, detect spikes, and rank root-cause hypotheses using only the case folder's payloads.

Instructions

[WRITE] Correlate everything this case has collected — steps 04/05.

WHEN: once evidence is in. Unlike incident_timeline, this takes no events: it reads the payloads already submitted, so the result is reproducible from the case folder alone months later, on a machine with access to nothing.

RETURNS: {event_count, window, binning, classification, spikes, spikes_total, hypotheses, evidence_without_events, evidence_without_events_detail, rejected, note} and writes timeline.md.

GOTCHAS: note distinguishes three states that all show zero events — no evidence submitted at all, evidence that carried none, and a genuinely quiet window — and names which items carried none, with what they held instead. rejected names any row that could not be read, with the evidence item it came from; dropping those silently would shrink the picture the conclusion rests on. Submit a read tool's raw result as payload for its events to reach here — a summary of the result carries no rows, and case_submit_evidence says so at the time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNoHow many ranked hypotheses come back (default 5). Spikes are capped separately at 20, true count in 'spikes_total'.
case_idYesThe case whose submitted payloads are correlated (from case_open/case_list). Unlike incident_timeline this takes no events — everything comes from the case folder.
bin_secondsNoTime-bin width in seconds. Omit and it is chosen from event density (ladder 1..86400, finest width still averaging 4 events per bin); `binning` reports which was used.
z_thresholdNoStandard deviations above the mean bin count that mark a spike (default 2.0). Under 3 bins, or a flat series, yields none at any threshold.

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.9/5.0
Behavior5/5

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

Annotations are all false, so the description carries the full behavioral burden. It discloses it writes timeline.md (consistent with readOnlyHint=false), explains the tool's reproducibility from the case folder alone, and details the `note` and `rejected` fields, including the three zero-event states and consequences of silent row drops. No annotation contradiction.

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?

Organized into clear sections (WHEN, RETURNS, GOTCHAS) with the core purpose front-loaded. Every sentence carries weight—no fluff—and the length is justified by the density of critical operational details.

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 correlation tool without an output schema, the description lists all return fields and explains nuanced behaviors (note, rejected, spike thresholds). It covers usage prerequisites, input expectations, and gotchas, making it self-sufficient for an agent to call accurately.

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 baseline is 3. The description adds meaningful context for `case_id` (source from case_open/case_list, contrast with incident_timeline) and clarifies expected payload format for events (though that's more usage than parameter-specific). Modest value over schema, but not extensive, warranting a 4.

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 '[WRITE] Correlate everything this case has collected — steps 04/05,' stating a specific verb, resource, and workflow step. It clearly distinguishes itself from incident_timeline by emphasizing it takes no events and reads submitted payloads, leaving no ambiguity about its role.

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?

Explicit WHEN guidance ('once evidence is in') and a direct contrast with incident_timeline ('Unlike incident_timeline, this takes no events'). It also gives actionable instructions on how to feed the tool ('Submit a read tool's raw result as `payload`') and cautions against using summaries (which carry no rows), fully covering when and how to use it vs alternatives.

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