Loading ToolBench
AI-powered workspace assistant for managing calendar events and emails using Nylas API integration with LangChain and LangGraph
This MCP server has significant quality gaps across naming, descriptions, schema completeness, and error handling. Most tools lack comprehensive parameter documentation and output schema definitions. Descriptions vary widely in quality and usefulness for LLM selection. No input validation, error guidance, or security hardening visible. The server is fundamentally underdeveloped for production use despite having a reasonable tool set (7 tools).
Creates and schedules a new calendar event. IMPORTANT FOR AI: This function creates calendar events using exact datetime information. Parameters: title (str) - A descriptive title for the event; start_time (str) - The exact start datetime in ISO 8601 format with IST timezone; end_time (str) - The exact end datetime in ISO 8601 format with IST timezone. AI should NEVER assume or guess dates - ALWAYS use date/time tools first. ALL TIMES ARE IN IST (Indian Standard Time, UTC+05:30). Returns: Event creation response from Nylas API.
Retrieves all events from the connected calendar. IMPORTANT FOR AI: This function fetches existing calendar events to check availability and avoid conflicts. Use this function to check for scheduling conflicts before creating new events, to show user their upcoming events when asked, and to find available time slots for scheduling.
Returns the current time in multiple formats.
Returns the current Unix timestamp and readable format.
Retrieves the n most recent emails from the connected email account. IMPORTANT FOR AI: This function fetches existing emails to provide email management and communication assistance. Use this function to show users their recent emails when asked, help users catch up on recent communications, find specific emails by checking recent messages first, and identify important senders or urgent subjects.
get_profile tool has no documented input schema and minimal description ('Returns user profile information', 35 chars, below 50-char minimum for context). Cannot assess what fields are returned or how to use output.
get_calendar_events accepts no parameters (empty input schema {}) but description implies filtering/date range logic ('check availability and avoid conflicts'). Should accept optional parameters like start_date, end_date, limit to enable flexible querying. Current implementation forces retrieval of ALL events every call.
No output schemas documented for ANY tool. LLMs cannot know what fields to expect from responses, forcing unstructured parsing and increasing hallucination risk. E.g., does create_event return {event_id, created_at, calendar_url} or something else?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Returns user profile information
Returns today's date in multiple formats.
Description of create_event contains example values ('2025-06-21T14:30:00+05:30') embedded in the parameter description. LLMs tend to reuse example values literally rather than adapting to actual context, risking incorrect datetime values passed in real calls.
get_latest_emails accepts parameter 'n' with no constraints documented. Description says 'default: 5, max: 50' but JSON schema lacks minItems, maxItems, or default value declarations. LLMs cannot enforce these bounds, they rely on description text, and unstructured text is unreliable.
No error handling or recovery guidance visible in any tool. If create_event fails (e.g., time conflict, invalid timezone, API error), what should the LLM do? Retry? Ask user? Call a different tool? No guidance provided.
Tool descriptions for discovery/utility functions (get_todays_date, get_current_time, get_current_time_in_unix) are too generic. Why are THREE separate time tools provided? What is the LLM's decision logic for choosing between them? Descriptions should clarify: 'Use get_current_time for human-readable display; use get_current_time_in_unix only if a downstream API requires Unix epoch.'
create_event description includes long advisory text ('IMPORTANT FOR AI: This function creates calendar events...') that reads like a prompt injection guard. This suggests the tool was not originally designed with LLM agents in mind. Text should be concise and constraint-driven rather than instructional.
No mention of pagination support for get_calendar_events or get_latest_emails. If a user has hundreds of emails or calendar events, what happens? Do tools return all items (risking context explosion) or silently truncate? No limit parameter, no pagination cursor, no total count in response.
Tool compositions and chaining IDs not documented. If get_latest_emails returns email objects, do they include sender_id/sender_email so an LLM can compose downstream tools (e.g., reply_to_email)? Required reference IDs must be present in responses to enable agent planning.