Loading ToolBench
A multi-server MCP implementation providing weather queries, SQL database access, and PowerPoint translation capabilities
Three tools with mixed definition quality. All have descriptions and schemas, but descriptions vary in quality and clarity. query_weather and query_database have detailed, usage-focused descriptions (exceeding recommended length), but lack parameter constraint clarity. get_database_schema is minimally described. Parameters are typed but lack LLM-optimized constraint guidance. No schemas document output structure, pagination, or error categories. No tool annotations (readOnlyHint, idempotentHint) present despite all being read-only operations.
Get the database schema as a resource.
Execute SQL query and return formatted results, supporting queries on the sales database. ## Usage Scenario - Querying sales data for analysis - Getting sales statistics for regions, cities, or products - Comparing sales performance across different time periods - Analyzing sales trends for product categories ## Parameter Description :param query: SQL query statement (only SELECT operations are supported) ## Database Structure The database contains a 'sales' table with the following fields: - ID (VARCHAR): Sales record ID - Date (DATE): Sales date - Region (VARCHAR): Region, values include: 関東, 関西 - City (VARCHAR): City, values include: 東京, 横浜, 埼玉, 千葉, 京都, 大阪, 神戸 - Category (VARCHAR): Category, values include: 野菜, 果物 - Product (VARCHAR): Product name, e.g., キャベツ, 玉ねぎ, トマト, リンゴ, みかん, バナナ - Quantity (INT): Sales quantity - Unit_Price (DECIMAL): Unit price - Total_Price (DECIMAL): Total price ## Input Example - "SELECT * FROM sales LIMIT 5" - Query the first 5 sales records - "SELECT Region, SUM(Total_Price) FROM sales GROUP BY Region" - Calculate total sales by region - "SELECT Product, SUM(Quantity) FROM sales WHERE Category='果物' GROUP BY Product ORDER BY SUM(Quantity) DESC" - Query the best-selling products in the fruit category - "SELECT City, AVG(Unit_Price) FROM sales WHERE Product='リンゴ' GROUP BY City" - Query the average unit price of apples in each city ## Notes - Only SELECT and other read operations are supported; modifying the database is not allowed. - Query results will be automatically formatted into a readable table. - More complex queries may take a few seconds to process.
Query weather information for a specified city, providing current temperature, weather conditions, humidity, etc. ## Usage Scenario - Planning trips or outdoor activities - Checking the weather conditions of a specific city - Understanding weather trends to make decisions ## Parameter Description :param city: City name (must use English) ## Input Example - "Taipei" - Query weather for Taipei City - "Tokyo" - Query weather for Tokyo - "New York" - Query weather for New York - "London" - Query weather for London ## Notes - City name must be in English - For city names with spaces, keep the space (e.g., "New York") - Results include temperature, humidity, wind speed, etc.
Missing output schema documentation for all tools. LLMs cannot plan downstream steps or extract return values without knowing response structure.
Tool descriptions exceed 1024 character guideline (query_weather ~420 chars, query_database ~850 chars), creating token inefficiency. Descriptions contain literal examples ('Taipei', 'Tokyo') that LLMs may reuse verbatim.
Missing tool annotations despite all tools being read-only operations. readOnlyHint should be present on all three tools to signal to LLMs that these calls are safe to retry and have no side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
query_database parameter lacks validation guidance. Description states 'only SELECT operations are supported' but does not explain how invalid queries (UPDATE, DELETE, DROP) are rejected or what error message is returned.
get_database_schema has minimal description (17 characters: 'Get the database schema as a resource.'). Does not explain when to call it, what structure it returns, or how it relates to query_database.
query_weather parameter 'city' lacks format constraints. Description notes city name must be English and mentions space handling, but does not specify length limits, character restrictions, or example fallback behavior (e.g., 'city not found' error guidance).
No error handling documentation. Tools do not explain retryable vs. fatal errors, what happens on invalid input, or how LLMs should recover (e.g., if city is not found, should it try alternate spellings?).