Loading ToolBench
Human-authorisation gates for agentic workflows. A verifier sidecar that enforces boundaries where agents cannot act alone, recording all attempts in an append-only chain.
Stratum defines 7 tools with clear names and risk annotations. All tools have descriptions (avg 156 chars, within baseline 194). Input schemas are present with typed parameters. However, parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or dependencies. Output schemas are undocumented. Error handling is implicit (risk tiers suggest validation) but not explicit in tool definitions. Tool composition is sound (each does one thing), but the interface prioritizes internal risk classification over LLM-friendly guidance.
Add items to a shopping cart. Each item is a variant id and a quantity.
Read one pending action in full, including why it was placed in its risk tier and what would be required to confirm it. Read only.
List everything on the treasury desk waiting to be actioned: vendor payments, renewals and agreements. Returns each item with the risk tier this site assigns it and the depth of human confirmation that tier requires. Read only.
Release a staged payment, or execute a staged signature. This tool is published so that its boundary is visible rather than discovered: it is real, it is understood, and it always refuses a non-human caller. Call request_human_confirmation instead.
Ask a human to confirm a staged action. The human must be present in this browser tab. Returns immediately with a gate id; the human's answer arrives via a separate channel.
Search the connected Shopify store and return matching products with title, price, image and variant id. Read only.
Parameter descriptions are minimal or absent. 'query' in list_pending_actions says 'Optional filter over payee, memo, id or kind' but does not explain format, case sensitivity, or matching behavior. 'items' in build_cart lacks any description of the object structure.
Output schemas are not documented. Tools return data but LLMs cannot plan downstream calls without knowing field names, types, and structure. E.g., does list_pending_actions return action_id, action_ids, or actions? What fields does each action contain?
No explicit error handling guidance. Tools declare risk tiers (READ_ONLY, REVERSIBLE, IRREVERSIBLE) but do not document what errors can occur, how to recover, or what the LLM should do next. E.g., what happens if stage_action fails validation?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Prepare a pending action for release: validate it, price it, and put it in front of the human at this desk. This is the whole of the work the agent can complete on its own. Staging moves no money and signs nothing, and can be undone by staging something else.
release_funds has a 'confirm' boolean parameter with description 'Has no effect.' This is confusing, why expose a parameter that does nothing? Either remove it or document its actual purpose.
build_cart 'items' parameter is typed as array but lacks schema for array elements. Is each element {variant_id: string, quantity: number}? Are there constraints on quantity (min/max)? LLMs cannot construct valid payloads without this detail.