Loading ToolBench
MCP server for Notion and Google Workspace automation
The server defines 8 tools with basic schemas and descriptions, but exhibits significant gaps across naming clarity, parameter documentation, output schema specification, and error handling. Most tools return generic string responses without structured schemas, violating the pattern:response-shaper requirement. Parameter descriptions are minimal (typically 10-30 chars) and lack validation constraints. No evidence of error recovery guidance, security considerations, or permission gating. Tool names follow verb_noun convention (positive), but descriptions are terse and often under the 50-character baseline for LLM optimization. The server does not leverage fastmcp's capabilities to improve schema richness or structured output.
Append a row to a Google Sheet.
Create a task/page in a Notion database. Return page ID + confirmation.
Create a Google Calendar event and return event ID. start_time and end_time must be ISO format strings.
Read all tasks from the database (title, status, due_date).
Return unread Gmail messages (sender, subject, snippet).
Fetch upcoming Google Calendar events for a given number of days.
All tools return generic string responses instead of structured objects. The return type annotation is `-> str` with no documented output schema, violating pattern:response-shaper and pattern:tool.
Tool descriptions are too short (35-55 chars) and lack context for LLM selection. None explain WHEN to use the tool, WHAT it returns, or any prerequisites. Example: 'Read all tasks from the database (title, status, due_date).' is a bare description without guidance on when to invoke it.
Parameter descriptions are minimal or absent of validation constraints. 'days' parameter has no bounds (1 - 365?). 'row_data' is an array with no documentation of element types or length limits. 'sheet_id' has no guidance on format (UUID? string ID?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Return data from a specific sheet range.
Send an email via Gmail API. Return success/failure JSON.
Error handling is generic. All tools wrap exceptions in a try-except block that returns `{'error': str(e)}`. This does not categorize errors as retryable/user-fixable/fatal, nor does it provide recovery guidance. LLMs receive a generic error message with no actionable next step.
No output schema documentation. Tools return stringified Python objects (str(result)). LLMs cannot plan downstream chaining (e.g., using returned page_id, event_id, email_id in subsequent calls) because the response structure is opaque.
No permission gating or scope declarations. Tools like send_gmail and add_notion_task have no verification that the calling agent/user has authority to execute them. Per pattern:permission-gate, destructive/sensitive operations must check permissions.
List/read tools (get_notion_tasks, get_upcoming_events, get_unread_emails) lack pagination support. No limit, offset, or next_cursor parameters documented. Large result sets could exhaust context windows.
No idempotency guarantees documented. Tools like create_calendar_event and send_gmail do not state whether repeated calls with identical inputs produce duplicate events/emails or are idempotent. Agents retry on ambiguous failures, non-idempotent behavior risks duplicate side effects.