Loading ToolBench
MCP server for accessing Google Calendar events by date
Single tool with critical definition gaps. Tool 'getMyCalendarDataByDate' has a valid schema with Zod validation, but lacks proper description and has only one parameter. The parameter description ('Invalid date format. Please provide a valid date string.') is malformed, it describes an error state, not the parameter's purpose. The tool itself has NO description field registered, violating the requirement that every tool must have a non-empty description. Output schema is undocumented (returns text/JSON but LLM cannot anticipate field structure). Error handling is minimal and non-actionable. Composition is single-tool server with no chaining complexity. Security: credentials (GOOGLE_PUBLIC_API_KEY, CALENDAR_ID) are properly injected via environment variables, not exposed as parameters.
Tool has NO description registered in server.tool() call. The description field is completely missing, making it impossible for LLMs to understand when or why to invoke this tool. This violates pattern:tool-description requirement.
Parameter description is malformed. The date parameter description reads 'Invalid date format. Please provide a valid date string.' This is an error message, not a parameter description. It should explain WHAT the parameter controls (e.g., 'The date for which to retrieve calendar events, in ISO 8601 format (YYYY-MM-DD)').
Output schema is undocumented. The tool returns { meetings: [...] } or { error: ... }, but the LLM has no indication of the response structure. Missing documented return types violate the baseline: '100% of A+ tools have documented return types'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Error responses lack actionable recovery guidance. When calendar.events.list() fails, the tool returns { error: err.message }, which may be cryptic API errors. Errors should include hints like 'Check that CALENDAR_ID is valid' or 'Verify GOOGLE_PUBLIC_API_KEY has calendar read permissions'.
No input validation hints in parameter description. Date parsing is validated by Zod (.refine with custom message), but the description does not specify accepted formats (ISO 8601, YYYY-MM-DD, etc.). LLMs need explicit format guidance in description text, not just schema validation.
Meeting response format unclear. Meetings are returned as strings ('${event.summary} at ${start}'), not structured objects with typed fields. If the LLM needs to extract meeting IDs, times, or attendees for downstream actions, this format is insufficient. Should return objects: [{ summary, start, end, id, ... }].