Loading ToolBench
MCP server for retrieving and storing context from a TableStore vector database with support for vector embeddings and knowledge management
This MCP server exhibits significant definition quality issues across multiple dimensions. Tool naming is inconsistent and lacks clarity (e.g., 'tablestore-store', 'tablestore-search' use hyphens instead of underscores; names do not clearly convey actions). Descriptions are present but inadequate, they are written in Chinese, lack English translations for a public tool, and do not follow LLM-optimized patterns (no 'what/when/why' structure). Parameter descriptions are minimal and sometimes missing type information. Input schemas are partially visible but lack comprehensive constraint documentation (no enums for expected values, no format specifications). Output schemas are completely undocumented, we cannot see what these tools return, making it impossible for LLMs to chain them or extract relevant data. Error handling is not visible in the source. Security concerns: the 'metadata' parameter in tablestore-store accepts arbitrary objects without validation. The delete_all_memories tool is highly destructive and the source shows no permission gates or confirmation patterns. No tool annotations (readOnlyHint, destructiveHint) are present despite clear risk levels (WRITE, READ_ONLY, DESTRUCTIVE marked in the spec).
添加记忆到内存系统。存储记忆文本内容并关联用户ID和客户端名称。
删除所有存储的记忆。移除特定用户和客户端的所有记忆记录。
列出所有存储的记忆。检索特定用户和客户端的所有记忆记录。
搜索存储的记忆。使用查询文本在内存系统中搜索相关记忆。
从Tablestore(表格存储)中使用自然语言形式的文本来搜索相似性文档。 输入参数： 1. 'query' 参数应该描述你正在寻找的内容，该工具将返回最相关的文档。 2. 'size' 参数：要返回的相似文档的数量。
将文档存储到Tablestore（表格存储）以供后续检索。 输入参数： 1. 'information' 参数应包含自然语言的文档内容。 2. 'metadata' 参数是一个Python字典，键为字符串，可以存储与该文档相关的元数据。
Tool naming violates verb_noun convention. 'tablestore-store', 'tablestore-search' use hyphens; names do not start with clear action verbs (should be 'store_document', 'search_documents' or similar). LLMs cannot reliably infer intent from these names.
Output schemas are completely undocumented. We cannot see what any tool returns, no response structure, field names, types, or examples are documented. This prevents LLMs from understanding what data is available and chaining tools correctly.
All descriptions are in Chinese only, lack English translations, and do not follow LLM-optimized format (what/when/why). Descriptions are 20-50 characters, below the effective minimum of ~50 chars needed to convey context. This severely limits LLM tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
delete_all_memories is a destructive operation (marked DESTRUCTIVE risk) with no permission gates, confirmation patterns, or dry-run support visible in the source. Tool accepts optional 'user_id' but no validation that the caller has authority to delete memories for that user.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are completely absent from the tool definitions. The risk levels (WRITE, READ_ONLY, DESTRUCTIVE) are documented in the spec but not reflected in the actual tool schema.
Parameter 'metadata' in tablestore-store accepts arbitrary objects (type: object) with no schema constraints, validation rules, or examples. This invites invalid input and makes the tool unpredictable.
No error handling patterns visible. No guidance on what errors can occur, whether they are retryable, or what the LLM should do next. This prevents graceful degradation and agent recovery.
No pagination parameters (page, limit, offset, next_cursor) visible for search_memories and list_memories. Tools returning collections must support pagination to avoid context window exhaustion.
Parameter 'user_id' in memory tools is optional with vague semantics: 'user_id，可选，优先级高于上下文变量' (optional, higher priority than context variables). The fallback behavior and context variable resolution are not documented in English or formally specified.