Loading ToolBench
Save, Edit, Create, Delete Notes, Access and interact with Gmail, Calendar, Tasks, and Git repositories. You can get messages, search emails, send new messages, manage calendar events, organize tasks, and perform advanced Git operations including commit management, branching, merging, rebasing, stashing, tagging, blame tracking, and repository configuration.
MIST provides 38 tools across calendar, git, email, notes, and tasks domains. Tool naming generally follows verb_noun conventions (create_event, delete_task, search_emails). However, the server has significant definition quality gaps: most tool descriptions are present but terse (10-30 chars), parameter descriptions are minimal or missing context, output schemas are completely undocumented, and error handling guidance is absent. The schema for tools like create_event_tool is well-formed (proper types, required/optional fields), but many parameters lack actionable constraints (e.g., date formats are mentioned in descriptions but not enforced in schema). Tools like search_emails accept 9 parameters but several (from_email, to_email, subject, label) lack enum constraints for valid values. No tool declares error recovery strategies or permission boundaries. Composition is reasonable, tools are single-responsibility, but output documentation is missing entirely, making it difficult for LLMs to plan multi-step workflows. This is a competent toolkit for a specific user but falls short of production-grade agent integration.
Create a new note with a title and content.
Add file contents to the staging area.
List all branches.
Switch branches.
Record changes to the repository.
Mark a task as completed.
Compose a new email draft.
Output schemas completely undocumented. No tool in the codebase declares what fields will be returned or their types. LLMs cannot plan multi-step workflows without knowing what data is available for chaining. Example: create_event_tool returns an event object but the agent has no visibility into the structure (whether it includes attendee_count, calendar_id, html_link, etc.).
Generic tool name 'add_tool' for git add operation. The name is too generic and does not clearly convey that it stages files for commit. Should be 'stage_files_tool' or 'git_add_tool'. This violates naming clarity for agents with many tools.
Generic tool name 'show_tool' for git show. The name lacks context and could refer to any 'show' operation. Should be 'show_commit_tool' or 'git_show_tool' to disambiguate from other show-* patterns.
Generic tool name 'status_tool'. Should be 'git_status_tool' or 'show_repository_status_tool' for clarity, especially as the codebase grows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Create a new branch.
Create a new event in a specified calendar.
Create a new task list.
Create a new task in a specified task list.
Delete a calendar event.
Delete a task list.
Delete a task.
Show changes staged for commit.
Show differences between branches or commits.
Show unstaged changes in the working directory.
Generate a summary of a note by extracting key points.
Initialize a new Git repository.
Get all available Gmail labels for the user.
List all calendars available to the user.
List notes, optionally filtered by subject or tag.
List all task lists available to the user.
Show commit logs.
Mark a message as read by removing the UNREAD label.
Search for emails using a raw Gmail query string.
Read a note by its ID or title.
List all remotes.
Reset the current HEAD to a specified state or unstage files.
Search for emails using specific search criteria.
Search for events in a calendar.
Search notes for a specific query string.
Compose and send an email.
Show the contents of a commit.
List all stashes.
Show the working tree status.
Update an existing calendar event.
Update an existing task.
No parameter constraints (enums, patterns, ranges) for most tools. Example: search_emails accepts free-form strings for from_email, to_email, subject without validation. No regex patterns or format validation visible. This invites hallucinated invalid values from LLMs.
No error recovery guidance. Tools return success/failure but do not guide the agent on what to do next. Example: if delete_event_tool fails because the event is locked, does the agent retry, escalate, or try a different approach? No error messages are documented.
No permission declarations (read:calendar, write:email, etc.). Agents have no visibility into what scopes each tool requires, making it impossible to configure least-privilege tool access.
Destructive operations (delete_event_tool, delete_task_tool, delete_task_list_tool) lack confirmation or dry-run support. Agents can irreversibly delete without validation, risking data loss.
Tool descriptions vary widely in length and specificity. Some (e.g., 'Show the working tree status') are 27 chars and minimal; others (e.g., create_event_tool) are ~150 chars and more helpful. Consistency is poor. Many descriptions lack WHEN to use the tool (e.g., 'Use when you need to check uncommitted changes').
No pagination documented. Tools like list_calendars_tool, list_notes, list_task_lists_tool return lists but do not expose limit, offset, or next_cursor. If users have many calendars/notes/tasks, agents will receive incomplete data.
Parameter descriptions sometimes vague or redundant. Example: reset_tool commit_ish parameter description is 280 chars but still ambiguous about edge cases (what if commit_ish is empty AND mode is empty?). Needs clearer examples and enum constraints.