Loading ToolBench
Wraps MCP servers as Amorce agents, exposing MCP tools via AATP protocol with HITL support
The Amorce MCP Agent Wrapper exposes 6 tools with significant quality gaps. While tool names follow verb_noun conventions (list_tools, call_tool, create_approval, get_approval, submit_approval, health), descriptions are generic and lack LLM-optimization. Input schemas are present for 3 tools (call_tool, create_approval, get_approval, submit_approval) but incomplete or missing for others. Most critically, parameter descriptions lack actionable constraints (e.g., what values approval_id should take, timeout_seconds bounds, enum values for decision field). Error handling is mentioned in descriptions but not evident in code samples. The tools lack composition clarity, approval workflow spans 3 separate tools (create → get → submit) when agents would benefit from a higher-level abstraction. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. Output schemas are not documented in the provided code.
Execute MCP tool via AATP. Takes tool_name, arguments, and optional approval_id. Supports HITL approval verification.
Agent requests human approval for a transaction. Generates approval_id and returns expiry timestamp.
Get approval status. Agents poll this to check if human has approved/rejected the transaction.
Enhanced health check endpoint with detailed MCP server status.
List available MCP tools as Amorce services. Performs AATP signature verification.
Submit approval decision (approve or reject). Called by agent after getting human response.
No output schemas documented for any tool. Agents cannot plan downstream calls or extract required fields without understanding response structure.
Parameter descriptions lack actionable constraints: timeout_seconds has no min/max; alternatives array has no per-item schema; approved_by accepts ambiguous identifier types (email vs username vs ID); decision enum is present but approval state machine (pending/approved/rejected/expired) not documented for get_approval response.
Approval workflow requires 3 sequential tool calls (create_approval → get_approval → submit_approval) with polling. Agents would benefit from a higher-level 'request_and_wait_approval' or 'wait_for_approval(approval_id, timeout_seconds)' tool that abstracts the polling loop and reduces multi-step brittleness.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Error handling is not evident in tool definitions. No recovery guides in descriptions (e.g., 'If approval expires, call create_approval again'). No actionable error responses visible (e.g., invalid tool_name, approval_id not found, timeout expired). Agents cannot self-correct without explicit error guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Agents cannot distinguish which calls are safe to retry, which modify state, which are read-only. call_tool risk is marked WRITE but should declare idempotency (is calling with same args twice safe?) and whether approval_id enables replay protection.
Descriptions are generic and lack LLM-optimization. Baseline for A+ tools is 50 - 200 chars with WHAT, WHEN, and dependency hints. Current descriptions (35 - 110 chars) state WHAT but rarely include WHEN to call or prerequisites. Example: create_approval should clarify 'Use this when a transaction requires human approval before execution' and 'Call submit_approval only after human has responded'.
Parameter 'approved_by' in submit_approval accepts ambiguous identifier (string, no format constraint). Should clarify: email, username, system user ID, or display name? Current design forces agent guessing.
health endpoint has minimal description (62 chars, below 'good' baseline of 100+). Does not explain when to call it vs a liveness probe, or how to interpret mcp_server.connected/status fields. Response structure visible in code but not formally declared as output schema.