Loading ToolBench
MCP server for managing user interactions and state within the Blip platform
Three tools with acceptable descriptions but significant schema and naming gaps. All tools share a single overly permissive schema (contactIdentity, optional action, optional payload:any) that violates constrained-input patterns. Tool names lack clear verb_noun structure. Descriptions are present (115-165 chars) but lack actionable guidance on when to use each tool, what fields to expect in responses, or error recovery. The 'payload:any' parameter is a major schema smell, LLMs cannot reason about valid input shapes. No output schemas documented anywhere. Error handling exists but does not guide recovery (BadRequestException with generic error.message). Overall Definition Quality sits at median C-range (52) due to weak parameter specificity and missing output documentation.
Create or update user contact information and metadata. Allows you to store user data, preferences, and custom attributes associated with the contact identity. Supports structured payloads for complex data storage.
Retrieve the current state and flow position of a user in the conversation. Returns information about where the user is in the conversation journey, their current context, and any relevant metadata. Useful for understanding user progress and making informed decisions.
Reset the conversation context and conversation history for a user. Use this when the user wants to start a new conversation flow or clear previous context. Requires the user identity.
All three tools share identical overly permissive schema with 'payload:any'. LLMs cannot validate inputs or infer valid payload shapes. Violates constrained-input pattern, enums, typed objects, and specific fields required for agent reasoning.
No output schemas documented for any tool. LLMs cannot plan downstream calls, extract chaining IDs, or understand response structure. Descriptions mention what tools return (e.g. 'Returns information about...') but provide zero field-level documentation.
Tool naming lacks clear action verbs. 'reset-context' is verb-noun; 'get-state' is clear. But 'add-or-update' contains 'and' (pattern anti-pattern) and conflates two operations. Should be 'create-user' and 'update-user' or 'update-contact' separately.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter descriptions are minimal. 'Optional action parameter' and 'Optional payload parameter' are not actionable. LLMs cannot infer what 'action' values are valid, what 'payload' structure is expected, or why to include them. Violates tool-description pattern.
Error responses throw BadRequestException with only error.message (no context, no recovery guidance). Violates recovery-guide pattern. Agent receives a generic string and cannot determine: is this retryable? Is it a user input error? Should I use a different tool?
No confirmation or dry-run for destructive operation 'reset-context'. Agents make mistakes; this tool can wipe user conversation history irreversibly. Should support a 'dry_run' parameter or a separate 'preview_reset_context' tool. Violates confirmation-request pattern.
Descriptions do not distinguish between tools. All three mention 'user/contact' and return 'information'. LLMs cannot reason about when to call 'get-state' vs 'reset-context' vs 'add-or-update'. Descriptions should clarify preconditions, side effects, and use cases explicitly.