Loading ToolBench
MCP server that integrates meeting summaries with Notion, enabling creation of Notion pages or database rows from meeting summary payloads
Single tool 'handle_meeting_summary' has a detailed input schema with proper types and nested object structures, but critical gaps undermine quality. Tool name uses 'handle_' (generic verb, not action-specific like 'create_' or 'store_'). Description is adequate (145 chars) but lacks guidance on when/why to use it or what happens post-creation. Output schema is completely undocumented, LLMs cannot plan downstream actions. No error handling guidance, no recovery paths, no validation rules in descriptions. Parameters lack actionable constraints (e.g., confidence range 0-1 is stated but not validated; priority enum is present but other fields lack similar rigor). The schema is visible and well-structured, but the tool fails on naming clarity, output documentation, and error guidance, three critical patterns.
Accepts a meeting summary payload (MeetingSummaryV1) and creates a Notion page or database row with the meeting details, including short summary, detailed summary, action items, highlights, and resource links
Tool name 'handle_meeting_summary' uses generic verb 'handle' instead of action-specific verb like 'create_notion_page' or 'store_meeting_summary'. LLMs cannot infer intent from the name alone.
Output schema is completely undocumented. Tool description does not specify what the API returns (e.g., page_id, database_row_id, success status, error details). LLMs cannot chain this tool to downstream operations.
No error handling guidance. Description does not explain what happens on failure (invalid token, parent not found, Notion API error). No recovery hints like 'If Notion connection fails, check NOTION_TOKEN env var' or 'If parent_id is invalid, call list_databases() first'.
Parameter descriptions lack actionable constraints. E.g., 'confidence' is typed as number with range 0-1 but description does not state this range or what happens if out of bounds. 'priority' enum is well-defined but other fields (e.g., 'timezone', 'role') lack format/constraint guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | <=2025-11-25 | v2 |
Tool description does not explain prerequisites or dependencies. E.g., does the tool require a Notion workspace token? Must the parent_id be a valid page or database? Must meeting.id be unique? These are implicit and force LLMs to guess.