Loading ToolBench
Prove what your AI agents did. Signed, tamper-evident audit receipts and exportable audit bundles for EU AI Act Article 12/26 record-keeping. MCP server + HTTP API; offline verification, hash-only privacy, deletion detection.
Four well-named tools with strong descriptions (100-200 chars each) and clear security/compliance focus. All tools have input schemas with typed parameters and descriptions. Naming follows verb_noun pattern (issue_, verify_, export_, get_). Descriptions explain WHAT, WHEN, and WHY. However, output schemas are not documented in the source code, responses are inferred from descriptions only. Error handling guidance is absent. Parameters lack constraints (enums, ranges, format specs). No pagination support documented for export_audit_bundle despite potentially large result sets.
Export all receipts in a date range as a signed audit bundle for a compliance officer or auditor. The bundle includes a tamper-evidence report: sequence gaps (deleted receipts) and hash-chain breaks are flagged. Timestamps are ISO 8601; omit both to export everything.
Return the service manifest: receipt schema version, signing key id, and the Ed25519 public key (base64 SPKI DER) to pin for offline verification.
Create a cryptographically signed, timestamped receipt proving that an agent performed an action. Call this immediately after any consequential action (approving an invoice, validating a supplier, sending a payment instruction, making a decision affecting a person) to build an audit trail that satisfies record-keeping obligations such as EU AI Act Articles 12 and 26. Pass the action details; if you include a payload it is SHA-256 hashed and immediately discarded — contents are never stored. Returns the signed receipt JSON, which verifies offline.
Check that an agent-receipts/v1 receipt is authentic: validates the Ed25519 signature, schema, and payload-hash format, and reports whether the receipt matches the copy stored in the vault. Use this before trusting a receipt presented by another agent or system.
Output schemas not documented. Tool descriptions infer return structure (e.g., 'Returns the signed receipt JSON') but no formal schema is visible in source code. LLMs cannot reliably extract fields or plan downstream operations without documented output types.
No error handling guidance. Tool descriptions lack recovery hints (e.g., 'If signature verification fails, check that the receipt was issued by this service'). LLMs cannot self-correct on failures.
Parameters lack format constraints. 'from' and 'to' in export_audit_bundle accept ISO 8601 strings but no regex pattern or format spec is declared. LLMs may pass invalid dates.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
No pagination documented for export_audit_bundle. Large date ranges could return thousands of receipts, blowing context windows. No limit, offset, or cursor parameters visible.
Payload parameter type is 'unknown' (any JSON). No validation rules or size limits documented. LLMs may pass extremely large payloads, causing performance issues.