Loading ToolBench
AI Agent Hub for Notion — orchestrate AI agents through Notion databases with human-in-the-loop approval. Built with MCP.
The server defines 5 tools with explicit Zod schemas and descriptions. However, quality is inconsistent. All tools have descriptions and type definitions, but descriptions are often too generic or lack actionable context. Parameter descriptions are sparse or vague in many cases. Output schemas are undocumented, LLMs must infer what fields the tools return. Error handling returns only error messages without recovery guidance. Notable: notion-write has complex nested block structures but lacks clear documentation of the block object fields and nesting rules. code-run exposes a dangerous capability (arbitrary JavaScript execution) with minimal safety guidance. web-search lacks specificity about fallback behavior and result structure. The tools are well-named (verb_noun pattern), but descriptions do not follow the 10-1024 character recommendation, most are 100-180 chars, which is acceptable, but lack specificity on when to use vs alternatives.
Execute JavaScript code in a sandboxed environment. Has access to Math, Date, JSON, and standard built-ins. No filesystem or network access.
Query a Notion database with filters and sorting. Returns matching pages with summarized properties.
Read pages, databases, or blocks from Notion. Returns structured content including properties and child blocks.
Create or update Notion pages. Supports creating pages with rich content blocks (headings, paragraphs, lists, toggles, code, callouts).
Search the web for information. Uses Brave Search API if available, falls back to DuckDuckGo. Useful for research tasks.
code-run tool lacks safety and security documentation. No mention of sandboxing validation, timeout enforcement, or what 'sandboxed' actually means. Arbitrary JavaScript execution is dangerous; the description must warn about limits and provide recovery guidance if code hangs or crashes.
Output schemas are completely undocumented. Each tool returns JSON via text serialization, but LLMs cannot plan multi-step workflows without knowing what fields to expect. For example, notion-read may return blocks, properties, children, but the shape is unknown. Add explicit output schema documentation for each tool.
notion-write block structure is complex with nested 'children' arrays and conditional fields (text, language, etc.) but the schema documentation is incomplete. The description does not explain which block types support children, how language applies to code blocks, or what happens if conflicting properties are provided.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
web-search description mentions 'falls back to DuckDuckGo' but does not specify what triggers the fallback, how results differ between providers, or what the result structure looks like. LLMs cannot reliably use this tool without understanding expected output fields.
notion-read has three mutually exclusive parameters (page_id, database_id, block_id) but the description does not state this clearly. LLMs may pass multiple or none, causing unclear behavior. Add explicit mutual exclusion guidance: 'Provide exactly one of: page_id (read page content), database_id (read schema), or block_id (read children).'
Error responses in all tools return only a text message via isError: true. No error classification (retryable vs fatal), no recovery guidance, no invalid value echoing. Per the rubric, errors must tell the agent what to do next: 'Notion API returned 404. Try notion-read first to verify the page exists.' Current implementation: 'Error: ...', unhelpful.
notion-query accepts a 'filter' parameter of type 'any' with only a link to Notion docs. LLMs cannot construct valid filter objects without seeing examples or a schema. This breaks the constrained-input pattern, replace with a formal schema or provide examples of common filters (by status, by checkbox, by date range).
notion-write 'action' parameter enum is clear (create, update, append), but parameter dependency rules are not documented. E.g., 'create' requires parent_id; 'update' and 'append' require page_id. Without this, LLMs guess and fail. Add: 'For create: parent_id is required. For update/append: page_id is required.'
code-run timeout_ms defaults to 5000ms but the description does not explain what happens if code runs longer (does it hard-kill the process? Return a partial result?). Also, no guidance on available built-ins beyond 'Math, Date, JSON', what about async, Promises, fetch? LLMs will assume capabilities that don't exist.
notion-query's start_cursor parameter for pagination is documented, but the response does not document whether a next_cursor is returned or how to know if results are exhausted. LLMs cannot implement pagination without this.