An intelligent agent communication platform based on LLM with MCP server integration, tool management, and multiple agent capabilities
This MCP server exhibits significant structural and quality issues that would not be recommended for production use. While tool definitions are present with some schemas, they suffer from inconsistent naming conventions, inadequate parameter descriptions, missing output schema documentation, and poor error handling patterns. The tools lack proper composition boundaries (many are CRUD variants of the same resources), and descriptions are often too generic or missing critical context. The codebase shows basic error handling with generic ValueErrors, but no recovery guidance or classification. Most critically, many tool parameters lack descriptions entirely or are minimal, violating the baseline that 100% of A+ tools have documented parameters.
Convert English tool name to Chinese name
Create an MCP server configuration with connection details and tools
Create an MCP STDIO server configuration with command and environment setup
Create a custom tool with Chinese name, English name, description, and logo URL
Delete an MCP server configuration
Delete an MCP STDIO server configuration
Delete a tool by its ID
Excessive tool fragmentation: 20 tools with significant duplication in purpose (get_all_tools, get_tools_data, get_tool_ids_from_name, get_id_by_tool_name, get_tool_name_by_id all query the same resource in slightly different ways). This violates the single-responsibility principle and forces LLMs to reason about which variant to use, wasting inference cycles.
Output schemas not documented. Tools like get_all_tools, get_mcp_servers, get_mcp_tools return lists, but the structure of list items, field names, and types are not declared in tool definitions. This forces LLMs to guess at response structure and plan downstream tool calls without clear field mappings.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Retrieve all available tools in the system
Get tool ID by tool name for a specific user
Retrieve all MCP servers accessible to the user
Retrieve all STDIO MCP servers for a user
Get detailed tool information from an MCP server
Retrieve all tools created by a specific user
Get multiple tool IDs from their names, including system tools
Get tool English names by their IDs
Retrieve all tools data in dictionary format
Retrieve all tools visible to a user, including personal tools and system tools
Update MCP server configuration including name, URL, and connection type
Update an MCP STDIO server configuration
Update tool information including Chinese name, English name, description, and logo URL
Parameter descriptions are missing or minimal. The 'config' parameter in create_mcp_server is described only as 'MCP Server 的配置信息' (MCP Server config info), with no guidance on what fields it contains, required keys, or valid values. The 'type' parameter in create_mcp_server lacks explanation of what SSE vs Websocket means in practice. This violates the baseline that 100% of A+ tools have parameter descriptions.
Inconsistent naming convention mixes verb_noun (create_tool, delete_tool) with noun_verb variations (get_visible_tool_by_user) and non-standard patterns (convert_zh_name_from_en_name). While action verbs are present, the inconsistent ordering and multi-part constructions reduce clarity. LLMs would benefit from uniform get_<resource>, create_<resource>, delete_<resource>, update_<resource> naming.
No error recovery guidance. The service layer raises generic ValueError exceptions like 'Create Tool Appear Error: {err}' without actionable recovery steps. Error responses should classify as retryable/user-fixable/fatal and suggest next steps (e.g., 'Tool name already exists. Try a different name or call get_all_tools() to verify uniqueness.').
Destructive operations (delete_tool, delete_mcp_server) lack confirmation or dry-run support. An agent that mistakenly identifies the wrong tool_id will permanently delete it without a recovery path. Consider adding a confirm_delete or preview_delete step.
Tool descriptions are generic and lack context. Many descriptions (e.g., 'Retrieve all tools created by a specific user' for get_personal_tool_by_user) do not explain when to use this tool vs. similar alternatives (get_visible_tool_by_user, get_all_tools). LLM selection quality suffers when tools lack distinguishing context. Descriptions should answer: What does it do? When to use it instead of similar tools?
Pagination not implemented. Tools like get_all_tools, get_mcp_servers, and get_mcp_stdio_servers return unbounded lists with no limit, offset, or cursor parameters. If a system has thousands of tools or servers, these calls will fetch everything, bloating responses and exhausting context windows.
Language mismatch in descriptions. Parameter and tool descriptions are primarily in Chinese (e.g., '工具的中文名称', 'MCP Server 的配置信息'), while tool names and the broader API are in English. This creates friction for non-Chinese-speaking LLM users and complicates multilingual prompting.