Loading ToolBench
Fetches a web article and writes its full content into an existing Notion page.
Two tools with well-structured schemas and detailed descriptions. clip_article and clip_status both have complete JSON Schema definitions with required fields and type declarations. Descriptions are comprehensive (200+ chars) and explain prerequisites, behavior, and error recovery. However, parameter descriptions lack explicit format/constraint details (e.g., 'Notion page id, with or without dashes' is informal). No enum constraints on the 'force' boolean. Error handling guidance is embedded in descriptions rather than formalized in error response schemas. Tool names follow verb_noun pattern (clip_*) appropriately. No tool annotations (readOnlyHint/destructiveHint) despite clip_article being a WRITE operation.
Fetches a web article and writes its full content into an existing Notion page in the WDB | Resources database, storing images inside Notion. The page must already exist — create it and set its properties first. This tool only fills in the body. This tool waits briefly for the work to finish, so it often returns the real outcome (CLIPPED or FAILED) directly. If it returns IN_PROGRESS or STARTED, call clip_status yourself to keep waiting. Never report success on anything other than a CLIPPED result, and never ask the user to prompt you to check. CRITICAL: if this tool fails at the transport level — a timeout, or the server not responding — that does NOT mean the clip did not happen. The work is dispatched before the reply is sent, so it may well be running. NEVER call clip_article again after such an error. Call clip_status instead and let it tell you what is actually on the page. Retrying blindly is how a page ends up with the article on it twice.
Reads a Notion page and reports whether a clip has finished, is still running, or failed. This tool WAITS for a running clip before answering, so calling it again is how you wait — never ask the user to prompt you to check. Keep calling it until it returns CLIPPED or FAILED, and report nothing to the user until then.
Missing tool annotations for destructive operations. clip_article modifies Notion pages (WRITE risk) but lacks destructiveHint annotation to signal to LLMs that this is an irreversible operation.
Parameter constraints not formalized as enums or JSON Schema patterns. 'force' is a boolean with no enum, and 'page_id' accepts 'with or without dashes' but this is documented in prose rather than a regex pattern or format constraint.
Error handling guidance embedded in tool descriptions rather than formalized in error response schemas. LLMs cannot parse recovery instructions from description text reliably; structured error responses with actionable next steps are needed.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Output schemas not documented. Neither tool explicitly declares what fields are returned (e.g., clip_article returns status codes like CLIPPED, FAILED, IN_PROGRESS, STARTED but this is only mentioned in description prose).
No idempotency or confirmation pattern for destructive retry scenario. clip_article warns 'Never call clip_article again after a transport error' but provides no formal mechanism (e.g., dry-run, confirmation_required) to prevent accidental re-execution.