Loading ToolBench
Server implements 9 tools with complete Zod-validated input schemas and tool annotations. Descriptions exist for all tools and parameters, but quality is mixed. Chinese-language descriptions lack clarity for English-speaking LLM contexts. Tool naming follows verb_noun pattern consistently (upsert_*, create_*, delete_*, search_*, open_*). Schema definitions are rigorous with strict validation. However, descriptions are tersely written (avg ~60 chars) with minimal actionable guidance. Error handling is basic, responses don't guide recovery or provide next steps. No output schema documentation visible. Read-only vs write operations are clearly separated. The server uses Zod for runtime validation but provides no LLM-optimized fallback descriptions or internationalization strategy.
在知识图谱中创建多个实体之间的关系(使用主动语态)
从知识图谱删除多个实体及其关联关系
从知识图谱删除实体中的特定观察内容
从知识图谱删除多个关系
打开指定名称的实体，获取这些实体详情和这些实体之间的关系
根据关键词搜索实体。任意关键词在实体任意部分出现即返回完整实体。本方法可能返回冗余信息，优先使用 search_nodes_smart
根据正则表达式搜索实体。完整匹配名称则返回完整实体；部分匹配名称、或匹配观察详情、类型，则返回简要信息
Descriptions are Chinese-language only and terse (30-60 chars), lacking actionable context for English LLMs. E.g. '创建或更新多个实体，保留原类型，添加观察内容' is underdescriptive, doesn't explain WHEN to use this vs open_nodes, what 'observations' mean, or how it interacts with type preservation.
No output schemas documented. Tools return YAML-serialized responses (via YAML.stringify) but LLMs have no formal schema to understand return structure. E.g., upsert_entities returns {content:[{type:'text', text:...}]} but the internal YAML structure is opaque. This violates pattern:tool which requires documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
创建或更新多个实体，保留原类型，添加观察内容
为知识图谱中已有的实体添加观察内容
Error handling is non-existent. Zod parse errors or graph operation failures will likely throw uncaught exceptions or return generic error messages without recovery guidance. E.g., if delete_entities is called with a non-existent entity name, the response is just '实体删除成功' (success message) regardless of outcome, masking partial failures.
search_nodes_smart parameter names are opaque: 'queryRegexAnyWhere', 'queryRegexEntityType', 'queryRegexObservation'. Unclear whether these are mutually exclusive, what happens if multiple are provided, or what the regex language is (e.g., PCRE, JS RegExp). No guidance on OR vs AND logic or result ranking.
No pagination, result limits, or filtering on read tools. search_nodes_anywhere and search_nodes_smart can return unbounded result sets if the knowledge graph is large, risking context window overflow. No limit parameter or guidance on max results.
Batch tool design lacks feedback granularity. When upsert_entities is called with 10 entities and 3 fail, the response does not indicate which ones succeeded vs failed. This forces agents to retry the entire batch, duplicating successful writes.
No idempotency guarantees stated for write operations. upsert_* tools claim idempotentHint=false, yet upsert_entities says it 'preserves type and adds observations', this sounds idempotent. Inconsistent signals confuse agents about retry safety.
search_nodes_anywhere description mentions 'or operator' for spaces but this is unexplained and non-standard. Description says '空格将视为 or 操作符' (spaces interpreted as OR) but doesn't clarify: is 'alice bob' equivalent to 'alice|bob' in regex? What if users want literal space matching?