Skip to main content
Glama
john-broadway

Proximo

by john-broadway
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

audit_verify

Verify the tamper-evident audit ledger's hash chain to prove logs are intact; pass an off-box pinned head value to detect truncation, forged appends, or replacement.

Instructions

Verify the tamper-evident audit ledger's hash chain — PROVE the log is intact.

Pass expected_head (the head() value you pinned off-box) to also catch tail truncation, a forged tail-append, or a full file replacement — a forward walk alone can't see those. Falls back to PROXIMO_AUDIT_EXPECTED_HEAD when omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expected_headNo64-char hex head() value pinned off-box; verifying against it also catches tail truncation, a forged tail-append, or a full ledger replacement. Omit to fall back to PROXIMO_AUDIT_EXPECTED_HEAD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.31.1
    • removedInput schema / properties / expected_head / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / expected_head / title
      Removed value: -"Expected Head"
    • addedInput schema / properties / expected_head / type
      Added value: +[
+  "string",
+  "null"
+]
    • removedInput schema / title
      Removed value: -"audit_verifyArguments"
  2. Changed1 schema field changedv0.21.0
    • addedInput schema / properties / expected_head / description
      Added value: +"64-char hex head() value pinned off-box; verifying against it also catches tail truncation, a forged tail-append, or a full ledger replacement. Omit to fall back to PROXIMO_AUDIT_EXPECTED_HEAD."
  3. First observedv0.18.1

TDQS

A3.9/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 burden and does disclose meaningful behavior: what each verification mode detects, the limitation that a forward walk alone cannot catch those cases, and the env-var fallback. It omits permission/auth requirements and what a failed verification returns, but the failure-mode coverage is unusually specific.

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?

Front-loaded with the imperative action and the payoff, then the optional parameter's value. Three compact sentences with no filler; 'PROVE' in caps is slightly rhetorical and the expected_head explanation duplicates the schema text.

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?

For a one-optional-parameter verification tool with no annotations and no output schema, the description covers the decision-relevant behavior and env-var semantics. The notable remaining gap is what verification returns and how a mismatch is surfaced, which nothing else in the definition documents.

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?

Schema description coverage is 100% and the parameter's schema description is nearly verbatim what the tool description says, so the description adds little beyond the schema. Baseline 3 applies for high coverage; the meaning of the value (an off-box pinned head() hex) is clear but already documented.

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?

States a specific verb and resource: 'Verify the tamper-evident audit ledger's hash chain', with the added goal of proving the log is intact. An agent can distinguish this from audit_entries (a read/enumeration tool) by the verification framing, though the sibling is never named explicitly.

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?

Gives clear conditional guidance: pass expected_head to catch tail truncation, forged tail-append, or full file replacement, and states the fallback to PROXIMO_AUDIT_EXPECTED_HEAD when omitted. It stops short of stating when to choose audit_verify over audit_entries or when verification is unnecessary.

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