Loading ToolBench
Model Context Protocol server for Emeritus API integration. Provides tools for user management, tag operations, order management, and leads import functionality through the MCP protocol.
The server provides 17 tools with visible schemas and descriptions, but quality is inconsistent. All tools have input schemas with typed properties and descriptions, meeting baseline schema requirements. However, descriptions are often minimal (1 sentence, 40-80 chars), and the tool set exhibits weak composition, many operations on the same resources (user, tag, order) are not well-differentiated. Parameter descriptions are present but terse. No output schemas are documented, error handling lacks recovery guidance, and no tool annotations (readOnlyHint/destructiveHint) are present despite having clear READ_ONLY vs WRITE semantics. The 17-tool set suggests domain completeness for a CRM-like system, but execution quality is below production baseline (median baseline is 194 chars for tool descriptions; these average ~60 chars).
Activate a tag group
Assign a tag to a user
Create a new tag group
Create a new user by mobile number or email
Deactivate a tag group
Fetch details for a specific order
Fetch user contact information
No output schemas documented. Tools return structured data, but LLMs cannot know what fields to expect in responses. This forces agents to guess field names for downstream tool chaining and wastes tokens on exploratory calls.
Descriptions are consistently too short (35 - 50 chars, median ~40). Baseline for A+ tools is 194 chars. Current descriptions lack context for WHEN to use each tool and any prerequisites. E.g., 'Update an existing tag group' doesn't explain whether this updates active/inactive state, membership, or metadata.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Fetch user profile information
Import leads from raw data
List order financial records with optional filtering
List orders with optional filtering
List all tag groups
List tags assigned to a user
Update an existing tag group
Update a user's email address
Update the owner of a user
Update the pool assignment of a user
No tool annotations present. Six WRITE tools (create_user, update_user_owner, update_user_pool, update_user_email, create_tag_group, update_tag_group, deactivate_tag_group, activate_tag_group, assign_user_tag, import_leads) and 10 READ_ONLY tools lack destructiveHint and readOnlyHint. LLMs cannot distinguish safe from unsafe operations without these signals.
Weak error handling. No error responses visible in code that tell LLMs what to do next (recovery guidance). No categorization of errors as retryable, user-fixable, or fatal. Agents will hit failures with no guidance on next steps.
import_leads tool has 30 optional parameters, several non-standard (form1_name, form1_value, form2_name, etc.). This explosive cardinality suggests incomplete API abstraction. LLMs will struggle to decide which combination of forms and fields to pass. Consider decomposing into a smaller, focused tool or adding enums for form field types.
list_orders and list_order_financial accept start_date and end_date as free-form strings with no format specified. No guidance on ISO 8601, Unix timestamps, or natural language. LLMs frequently pass malformed dates, causing silent API errors.
No pagination documentation in list_* tools. list_tag_groups accepts limit and offset, but no mention of total count or whether a next_cursor is returned. list_orders has page/page_size but no max imposed. Large result sets will blow context windows without stated limits.
create_user uses anyOf constraint (require mobile OR email), but no description explains this mutual exclusivity. LLMs may pass both, neither, or the wrong combination, causing validation errors.