Loading ToolBench
MCP server for querying Google BigQuery database
This server demonstrates basic tool structure but has significant gaps in production readiness. All 7 tools are explicitly defined with input schemas and descriptions, but the descriptions are generic and lack LLM-optimization. Parameter descriptions exist but are inconsistent in quality. The schema quality is moderate, most parameters are typed but lack important constraints (enums, min/max values, format specifications). Critically, the tool definitions lack output schema documentation, error handling guidance, and security considerations. The tool naming is reasonable (verb_noun pattern mostly followed), but parameter naming could be more explicit (e.g., 'whereClause' vs 'filter'). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels.
Execute a custom SQL query on the BigQuery dataset
Get the schema/column information for a specific table
Query the CUSTOMERS table with optional filters and limit
Query the LEADS table with optional filters and limit
Query the ORGANIZATIONS table with optional filters and limit
Query the PEOPLE table with optional filters and limit
Output schemas are not documented. Tools return query results but LLMs cannot see what fields to expect. This violates the response-shaper pattern and makes downstream tool chaining difficult.
No error handling guidance. When a query fails (syntax error, permission denied, table not found), the LLM receives a raw error but no recovery path. Error messages should guide the LLM to retry, call a different tool, or ask the user.
Tool annotations missing. execute_custom_query is marked WRITE risk but has no destructiveHint annotation. Query tools are READ_ONLY but lack readOnlyHint. Agents cannot infer safety constraints from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Query the PRODUCTS table with optional filters and limit
execute_custom_query accepts free-form SQL with no input validation or constraint. This is a SQL injection vector. The tool description does not warn of risks or mention that only READ-equivalent queries are allowed (despite WRITE risk marking).
whereClause parameter is a free-form string with example injection vectors in descriptions (e.g., 'Country = "USA"'). No validation or escaping mentioned. LLMs may construct broken SQL if examples are malformed.
No pagination. Query tools accept a 'limit' parameter but no offset or cursor. If an agent requests 100+ rows, results are truncated silently. Large datasets cannot be fully explored.
Descriptions are generic and lack context for LLM selection. 'Query the CUSTOMERS table with optional filters and limit' does not explain WHEN to use this tool or what it returns. Baseline for A-grade tools is 50-200 chars, optimized for LLM reasoning.
No confirmation or dry-run support for execute_custom_query. Agents can inadvertently run destructive queries. A confirmation pattern or dry-run mode would prevent catastrophic errors.