Loading ToolBench
Spend + tool-approval gate for AI agents — budget caps, HITL, and signed receipts so an MCP allowlist is never treated as authorization.
chp-mcp demonstrates strong definition quality with comprehensive schemas, detailed parameter documentation, and clear governance-focused descriptions. All 12 tools have explicit schemas with typed parameters and descriptions. Tool names follow verb-first convention (evaluate_, approve_, request_, place_, wire_, rebalance_, inspect_, issue_, authorize_, chp_). Descriptions are substantive (avg 180 chars) and domain-specific, explaining CHP protocol semantics (LOCKED/HITL_REQUIRED/BLOCKED states, receipt binding, audit logging). However, some descriptions use jargon without sufficient explanation for general LLM understanding, and output schemas are documented in text/comments rather than formally in the tool definitions. Error handling is implicit (policy denies written to ledger) but not explicitly documented per tool. Security model is clear but parameter-level guidance on when to use receipts vs raw approval could be stronger.
Human-in-the-loop approval for a proposal that returned HITL_REQUIRED. Cannot approve BLOCKED / hard-rule failures (spec §6.3 / §6.5). When tool + bound_args are supplied, mints a signed authorization receipt.
Consume a receipt (deny on drift/expiry/replay). Verify receipt signature, check expiry, detect replayed receipts, validate argument drift, and return authorization state.
Float-aware canonical content hash. Compute CHP consensus hash (deterministic, float-safe) of any JSON-serializable input.
Package / protocol versions. Return @cubiczan/chp-mcp and CHP protocol version information.
Run CHP Profile B capital/spend gate on a proposed action. Returns LOCKED, HITL_REQUIRED, or BLOCKED with claims and a content hash. Hard policy violations cannot be overridden by a human. BLOCKED is also written as a structured policy_deny to the CHP-signed audit ledger.
Allowlist ≠ authorization; bind a proposed call. Check if a tool call matches the approval policy, validate host-injected fields, and compute the args hash without executing.
Output schemas not formally documented in tool definitions. Descriptions refer to return types (e.g., 'Returns LOCKED, HITL_REQUIRED, or BLOCKED') but JSON Schema definitions lack explicit outputSchema specifications. LLMs cannot reliably parse what these tools return without seeing structured type definitions.
CHP-specific jargon in descriptions assumes domain knowledge (HITL, Consensus Hardening Protocol, policy_deny, scope binding, args hash, nonce, replay store). Descriptions like 'Run CHP Profile B capital/spend gate' do not explain what HITL means, when BLOCKED vs HITL_REQUIRED is triggered, or why a human approver is needed. LLMs may misunderstand or misapply these tools without clearer introduction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
CHP-chained deny / authorize / execute log. Read-only inspection of the Consensus Hardening Protocol audit trail.
Human allow/deny → signed receipt. Issue a cryptographically signed approval receipt after human decision, binding it to tool, resource, and args hash.
Synthetic equity order (scope trading:equities:place). No live venue. Requires a signed authorization receipt bound to these args. Receipt is optional on the wire so a missing receipt becomes a logged missing_receipt deny.
Synthetic portfolio rebalance (scope portfolio:rebalance). HITL at/above $1,000 notional. Requires a signed authorization receipt.
Request a signed authorization receipt for a scoped reference tool (place_equity_order, wire_treasury_transfer, rebalance_portfolio). Auto-lock mints a receipt; HITL_REQUIRED waits for approver; hard fails return a structured deny that is already on the audit ledger.
Synthetic treasury wire (scope treasury:wire). Default policy always requires a human-issued receipt. No live bank rail. Missing receipt is a logged deny, not a bare MCP error string.
Error handling and recovery guidance not documented in tool descriptions. Tools reference 'structured policy_deny' and 'logged deny' but do not explain what the LLM should do when it receives a BLOCKED result, a missing receipt error, or a replay detection. No guidance like 'If denied, try approve_spend() with a human approver'.
receipt parameter descriptions are sparse. Tools accept a 'receipt' object but do not explain what fields it must contain, how to obtain one (via issue_approval_receipt vs request_authorization), or what happens if it is missing. The relationship between approve_spend, request_authorization, and issue_approval_receipt is not clearly documented at the parameter level.
Missing parameter descriptions for some fields. 'filter' in inspect_audit_ledger is described only as 'Optional filter criteria (event, tool, reason_code)', does not explain what values are valid, how to format them, or what happens if a filter is invalid. '_meta' parameter in evaluate_tool_approval is under-described.