Loading ToolBench
BaseQL MCP has 13 tools with inconsistent quality. Strengths: all tools have action verbs (get_, run_); many have non-trivial descriptions (30-100 chars typical). Critical weaknesses: Input schemas are NOT visible in the provided source code for ANY tool. The tools/index.ts excerpt cuts off mid-registration, showing only the function signature but no actual mcpServer.tool() calls with schemas. Descriptions vary widely in quality, some are clear (get_token_age: '🚨 REQUIRED for holder queries! Returns safe time window'), others are vague (get_capabilities: 'Understand what BaseQL is good at and what it kind of sucks at'). No output schemas documented. Error handling not visible in source. Transport is STDIO-only, capping protocol readiness at 50.
Understand what BaseQL is good at and what it kind of sucks at
get contract by symbol
reverse contract lookup
Batch get CEX prices from Coinbase Exchange
reverse lookup: address to .eth name ONLY (does NOT work for .base.eth Basenames)
batch reverse lookup for .eth names ONLY (does NOT work for .base.eth Basenames)
get SQL template
NO INPUT SCHEMAS VISIBLE. The tools/index.ts file cuts off mid-function and does not show the actual mcpServer.tool() registrations with zod schemas. This is the single largest quality blocker. Cannot verify parameter types, required/optional distinctions, enum constraints, descriptions for parameters, or any structured input validation.
TOOL DEFINITIONS ARE INFERRED, NOT VISIBLE. The provided source code does not show the actual tool registration. Only tool names and descriptions from the HTTP endpoint /tools are visible. The actual mcpServer.tool() calls with full schema definitions must be in the code to receive higher scores.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get Base SQL tables, columns, and best practices
get important SQL rules
🚨 REQUIRED for holder queries! Returns safe time window
Get CEX price from Coinbase Exchange (NOT onchain DEX price)
resolve ENS/Basename to address (forward lookup works for both .eth and .base.eth)
execute SQL against Base
NO OUTPUT SCHEMAS DOCUMENTED. There is no specification of what each tool returns. LLMs cannot plan downstream tool calls or extract required fields without knowing the response structure. For example, does run_sql_query return {rows: [...], count: number}? Or raw data? Does get_contract return {address, symbol, decimals}? Unknown.
VAGUE DESCRIPTION: get_capabilities. Text: 'Understand what BaseQL is good at and what it kind of sucks at' (54 chars). This is informal and does not explain WHEN to call this tool or what the LLM will receive. Better: 'Returns a summary of BaseQL's strengths (token queries, holder analysis) and limitations (real-time pricing, DEX liquidity).'
PARAMETER DESCRIPTIONS MISSING OR INCOMPLETE. For tools with parameters (get_contract, get_contract_by_address, get_query_template, etc.), the parameter descriptions are visible in the schema hints in server.ts (e.g. 'Token symbol (e.g. USDC, ETH, WETH)'), but it's not clear if these are enforced in the actual MCP tool schema. Example values in descriptions (USDC, ETH, WETH) may cause LLMs to reuse them literally instead of adapting to the user's context.
NO ERROR RECOVERY GUIDANCE. The code in server.ts shows try/catch blocks that return generic errors: 'error instanceof Error ? error.message : "tool execution failed"'. LLMs receive unstructured error messages and cannot determine if the error is retryable, user-fixable, or fatal. Example: if run_sql_query times out, the LLM should know to retry with a simpler query or adjust parameters.
PARAMETER CONSTRAINTS NOT DOCUMENTED. For example, get_contract expects 'symbol (e.g. USDC, ETH, WETH)', but there is no specification of valid values, case sensitivity, or fallback behavior if the symbol is not in BASE_CONTRACTS. Similarly, run_sql_query accepts any SQL string with no constraints, timeouts, or injection protection documented.
DEPENDENCIES NOT DOCUMENTED. For example, get_token_age description says '🚨 REQUIRED for holder queries' but does not explain which tools require this precondition or how its output feeds into downstream tools. Similarly, resolve_name docs do not explain when to call it vs get_name_for_address or what happens if a name does not resolve.
RESULT LIMITS NOT SPECIFIED. For tools that return lists (e.g. get_names_for_addresses accepting an array), there is no documented limit on how many items can be queried at once or returned. This risks context window overflow or API abuse.