Loading ToolBench
Cryptographic accountability layer for MCP agent-to-agent interactions across multiple banks. Implements Ed25519 receipts, DAG ledger, Merkle batching, dispute packs, degraded-mode fallback, and WORM content encryption. Comprises Bank-A proxy, Bank-B proxy, independent witness (TrustAgentAI Cloud), and core cryptographic library.
This is NOT an MCP server. It is a custom HTTP REST API for a multi-bank accountability system. Tool definitions are inferred from OpenAPI-style endpoint descriptions, not registered via MCP protocol. No MCP tool registration, no JSON Schema input validation visible, no MCP transport layer detected. Descriptions are domain-specific but lack LLM-optimization guidance. Parameters are documented in prose but lack formal type constraints. Output schemas are not documented. This system operates as a standalone REST service, not as an MCP-compliant agent tool server.
Bank-B proxy retrieves all Merkle batch anchors (blockchain transactions)
Witness retrieves encrypted transaction content blob by content hash
Bank-A proxy audits the status of a degraded transaction: RECONCILED (has COSIGN), EXPIRED_UNRECONCILED (past deadline), or PENDING
Retrieves full Dispute Pack for a trace_id: all ledger entries plus Merkle proofs for each entry
Retrieves all stored envelopes (Intent, Acceptance, Execution, CoSign, Degraded records)
Server-Sent Events stream for real-time updates (envelopes, thoughts, anchor events, degraded-mode status)
Server health check endpoint
Retrieves TimestampRegistry lookup for a trace_id: all recorded events and their timestamps
Not an MCP server. This is a custom REST API with no MCP protocol implementation. Tools are not registered via MCP; no tool definitions exist in MCP format. Cannot be used as an MCP tool server.
No input schemas visible. Endpoint descriptions include prose parameter lists (e.g., 'intent', 'estimated_cost_usd') but no formal JSON Schema with type constraints, required fields, or validation rules. Cannot validate LLM-generated inputs.
Output schemas not documented. Endpoints return data (e.g., AcceptanceReceipt, ExecutionEnvelope, CoSignReceipt) but response structure is not formally specified. LLMs cannot plan downstream tool calls without knowing what fields are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Retrieves full epoch history (transparency log) of a key ID including validFrom/validUntil timestamps
Retrieves all recorded agent thoughts/logs
Bank-A proxy returns current trigger state
Verifies the append-only hash-chain integrity (Bank-A, Bank-B, or Witness depending on endpoint)
Receives IntentEnvelope from Bank-A proxy, validates against risk budget and nonce registry, calls Bank-B decision agent for approval, returns AcceptanceReceipt with dual signatures (Proxy A + Proxy B)
Independent witness (TrustAgentAI Cloud) receives Intent + Acceptance pair, verifies both proxy signatures, co-signs with witness key, appends to witness hash-chain, returns CoSignReceipt
Receives ExecutionEnvelope from Bank-A proxy after tool execution, records in DAG ledger, returns dual-signed execution record
Bank-B proxy flushes pending DAG ledger entries into a Merkle batch, returns batch metadata with merkle_root and batch_id
Bank-A proxy reconciles a degraded transaction by retrying witness co-sign once it recovers (Delta #7)
Witness (TrustAgentAI Cloud) registers a bank proxy public key with optional key rotation endorsement
Bank-B proxy registers a peer (Bank-A) public key with optional key rotation endorsement signature
Clears all state (envelopes, thoughts, ledger, blobs) — demo/testing only
Witness revokes a bank proxy public key with endorsement signature (Delta #6)
Bank-B proxy revokes a peer public key with endorsement signature (Delta #6 key rotation)
Records a thought/log message from an agent, broadcasts via SSE
Bank-A proxy triggers demo scenario, broadcasts SSE event
Bank-A proxy marks demo trigger as complete
Witness stores encrypted transaction content (WORM store, Delta #5): ciphertext + wrapped DEKs for each holder
Naming inconsistency and lack of verb-first convention. Endpoints use REST conventions (POST, GET, PUT) but tool names should start with action verbs (get_, create_, update_, delete_). Names like 'POST /accept' and 'POST /co-sign' are unclear without context.
No error handling guidance. Descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. No mention of retryable vs. fatal errors, or actionable error messages.