Skip to main content
Glama

warden__audit

Access the append-only transparency log of all publishes and the current Merkle root to verify audit trails and detect tampering.

Instructions

The append-only transparency log (every publish) + current Merkle root.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description still conveys useful behavioral traits: 'append-only' implies the data is immutable and read-only, and 'every publish' scopes the content. However, it says nothing about volume (an unbounded log of every publish with no pagination parameters), response format, or whether the Merkle root is a separate field — real risks for a zero-parameter call.

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?

A single compact sentence with zero filler and the core scope front-loaded. It reads as a fragment rather than a statement of action, which costs a little clarity but no words are wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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

For a simple no-parameter tool with no output schema, the description adequately indicates both what is returned (the log) and the Merkle root. It is still thin on whether the result is truncated or how large the log can get, which matters for a tool that implicitly returns everything ever published.

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 takes zero parameters, so the baseline is 4 and the description creates no confusion about required input. There is nothing extra to document.

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 exact resource — the append-only transparency log covering every publish — plus the current Merkle root, which is specific enough to know what data comes back. It lacks an explicit verb (read/list/fetch) and does not distinguish itself from warden__list, which an agent may plausibly confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives such as warden__list or warden__recall, and no stated trigger or prerequisite. The agent must infer that this is for auditing published artifacts rather than general listing.

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