Skip to main content
Glama

ledger_entries

Read the hash-chained audit ledger of predict, explain, and verify calls in order, and check whether the chain is intact to detect edits or deletions.

Instructions

Read the audit ledger: every predict, explain and verify call, in order.

Also reports whether the ledger's hash chain is intact (it breaks if an earlier entry was edited or deleted).

Args: last_n: how many of the most recent entries to return. order_id: only entries about this order. tool: only entries from this tool ("predict", "explain" or "verify").

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ledger_entries"
  }
}

Input Schema

NameRequiredDescriptionDefault
toolNo
last_nNo
order_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full load, and it does meaningful work: it declares the read-only nature, the ordering guarantee, and a non-obvious behavior — the hash-chain integrity report and the fact that it breaks on edited/deleted entries. It does not cover pagination limits or how the integrity verdict is surfaced in the response.

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?

Purpose and the surprising integrity behavior are front-loaded, followed by a compact Args block. No sentence is redundant.

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

Completeness4/5

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

Read-only, ordering, filtering and integrity semantics are all covered for a tool with no annotations and no output schema. The remaining gap is the shape of the return value (entry fields, how chain status is reported), which an agent would have to discover at call time.

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 0%, so the description must compensate, and it does: all three parameters are explained, and crucially it supplies the allowed values for 'tool' ('predict', 'explain' or 'verify') that the schema lacks via any enum. The default of last_n=10 is left to 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?

Opens with a specific verb and resource ('Read the audit ledger') and defines the content precisely as 'every predict, explain and verify call, in order' — which also disambiguates it from the sibling action tools predict/explain/verify that merely write those entries.

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 integrity-check sentence and the per-order/per-tool filters convey the auditing use case clearly, so an agent knows when to reach for it. It stops short of stating exclusions or naming an alternative (e.g. list_orders) for non-audit lookups.

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