This server has 4 tools with basic implementations but significant quality gaps. All tools have descriptions and schema visibility, but descriptions are Chinese-language and lack LLM optimization. Parameter schemas are present but minimal. No error recovery guidance. No tool annotations. Single responsibility is generally met, but output documentation is sparse.
将 Base64 文本解码为 UTF-8 字符串
将明文字符串编码为 Base64 文本
使用 Python 代码在文件中搜索指定字符串(支持文本和二进制文件)
使用 strings 命令在文件中搜索指定字符串(支持二进制文件)
Tool descriptions are in Chinese only, making them inaccessible to English-language LLM agents and reducing discoverability in multilingual deployments.
Descriptions lack LLM-optimized context. They state WHAT the tool does but not WHEN to use it or WHY it's better than similar tools. For example, search_string_in_file_by_strings vs search_string_in_file_by_code lack clear differentiation criteria for agent selection.
No documented output schemas. Tool functions return strings (encode_base64, decode_base64 return str; search functions return formatted str), but LLMs have no machine-readable specification of response structure, forcing them to parse free-text output.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Error responses are contextual strings (e.g., '编码失败: {str(e)}'), not structured error objects. They lack recovery guidance, LLMs cannot determine if errors are retryable, user-fixable, or fatal.
Naming conflict: search_string_in_file_by_strings and search_string_in_file_by_code are semantically similar but have cryptic differentiators ('by_strings' vs 'by_code'). LLMs will struggle to choose between them. Consider rename_to_search_strings_with_shell vs search_strings_with_python or use a single parameterized tool.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All four tools are read-only and idempotent, but the server does not declare this via schema metadata, forcing LLMs to infer safety properties.
Parameter min_length in search_string_in_file_by_strings has a default (4) but lacks constraint documentation (e.g., 'must be >= 1'). No bounds checking visible in code.