Proximo

Overview Schema Source Related Servers Discussions Admin

audit_verify

Read-only

Read-only checks that walk an audit chain and report the first break, catch a cut tail with expected_head, and verify a sealed archive using path.

Instructions

READ-ONLY: walk the chain, report the first break; expected_head catches a cut tail; path= checks a sealed archive.

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": "audit_verify"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No
`expected_head`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.49.1Oct 27, 2026
- removedInput schema / properties / expected_head / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / expected_head / default
```
Removed value: -null
```
- removedInput schema / properties / expected_head / title
```
Removed value: -"Expected Head"
```
- addedInput schema / properties / expected_head / type
```
Added value: +"string"
```
- removedInput schema / properties / path / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / path / default
```
Removed value: -null
```
- removedInput schema / properties / path / title
```
Removed value: -"Path"
```
- addedInput schema / properties / path / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"audit_verifyArguments"
```

Changed7 schema fields changedv0.46.2Oct 24, 2026

addedInput schema / properties / expected_head / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / expected_head / description

Removed 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."

addedInput schema / properties / expected_head / title
```
Added value: +"Expected Head"
```
removedInput schema / properties / expected_head / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

addedInput schema / properties / path

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Path"
+}

addedInput schema / title
```
Added value: +"audit_verifyArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "audit_verifyDictOutput",
+  "type": "object"
+}

Changed4 schema fields changedv0.31.1Aug 7, 2026
- 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"
```

Changed1 schema field changedv0.21.0Jul 13, 2026

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."

First observedv0.18.1Jul 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The description reinforces the readOnlyHint with an upfront READ-ONLY label and adds useful behavior beyond annotations: it walks the chain and reports the first break. It also explains that expected_head detects a cut tail, which is meaningful verification context. With an output schema present, return details need not be repeated.

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?

Extremely compact and front-loaded. The READ-ONLY constraint comes first, followed by the core behavior and the two parameter use cases, with no wasted 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?

Given the output schema and readOnly annotation, the description provides the essential operational context: read-only nature, chain-walking behavior, truncation detection, and archive checking. A brief clarification of what 'chain' refers to would make it fully self-contained.

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 description coverage is 0%, so the description carries the burden and does so reasonably. It assigns clear meaning to path as an archive path and expected_head as a truncation check, though it omits optionality, format expectations, and examples.

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+resource combination: walking an audit chain and reporting the first break. It separates itself from audit_entries by describing verification rather than listing, though 'chain' remains somewhat jargon-dependent and the sibling is not 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 Guidelines3/5

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

The description explains when to use each parameter — expected_head for detecting a truncated tail and path for checking a sealed archive. It does not state when to choose audit_verify over audit_entries or other alternatives, leaving selection guidance implicit.

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

Deploy Server