Loading ToolBench
Stage 2 backend service for an AI Customer Success agent that handles inbound support messages from Email, WhatsApp, and Web Form channels. Processes messages through an intelligent agent workflow with database persistence, escalation detection, knowledge base search, and ticket creation.
Critical gaps across all dimensions. Tool schemas are partially visible but lack complete JSON Schema definitions with proper type constraints. Descriptions exist but are generic and lack LLM-optimization guidance. Parameters expose database session objects (anti-pattern), lack enums for constrained inputs (channel, priority, severity, reason), and missing descriptions for several fields. No output schemas documented. Error handling absent. Tools violate single-responsibility principle (create_ticket bundles escalation logic; escalate_issue generates responses). No idempotency guarantees or recovery guidance.
Create a support ticket in the database with customer, channel, subject, message, priority, and status.
Flag a ticket for human agent review and generate an escalation holding response for the customer.
Retrieve customer profile and context information including name, email, account tier, VIP status, and ticket history.
Search the local knowledge base for content relevant to the query.
Format and return a channel-specific response with appropriate tone, length, and structure for the target channel.
Database session objects exposed as parameters. All tools accept 'db' parameter of type 'object', this violates secret-injection and server-side abstraction patterns. Sessions should never be tool parameters; inject via middleware.
Missing enum constraints on constrained inputs. 'channel' accepts free-form strings (should be enum: email|whatsapp|web_form). 'priority' and 'status' in create_ticket lack enums. 'reason' in escalate_issue lists valid values in description but not as schema enum. LLMs will hallucinate invalid values.
No output schemas documented. Tools return unspecified structures. LLMs cannot plan downstream calls or extract required fields. E.g., search_kb returns 'KB entries' but field names, types, and pagination are undocumented.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Composition violation: create_ticket and escalate_issue both handle escalation logic. create_ticket accepts escalation fields (escalated, escalation_reason, escalation_severity); escalate_issue also escalates. Unclear which tool to use when. Split responsibilities.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryability, or next steps. E.g., search_kb may return empty results, should it suggest alternative queries or escalate?