Loading ToolBench
MCP server for searching engine oil information from a PostgreSQL database, deployed on Google Cloud Run
This server has a single tool with severe quality gaps. The tool name 'search_engine_oil' is grammatically awkward and violates naming conventions (should be 'search_oil' or 'find_oil_specification'). The description is non-English ('搜尋引擎機油工具' = 'Search Engine Oil Tool') and only 12 characters when translated, providing minimal context for LLM selection. The input schema is present with three optional parameters (brand, model, year) that have descriptions, but the tool lacks an output schema definition, critical for agents to understand what data is returned. The implementation shows a stub that always returns a hardcoded string ('資料庫連線成功！') rather than actual search results, making it unsuitable for production. No error handling guidance, no parameter constraints (e.g., year range), and no documentation of when/why to call this tool versus alternatives. The code comment indicates SQL logic is missing ('這裡維持你原本的 SQL 邏輯'), suggesting incomplete implementation.
搜尋引擎機油工具
Tool name is awkward and non-idiomatic. 'search_engine_oil' violates verb_noun conventions and is ambiguous, does it search for oil, search for engines, or search in an oil database? Should be 'search_oil', 'find_oil_spec', or 'get_oil_recommendation'.
Description is non-English ('搜尋引擎機油工具') and only 12 characters when translated. Does not explain WHAT the tool does, WHEN to use it, or what it returns. Violates the 10-1024 character guideline and the 50-200 character LLM-optimization baseline. LLMs cannot reliably select or invoke this tool without a clear English description.
No output schema documented. Agents need to know what fields are returned (e.g., oil_type, viscosity, price, availability). Without output schema, agents cannot chain this tool to downstream calls and must guess at response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Parameters lack constraints and detailed guidance. 'year' parameter has no min/max range (e.g., 1900 - 2026). 'brand' and 'model' accept arbitrary strings with no enum, validation, or examples. No documentation of valid brands or models, forcing LLMs to guess.
No error handling or recovery guidance. Implementation has a stub returning a hardcoded string. Real failures (database unavailable, no matching oil found, invalid vehicle year) have no error messages to guide LLM recovery. Missing 'Try search_users() first' patterns or retry advice.
Implementation is incomplete and non-functional. Code contains '這裡維持你原本的 SQL 邏輯' (placeholder comment), actual SQL query logic is missing. Tool returns hardcoded 'Database connection successful!' instead of search results, making it unsuitable for production use or testing.
No parameter dependencies or mutual exclusivity documented. Should clarify: Are all three parameters optional? What happens if none are provided (return all oils, or error)? Can users search by just brand, or must they provide model + year? This forces LLMs to guess at valid invocation patterns.
No pagination or result limit. If 'search_engine_oil' returns 1000+ matching oils, the response could exhaust context window. No mention of limit parameter, pagination tokens, or max result count.