Loading ToolBench
An AI-powered terminal assistant with tool execution capabilities
Clarissa has fundamental definition quality issues across most tools. While 8 tools are defined with names and basic descriptions, the schemas are incomplete, descriptions lack actionable detail, and parameter documentation is minimal. Most tools fall below the 50th percentile for production-grade agent tools. The server provides descriptions that are often vague or cut off (e.g., reminders tool description is only 'Create, read, and manage reminders' with no WHEN/HOW guidance). Parameters lack type constraints and relationship documentation. No error handling guidance is present. The weather tool mentions triggers but tool selection should rely on descriptions, not trigger phrases. Overall, the definitions would not pass code review by a principal tool engineer.
Evaluate mathematical expressions. Supports basic arithmetic (+, -, *, /), exponents (^), parentheses, and common math functions (sqrt, sin, cos, tan, log, abs, floor, ceil, round, pow) and constants (PI, E).
Create, read, and manage calendar events. Can create new events, list upcoming events, and search for events.
Search contacts by name or query
Get the device's current location
Save a fact or preference to Clarissa's long-term memory
Create, read, and manage reminders
Reminders, contacts, remember, and location tools have descriptions under 30 characters; several under 20 chars. Current descriptions are too terse to guide LLM tool selection.
Calendar and reminders tools declare action enums (e.g., 'create', 'list', 'search') but lack documentation of which parameters are required for each action. For example, calendar's 'create' action requires title and startDate/endDate, but this dependency is not stated. This forces LLMs to guess, causing invalid calls.
No output schemas are documented for any tool. LLMs cannot plan downstream tool calls (e.g., what fields does calendar.list return? How do I get event IDs for follow-up actions?) without knowing the response structure. This forces trial-and-error reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get current weather and forecast. TRIGGERS: 'weather', 'temperature', 'hot', 'cold', 'rain', 'sunny', 'forecast'. No params = current location. Returns: conditions, temp, humidity.
Fetch and summarize content from a URL
Weather tool description mentions TRIGGERS ('weather', 'temperature', etc.), but MCP tools should not rely on trigger phrases. Tool selection is driven by descriptions and LLM reasoning, not pattern matching. Remove trigger language and focus on describing WHAT the tool does and WHEN to use it.
Web_fetch has no description of output format (is it HTML, plaintext, markdown?), length limits, or error handling (404, timeout, invalid URL). Calendar does not document pagination behavior (does list return all events or page 1?). These omissions force LLMs to discover behavior through trial-and-error.
Remember tool accepts 'content' string but does not document: How much data can be stored? How is memory retrieved? Is this persistent across sessions? What format is best? Without these answers, LLMs cannot reliably use the tool.
Calendar, reminders, contacts, and web_fetch tools have no error handling guidance. If a calendar event creation fails (conflict, invalid date), what should the LLM do? Retry? Ask the user? The tool should return recovery guidance, not just an error code.
Calendar and reminders tools use generic action enums without documenting required vs. optional parameters per action. For create: title required, location optional? For list: daysAhead default 7, but what if user wants month-long view? These constraints must be explicit in parameter descriptions.
Weather tool latitude/longitude parameters lack validation ranges (±90 for lat, ±180 for lon). Calculator expression parameter lacks validation rules (are { } allowed? limit on expression length?). These omissions invite invalid input from LLMs.