Loading ToolBench
MCP server for PostgreSQL database operations with sentiment analysis and local Hugging Face model support
This server has severe definition quality issues. Of 6 declared tools, only 3 are clearly defined in the source code provided. Two tools ('predict_sentiment' appears twice with different schemas) represent a critical naming conflict. Descriptions are present but often generic and under 100 characters. Input schemas are mostly complete but lack proper type enforcement on several parameters. Output schemas are not documented. The code snippet is incomplete (cuts off mid-response), making full assessment impossible. Most critically, the tool definitions show duplication, inconsistent parameter contracts, and lack of error handling guidance.
Lấy thông tin về model đang được load
Lấy thông tin schema database (tên bảng, cột, kiểu dữ liệu)
Phân tích sentiment của văn bản sử dụng local Hugging Face model
Đánh giá cảm xúc của đoạn văn bản (positive/negative/neutral)
Thực thi câu lệnh SQL SELECT trên database
Lấy dữ liệu từ một bảng trong database
CRITICAL: Duplicate tool name 'predict_sentiment' with different schemas and behaviors. First variant accepts text/model_name/device_map; second accepts only text. This causes naming ambiguity and LLM confusion about which variant to call. Pattern:tool requires each tool name to be unique and unambiguous.
Tool description lengths are inconsistent and often generic. 'Lấy dữ liệu từ một bảng trong database' (48 chars) and 'Lấy thông tin schema database' (28 chars) are too brief to guide LLM selection. Pattern:tool-description recommends 10 - 1024 chars with explicit WHAT/WHEN/PREREQUISITES. Current descriptions lack these elements.
Output schemas are completely undocumented. The rubric (section D) requires documented return types for all tools. Callers cannot plan downstream operations without knowing what fields to expect (e.g., does query_database return result count? column names? raw rows?). This violates pattern:response-shaper and forces agents to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions are minimal. 'model_name' ("Tên model (mặc định: TungCan/tuning-sentiment-abp-pos)") lacks format/constraint guidance. 'uri' ("URI của resource (table) định dạng 'postgres://schema.table'") includes an example but not a formal pattern constraint. Pattern:tool-description requires descriptions to state expected format, range, and constraints.
No error handling guidance in tool descriptions. query_database allows 'chỉ cho phép SELECT, tối đa 10000 ký tự' but provides no error message template for SQL validation failures, malformed queries, or connection errors. Pattern:recovery-guide requires errors to tell the LLM what to do next.
Inconsistent parameter naming. 'uri' in read_resource uses an uncommon identifier. If other tools accept 'table_name' or 'schema' separately, the agent must reason about field mappings. Pattern:tool-chain and mxe:response-field-naming require consistent naming across tools in the same domain.
No pagination support visible in query_database or read_resource. For large result sets, these tools may return thousands of rows, blowing the context window. Pattern:paginated-result requires limit, offset/cursor, and total count to manage large result sets.
SQL injection risk not mitigated in tool definitions. 'sql' parameter in query_database accepts a raw SQL string with only a length constraint (10000 chars). Pattern:tool-gateway requires input sanitization guidance. No mention of parameterized queries or SQL escaping in the description.
Composition issue: predict_sentiment loads a model synchronously on every call. If the agent calls this tool 10 times in succession, model loading latency multiplies. No caching or connection pooling mentioned in tool descriptions. Pattern:tool requires that repeated calls with same input return same result efficiently.