Loading ToolBench
An MCP server that integrates with Wordware API to create Notion pages and execute dynamic tools configured via Wordware released apps. Supports both synchronous and asynchronous execution with ReAct-style agent orchestration for multi-step reasoning.
Critical gaps across all dimensions. Tool names lack action verbs (handle_user_request, test). Descriptions are verbose and confusing rather than LLM-optimized. The handle_user_request tool description is 600+ chars of meta-explanation about ReAct agents instead of stating what the tool does. Parameter schemas exist but lack proper type definitions and constraints. No output schemas documented. Error handling is absent. The server conflates tool orchestration with tool definition, handle_user_request tries to be a meta-dispatcher rather than a concrete action.
Create a Notion page synchronously.
Create a Notion page asynchronously and return a job ID.
Check the status of a previously started Notion page creation job.
Entry point for user requests. For multi-step reasoning (e.g., use the output of one tool as input to another), Claude should call this tool first and describe the desired outcome clearly in the `user_command`. If a task requires multiple steps, this tool will internally invoke a ReAct-style agent to orchestrate the steps. This is a tool that is used to handle user requests. Here are a list of tools available: - notion_page (use to create a new page in Notion) - google_search (use to search the web to get up to date information or current information) - wikipedia_lookup (use to get information from wikipedia, if you need to know more about a topic or need to research something) - google_news (use to get the latest news) When the tool is called, Claude tells it which tool it wants to use. The process is as follows: 1. Use the provided tool (e.g., "notion_page") to handle the request. 2. Call the chosen tool to get an initial result. 3. If the query indicates multi-step processing is needed (e.g., contains "multi-step"), delegate to the ReAct agent for further processing.
handle_user_request violates single-responsibility principle. It is a meta-dispatcher that tries to route to other tools (notion_page, google_search, wikipedia_lookup, google_news) rather than performing a concrete action. Tool names must start with action verbs (get_, create_, search_, etc.) and do exactly one thing. This tool does neither.
Descriptions are verbose meta-explanations (600+ chars) rather than LLM-optimized action statements. handle_user_request spends 400+ chars explaining ReAct agents and internal orchestration instead of stating: 'Execute a user command by delegating to the appropriate tool (notion_page, google_search, wikipedia_lookup, or google_news).' Baseline: 194 chars avg, 10-1024 range. Current descriptions waste tokens and bury intent.
test tool has no description (5 chars: 'Test tool to verify MCP functionality.') and empty input schema {}. This tool is non-functional for agent use.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | <=2025-11-25 | v2 |
Test tool to verify MCP functionality.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns. create_notion_page and create_notion_page_async should document: {page_id: string, url: string, created_at: ISO8601}. get_job_status should document: {status: 'pending'|'processing'|'complete'|'error', result?: string, error?: string}.
Parameter descriptions are minimal or missing. 'title' and 'body' in create_notion_page lack format guidance (max length? markdown support? required fields?). 'job_id' in get_job_status lacks explanation of where it comes from.