Loading ToolBench
MCP server for Yunnan University integrations including Coremail email system, WeChat Work enterprise messaging, and staff information platform
The server implements 17 tools across five modules (prompts, resources, examples, coremail, staff, weixin-work). Most tools have minimal descriptions (many under 50 chars) and lack proper parameter type annotations in several cases. Parameter descriptions are often missing or vague. No input validation, error recovery guidance, or output schema documentation visible. The dynamic loader pattern is clever but obscures actual tool registration from static analysis. Naming is generally reasonable (verb_noun style) but inconsistent descriptions and incomplete schemas keep quality low. This is a typical community server, functional but not production-ready.
添加 coremail 用户 user_at_domain 的别名信息
Calculate BMI given weight in kg and height in meters
Debug error with user and assistant message context
添加 coremail 用户 user_at_domain 的别名信息
Fetch current weather for a city
获取 coremail 用户 user_at_domain 的指定属性（默认为姓名，统一身份认证用户名，用户状态）信息
获取 coremail 用户 user_at_domain 的用户的别名信息
Parameter type annotations incomplete: 'attrs' in getAttrs() has default value but no type hint; 'user_alias_at_domain' in addSmtpAlias/delSmtpAlias lacks type annotations; 'password' in updatePassword has no type hint. JSON Schema inference is weak.
Descriptions are inconsistent and often trivial (< 50 chars). Examples: 'Static configuration data' (23 chars), 'Dynamic user data' (17 chars), 'Error message to debug' (21 chars). No context about when to use, expected format, or return structure.
No output schema documentation. Tools return strings, dicts, bools, or lists without declared structure. LLMs cannot infer downstream field names (e.g., does getAttrs return a dict with keys 'true_name', 'cas_name'? Not documented).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
根据 统一身份认证用户 cas_name 查找 coremail 用户
Static configuration data
获取教职工信息，可通过教职工工号、姓名、手机号等信息查询
根据企微用户id userid 获取企微用户信息
Dynamic user data
根据企微用户电话号码 telphone 获取企微用户id userid 信息
Please review this code
修改 coremail 用户 user_at_domain 的密码为 password
根据企微用户id user_id 及企业邮箱别名 biz_mail_alias 设置其企业邮箱别名
检查 coremail 用户 user_at_domain 是否存在
No error handling guidance. Functions catch API errors and return f'Error: ${result['message']}' as a string. LLMs are told nothing about retryability, root cause, or next steps. Example: addSmtpAlias could fail due to invalid email, user not found, or permission denied, indistinguishable to the caller.
Naming inconsistency: 'getAttrs', 'getSmtpAlias', 'addSmtpAlias', 'delSmtpAlias', 'userExist2' use camelCase; 'calculate_bmi', 'fetch_weather', 'get_staff_info' use snake_case. Mixed conventions confuse LLM parsing. Also, 'userExist2' and 'delSmtpAlias' descriptions are misleading, delSmtpAlias says 'Adding' when it deletes.
Secrets exposed as parameters: tools in coremail.py and rs_staff.py likely depend on API keys (CoremailClient, data_platform calls) but these are injected via environment variables, not exposed in tool params, this is correct. However, fetch_weather directly uses os.getenv('OPENWEATHER_API_KEY') which is good practice, but error messages may leak token info if API calls fail.
Tool parameters lack validation and constraint documentation. Examples: user_at_domain format not validated (should be user@domain); password in updatePassword has no minimum length or complexity requirement stated; city in fetch_weather has no validation or list of supported cities. LLMs will pass arbitrary values.
No permission gates or audit logging. Destructive tools (addSmtpAlias, delSmtpAlias, updatePassword) modify state without checking caller authority or logging who triggered the change. This violates audit-trail and permission-gate patterns.
Tool composition issues: lookup tools (getUserFromCasName, get_userid_by_telphone) return minimal info; chaining to other tools (e.g., getting user info after lookup) requires a second call. Response should include user_at_domain or user_id from the start to enable single-call composition.
fetch_weather async but no timeout declared; hung API calls block the server. No pagination or result limits for list-like tools. No idempotency guarantees (e.g., addSmtpAlias called twice with same params, does it error or succeed twice?).