Loading ToolBench
Three tools present with schemas and descriptions visible in source. However, significant quality gaps limit usefulness: (1) hxq_login has 25 parameters with many redundant device fields that should be abstracted or optional-by-default; (2) descriptions are present but generic and do not explain WHEN to use each tool or dependencies; (3) no error guidance in descriptions, LLMs cannot understand failure modes or recovery paths; (4) parameter descriptions lack constraints, formats, or examples of valid values; (5) no output schema documentation despite complex response types (LoginResponse, VersionConfig, etc. are defined but not exposed in tool registration); (6) naming convention inconsistent (hxq_login vs check_login_status vs refresh_token, first uses underscores between words and prefix, others do not follow verb_noun pattern clearly); (7) check_login_status and refresh_token are discovery/utility tools but lack context about when to call them relative to hxq_login; (8) no documented authentication flow or token lifecycle; (9) security concern: tools accept credentials (password, verify_code) as parameters, no mention of encryption, HTTPS, or secure transmission in descriptions.
检查用户登录状态 Args: user_token: 用户token Returns: 登录状态信息
盒小圈APP登录接口 Args: account: 用户账号（手机号码） login_type: 登录类型，"0"=密码登录，"1"=验证码登录 password: 密码（密码和验证码必传一个） verify_code: 验证码（密码和验证码必传一个） client_type: 客户端类型 client_version: 客户端版本 channel: 客户端渠道 imei: 移动设备ID manufacturer: 移动设备制造商 model: 移动设备型号 os_version: 移动设备系统版本 device_id: 设备ID os_image: 屏幕分辨率 storage_space: 内存大小 wifi_ssid: WiFi名称 providers_name: 移动运营商 cpu_architecture: 设备CPU架构 latitude: 登录经度 longitude: 登录纬度 push_id: 个推deviceId register_id: 个推cid signature: 加密串 timestamp: 时间戳 user_agent: 用户代理 Returns: 登录响应数据，包含用户信息和token等
刷新用户token Args: refresh_token: 刷新token Returns: 新的token信息
Tool descriptions lack recovery guidance and error classification. Descriptions state WHAT tools do but never explain failure modes, retryability, or next steps. For example, hxq_login description mentions two password modes but never states which errors are retryable (invalid password) vs fatal (account locked) vs user-fixable (wrong login_type). LLMs cannot plan error recovery without explicit guidance.
No output schema documented. hxq_login has a complex LoginResponse with ~40 fields (userId, userToken, refreshToken, versionConfig, areaUpdateInfosList, bottomConfigList, etc.) but tool registration exposes no return type hint. LLM cannot predict what data is available in the response and must guess which fields to extract for follow-up calls (e.g., userToken for check_login_status). Broken tool chains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Parameter constraints missing or loose. hxq_login login_type accepts string '0' or '1' but schema does not declare enum, LLM could pass 'password', 'code', or other strings and fail silently. account parameter says 'phone number' but no regex or length constraint. Many optional params (imei, manufacturer, model, etc.) have empty string defaults, suggests poor API design abstraction. Should be wrapped in a single 'device_info' object or provided server-side.
Credentials exposed as tool parameters. hxq_login accepts 'password' and 'verify_code' as parameters. These will be logged in agent traces, prompt history, and audit logs. Server implementation includes MD5 encryption in-tool, but parameter itself is transmitted as plaintext to the MCP server, then hashed. Should use server-side secret injection (environment variables, vault, or secure storage) and never expose credentials as parameters.
Tool descriptions are too brief and generic (20-50 chars). Baseline for A-tier tools is 50-200 chars per description. Current descriptions lack actionable detail: 'Check user login status' does not explain when to call it, what it validates, or how it relates to other tools. These descriptions are at the lower bound.
No token lifecycle or dependency documentation. Tools form an implicit sequence (hxq_login -> check_login_status | refresh_token) but descriptions never state this. LLM cannot infer when to call check_login_status (periodically? after login? before every action?) or when refresh_token is needed (after expiry? before expiry returned as error?). Composition pattern violated.
No permission gates or scope declarations. Tools perform authentication and session management, sensitive operations that require audit trails and permission checks. No mention of what credentials are required, what scope the tools grant, or what user identity is asserted. Violates pattern:scope-declaration and pattern:audit-trail.
Redundant device parameters in hxq_login. 15 device-related parameters (imei, manufacturer, model, osVersion, deviceId, osImage, storageSpace, wifiSsid, providersName, cpuArchitecture, latitude, longitude, pushId, registerId, userAgent) are exposed individually with empty defaults. This is poor API abstraction, should be collapsed into a single 'device_info' object, provided server-side via configuration, or collected via a separate discovery tool. Current design increases parameter count and error surface.