WorkloadTruth MCP Server

Overview Schema Source Related Servers Discussions Admin

verify_audit_log

Verify a WorkloadTruth audit log's hash chain integrity to detect edited, reordered, or deleted entries. Run before trusting records for security- or billing-sensitive decisions.

Instructions

Verify that a local WorkloadTruth audit log's hash chain is intact, i.e. no entry was edited, reordered, or deleted after it was written.

Call this before trusting historical classify_workload / workloadtruth watch records for anything security- or billing-sensitive -- each log entry's hash covers its own content plus the previous entry's hash, so any tampering anywhere in the file breaks the chain from that point forward and this tool will report exactly where.

Prerequisites: the file at log_file must exist and be a WorkloadTruth JSONL audit log (produced by write_to_audit_log=True on classify_workload, or by workloadtruth watch).

Side effects: read-only. Opens and reads log_file from local disk; never writes, never makes a network call. Safe to call repeatedly and idempotent -- verifying an unmodified log always returns the same result.

Parameters: log_file -- path to the JSONL audit log, defaults to workloadtruth.log.jsonl in the current working directory. Example call: {"log_file": "workloadtruth.log.jsonl"}.

Returns a dict with valid (bool), message (str -- "chain OK" or a description of the first broken link found), and entries (int count of entries verified before any break).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`log_file`	No		workloadtruth.log.jsonl

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 27, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries full behavioral burden. It openly discloses side effects ('read-only', 'never writes, never makes a network call'), repeatability and idempotence, and explains the hash-chain failure semantics. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though longer than average, every sentence carries essential information: what the tool checks, when to use it, prerequisites, side effects, parameter semantics, and return shape. The most critical usage guidance is 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?

For a tool with one optional parameter and an output schema already present, the description is complete. It covers purpose, prerequisites, side effects, parameter details, and return fields. Even without an output schema, an agent could call this correctly.

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?

Schema description coverage is 0%, so the description must compensate, and it does fully. It explains what log_file is, its default value and location, and gives an example call. This adds meaning well beyond the bare type/default in the 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?

States a specific verb and resource: 'Verify that a local WorkloadTruth audit log's hash chain is intact.' It also defines the precise guarantees checked (no entry edited, reordered, or deleted). Clearly distinguishable from siblings classify_workload and run_benchmark, which perform different operations.

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 when to call: before trusting historical classify_workload or workloadtruth watch records for security- or billing-sensitive purposes. It also states prerequisites, including the required format and provenance of the log file. This gives an agent a clear decision rule.

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

Deploy Server