Loading ToolBench
Telegram bot with audio processing capabilities and LangGraph agent integration for task automation across multiple services (Todoist, Google Calendar, Gmail, Notion)
The Jarvis MCP server manages 22 tools across Todoist and Google Calendar integrations. All 22 tools have descriptions and input schemas visible in the source. However, there are critical deficiencies in parameter descriptions, output schema documentation, and error handling guidance. Many parameter descriptions are minimal or omitted entirely. No output schemas are documented in the source code excerpts provided. The tool naming follows verb_noun convention consistently, which is a strong baseline. However, approximately 40% of parameters lack descriptions or type hints beyond what the schema declares. Error handling is present but does not provide recovery guidance or error categorization (retryable, user-fixable, fatal). The server does not implement tool annotations (readOnlyHint, destructiveHint, idempotentHint), even though tools are clearly marked with risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in metadata. This indicates a missed opportunity to communicate intent to the LLM via formal annotations.
Add a comment to a Todoist task
Add a new task to Todoist
Mark a Todoist task as complete
Create a new event in Google Calendar with RFC 3339 datetimes and timezone offset
Create a new project in Todoist
Add a section to a Todoist project
Delete an event from Google Calendar
Output schemas not documented. No tool returns documented in source code excerpts. LLMs cannot predict what fields are available in responses, forcing them to reason blindly about downstream chaining.
Tool annotations missing. Tools are internally marked with risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but these are not exposed via readOnlyHint, destructiveHint, or idempotentHint annotations in the MCP response. LLMs cannot distinguish safe reads from irreversible writes without explicit annotations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 21 | 2024-11-05+ | v1 |
Delete a task from Todoist
Fetch a specific event from Google Calendar by event ID
Get comments for a Todoist task
Retrieve completed Todoist tasks filtered by completion date
Check free/busy time slots on Google Calendar to detect conflicts before creating events
List all labels in Todoist
List Todoist projects, optionally filtered by name substring
List all tasks from Todoist
Query tasks from Todoist using filter syntax (e.g. 'search: dentist', 'p1', 'overdue', 'due after: Jul 5 2026 & due before: Jul 13 2026')
Fetch a specific task by ID from Todoist
List events from a Google Calendar within a time range
List all Google Calendars accessible to the user
Mark a Todoist task as incomplete
Update an existing Google Calendar event
Update an existing Todoist task
Parameter descriptions are inconsistent and often minimal. Many parameters lack actionable guidance on format, constraints, or expected values. Examples: 'priority' in add_todoist_task lacks numeric range clarification in description; 'filter' in get_tasks_by_filter lacks syntax examples; 'search' in get_projects is underdocumented.
No error handling guidance. Error responses do not indicate whether errors are retryable, user-fixable, or fatal. No recovery suggestions provided (e.g., 'Task not found. Try get_tasks() first to list available tasks.').
Confirmation/dry-run missing for destructive operations. delete_todoist_task and delete_calendar_event are irreversible but have no confirmation step, dry-run, or undo mechanism. Agents may delete resources unintentionally.
Parameter interdependencies underdocumented. create_calendar_event accepts both datetime and date parameters (start_datetime/start_date and end_datetime/end_date) but descriptions do not clarify mutual exclusivity or precedence rules. LLMs may pass both, causing ambiguous calls.
No pagination control documented. get_tasks_by_filter, list_calendar_events, and get_projects may return large result sets, but descriptions do not mention limits, pagination tokens, or result count capping. Risk of context window exhaustion.
Tool chaining assumptions undocumented. Many tools require IDs from prior reads (e.g., add_comment needs task_id from get_todoist_task), but these chaining dependencies are not explicit in descriptions or noted as recovery hints.