Loading ToolBench
A web-based MCP server implementation with frontend tools for theme control, navigation, form interaction, scroll management, analytics, and local storage preferences
This server exhibits significant quality gaps across naming, descriptions, and schema documentation. While 19 tools are registered with basic schemas, many lack proper input validation, comprehensive descriptions, and error handling guidance. The server mixes legacy website tools (theme, navigation, form-filling) with generic utility functions (preferences, analytics) and a disconnected TODO subsystem. Tool definitions are visible in source code (useWebMCPTools.tsx hooks and oldWebsiteForReference handlers), but descriptions are often generic, parameters frequently lack context, and output schemas are not documented. The naming convention is generally sound (verb_noun pattern), but several tools lack clarity around when to use them vs. alternatives. No evidence of error recovery guidance, permission gates, or audit logging. Average tool score: 42/100.
Creates a new todo item
Permanently deletes all todo items
Permanently deletes a todo item by its ID
Fill out the contact form with provided information
Retrieves a list of all todos
Get information about the current page
Get information about available form fields on the current page
No documented output schemas for any tool. Users and LLMs cannot predict what data structure is returned, forcing them to guess or require example invocations. This violates pattern:response-shaper and forces downstream tools to reason about response structure without evidence.
Destructive tools (deleteTodo, deleteAllTodos) lack confirmation or dry-run support. Agents can irreversibly delete data without explicit user approval. No evidence of confirmation_request pattern implementation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Retrieve a user preference from local storage
Get information about the current scroll position and page dimensions
Get the current theme setting
List all stored WebMCP preferences
Navigate to a different page on the website
Pings the server
Scroll to the bottom of the page
Scroll to the top of the page
Save a user preference to local storage
Change the website theme (dark or light mode)
Track a custom analytics event
Updates an existing todo item's text or completion status
Descriptions are generic and under-specified. Examples: 'Pings the server' (30 chars), 'Scroll to the top of the page' (29 chars), 'Scroll to the bottom of the page' (34 chars), 'Retrieves a list of all todos' (29 chars). Most fall below the 50-char baseline for LLM clarity. The rubric baseline is 194 chars for production tools.
No pagination or result limits for list-like tools (list_preferences, getTodos). If users accumulate hundreds of todos or preferences, returning all items will exhaust context. No evidence of page/offset/limit parameters or result capping logic.
No error handling guidance. If track_event fails, fill_contact_form times out, or navigate_to hits a 404, there is no documented recovery path (retry, ask user, escalate). LLMs receive raw errors with no actionable next step.
Inconsistent parameter naming and typing across tool subsystems. Theme tools use 'theme' enum; preference tools use generic 'key'/'value' strings with no validation. Todo tools use UUID format correctly (format:'uuid') but preference and navigation tools do not enforce identifier formats or constraints.
get_form_fields and get_scroll_info return structure is undocumented. What fields do they include? How are they structured? Without output schema documentation, LLMs cannot plan downstream calls that depend on this data.
Ping tool is marked as READ_ONLY and present, but ping is a deprecated/removed feature in the current MCP spec (2026-07-28). While it does not break functionality, its continued inclusion and lack of clear purpose suggests the server is tracking older patterns.