Loading ToolBench
MCP server providing schema-driven LLM interactions with authenticated, auditable workflows for database queries, web search, weather forecasts, and audit logging
Server has 6 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (sql_query, web_search, geocode_location). Descriptions are present and reasonably detailed (100-250 chars typical). However, several tools lack parameter descriptions, output schemas are not formally documented in the tool definitions, and error handling guidance is minimal. The sql_query tool has good input validation via Pydantic but lacks explicit output schema documentation. Search and weather tools have reasonable descriptions but missing some parameter details. Overall: solid foundation but gaps in schema completeness and error recovery guidance prevent higher scores.
Get the schema of available database tables. Use this first to understand what data is available.
Look up coordinates (latitude/longitude) for a city or location name. Use this before calling the weather tool.
Execute a SQL SELECT query against the operations database. Available tables: - customers: id, name, email, company, industry, created_at, lifetime_value, is_active - products: id, name, category, price, stock_quantity, is_available - orders: id, customer_id, order_date, total_amount, status, shipping_city, shipping_country - metrics: id, date, metric_name, value, dimension Only SELECT queries are allowed. Dangerous operations are blocked. Returns structured results with row count and execution time.
View recent audit log entries. Shows tool execution history including user, tool, success status, and timing. Requires 'analyst' or 'admin' role.
Get weather forecast for a location. Provide latitude and longitude coordinates. Use geocode_location first if you have a city name. Returns current conditions and daily forecast.
Output schemas not formally documented. Tools return structured responses (SQLQueryResult, SearchResponse, ToolError) but these schemas are not visible in tool definitions. LLMs cannot plan downstream calls without knowing return field names and types.
database_schema tool has minimal description (under 20 chars of actionable guidance). Does not explain when to call it, what structure it reveals, or how to use results. Violates pattern:tool-description baseline of 34-392 chars.
Error handling lacks recovery guidance. ToolError responses include code and message but do not tell LLM what to do next (retry, ask user, call alternative tool). Violates pattern:recovery-guide.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
Search the web using Tavily API. Returns structured search results with titles, URLs, and content snippets. Requires TAVILY_API_KEY to be configured.
view_audit_log requires 'analyst' or 'admin' role but tool definition does not document permission requirements or error when user lacks access. Violates pattern:scope-declaration.
weather tool requires latitude/longitude but does not explain coordinate format, range validation, or precision. Parameter descriptions lack actionable constraints (e.g., 'Latitude: -90 to 90, decimal degrees').