Loading ToolBench
A no-code MCP (Model Context Protocol) server builder and deployment platform with visual tool creation, specification management, and Cloudflare Workers deployment
MCP Space exhibits critical definition quality gaps across all 8 tools. While tool names follow verb_noun patterns (compare_query_json, get_tool_by_id), most tools lack actionable descriptions and critical schema validation details. Descriptions are present but often generic or incomplete. Input schemas are visible but lack proper type definitions for complex parameters (e.g., 'json_data' in compare_query_json is declared as type 'object' with only minimal description). No output schemas are documented. Error handling guidance is absent. The tools appear to be a mix of database queries and parsing utilities, but the interface does not guide LLM selection or explain error recovery paths. No tool declares constraints, enums, or validation rules that would help agents invoke tools correctly.
Compare a query with a JSON object and return a semantic similarity score between 0.0 (no match) and 1.0 (perfect match) using Gemini model for semantic analysis
Create a formatted summary of multiple tool specifications with parameters, environment variables, and descriptions
Detect if a query is asking to create multiple tools and extract tool names/descriptions. Returns a tuple of (is_multiple_tools, number_of_tools, list_of_tool_descriptions)
Retrieves a specification from the spec table by its ID from Supabase database
Searches for a specification in the spec table based on semantic matching with the query, optionally filtered by user_id or server_id
Retrieves a tool from the tools_data table by its ID from Supabase database
No output schemas documented for any tool. LLMs cannot infer what fields to expect from responses, blocking downstream tool chaining and multi-step planning.
Input parameter descriptions are minimal or generic. 'json_data' in compare_query_json is described as 'The JSON object to compare against the query (tool or specification JSON)', too vague to guide LLM input construction. No format, constraints, or nesting structure specified.
Tool descriptions lack context for LLM selection. 'Retrieves a tool from the tools_data table by its ID from Supabase database' explains the technical action but not WHEN to use it vs get_tool_by_query, or what happens on failure (not found, database error, timeout).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Searches for a tool in the tools_data table based on semantic matching with the query, optionally filtered by user_id or server_id
Parse a tool update query in the format 'update the tool: {tool_name} {query}' and returns a tuple of (tool_name, update_query) or (None, None) if not a valid update query
No error handling guidance. Tools make external API calls (Gemini for semantic analysis, Supabase queries) but provide no recovery hints. What should the LLM do if Gemini times out? If a query returns no results? If Supabase is unavailable?
Input schemas lack proper type definitions and constraints. The 'query' parameter in get_tool_by_query is type 'string' with description 'The search query...' but no minLength, maxLength, or format constraint. 'user_id' and 'server_id' are optional but no guidance on what happens if both are provided.
parse_tool_update_query and detect_multiple_tools_query are utility/parsing functions with narrow, machine-oriented purposes, not user-facing tool queries. Their descriptions do not explain the broader use case, are these called by agents during planning, or only internally?
create_spec_summary accepts a 'tools' array parameter but the structure of each tool object is not formally documented. Expected fields are inferred from the code (tool_name, tool_description, tool_parameters array with tool_parameter_name and tool_parameter_required fields, tool_env_vars array with env_name). Agents will struggle to construct the correct input shape.
No tool declares data sensitivity, rate limits, or permission requirements. Queries to Supabase may return user/server IDs, are these scoped to the caller's organization or globally visible? Can the agent query any user_id or only authenticated users?