Loading ToolBench
AI Agent interaction security framework and MCP Tool Gateway core
Agent Interlock provides explicit tool definitions with input/output schemas and annotations. However, there are critical issues: (1) duplicate tool names (lookup_order appears twice with different schemas; send_email appears twice with different signatures), creating ambiguity for LLMs; (2) parameter descriptions are entirely missing, the schema shows types but no descriptions explaining what each parameter controls; (3) output schemas are defined in code but not visible in tool registration; (4) descriptions are adequate (100-150 chars) but lack dependency hints or prerequisites. The refund_agent tools are well-structured with proper schemas and readOnlyHint annotations, but the support_agent tools are incomplete in the provided source. Overall, solid foundation undermined by naming conflicts and missing parameter documentation.
Issue a refund of the given amount against one order.
Look up the status of one customer order by its order id.
Look up the status, refund-eligible amount and customer email of one order by its order id.
Send one notification email to the customer about their refund.
Send one reply email to the customer who owns the order.
Send an approved customer support reply.
Duplicate tool names with conflicting schemas: 'lookup_order' defined twice (refund_agent vs support_agent) with different input schemas (orderId vs order_id); 'send_email' defined twice with different required parameters and constraints. LLMs cannot disambiguate and will select the wrong variant.
Parameter descriptions entirely missing from all tool schemas. JSON Schema shows types (string, number, email format) but no descriptions explaining what each parameter controls, when to use it, or valid ranges. LLMs cannot infer parameter semantics from names alone (e.g., 'to' could be recipient, destination, or target).
Output schemas defined in code (LOOKUP_ORDER_OUTPUT_SCHEMA, etc.) but not visible in tool registration or MCP protocol responses. LLMs cannot plan downstream tool calls or extract required fields without knowing output structure.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
Parameter naming inconsistency: refund_agent uses 'orderId' (camelCase) while support_agent uses 'order_id' (snake_case). This forces LLMs to track two naming conventions for the same concept, increasing error likelihood.
Missing error handling guidance. Tool descriptions do not explain what happens on failure (e.g., 'no such order' is returned as a valid response in lookup_order, but this is not documented). LLMs need explicit recovery paths.