Loading ToolBench
IoT project with AI/ML capabilities, device management, knowledge graphs, and MCP server integration
IntelliConnect exposes 18 IoT management and AI control tools with severe definition quality gaps. Most tools have minimal descriptions (typically 10-30 characters in Chinese), lack comprehensive input schema documentation, and contain no output schema specifications. Tool names are inconsistently structured, some use Chinese descriptions rather than English verb_noun patterns (e.g., 'machineMessage', 'getConnectedNum' mix camelCase with vague semantics). Critical security issues: Authorization tokens are exposed as tool parameters rather than server-side injected. The codebase shows Spring Boot HTTP transport with Spring WebMVC MCP support, but tool definitions appear to be manually registered without formal schema validation. Per-tool analysis reveals that while basic input parameters are specified (e.g., Authorization, productId), parameter descriptions are sparse, and no output schemas are documented anywhere. Error handling is absent from tool definitions. Composition suffers: tools like 'aiControl' and 'aiControlStream' duplicate functionality; 'control' is too generic. Tool naming violates verb_noun clarity (readData, readEvent use 'read' but don't clarify reading from what system). This server prioritizes implementation over API surface quality.
Add single product tool ban
请求Agent
使用大模型控制设备
使用大模型控制设备(文字流式)
设备属性或服务控制api接口
Delete MCP server configuration
Delete product tool ban
Delete all product tools ban
Authorization token exposed as tool parameter instead of server-side injection. Tokens appear in src/main/java/top/rslly/iot/controllers/Tool.java as explicit 'Authorization' parameter across all 18 tools. This violates pattern:secret-injection, secrets in tool parameters leak into agent traces, logs, and prompt history.
No output schemas documented for any tool. Tool.java defines tools but provides no return type specifications. LLMs cannot plan downstream tool calls or understand what data they'll receive. Violates pattern:tool (100% of A+ tools have documented return types).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
用于获取连接的设备数量
Get MCP server list for authorized user
Get product tools ban list
用于获取平台运行环境信息
获取属性实时数据
Create new MCP server configuration
Post product tools ban configuration
用于获取物联网一段时间的设备数据
用于获取物联网一段时间的设备事件数据
停止大模型文字流式生成
Tool descriptions are minimal or trivial (10-40 characters). Examples: 'machineMessage' ("用于获取平台运行环境信息"), 'agent' ("请求Agent"). Rubric baseline: avg 194 chars, 94% of A+ tools have substantial docstrings. These are below 50 chars and omit WHAT the tool does, WHEN to use it, and any prerequisites. Violates pattern:tool-description.
No error handling guidance in tool definitions. No error categorization (retryable, user-fixable, fatal), no actionable error messages, no recovery hints. Violates pattern:recovery-guide and pattern:error-classification, errors should tell the LLM what to do next.
Duplicate/overlapping tool functionality: 'aiControl' and 'aiControlStream' both control devices via LLM but with different streaming modes. LLMs will waste reasoning cycles deciding which to use. Additionally, 'control' is too generic and doesn't clarify its scope vs 'aiControl'. Violates pattern:tool (each tool should do exactly one thing with clear naming).
Generic tool names lack verb_noun clarity. 'machineMessage' (noun-noun, unclear action), 'metaData' (noun, no verb), 'agent' (bare noun), 'control' (single verb, no object). Baseline: 90% of A+ tools start with action verb. These violate pattern:tool naming, LLMs rely on name to infer intent before reading description.
Parameter descriptions are missing or extremely sparse. Example: 'readData' has parameter 'readData' with description 'Time range and device parameters using millisecond timestamps', no field-level breakdown of what 'readData' object expects (keys, ranges, constraints). 'control' parameter 'controlParam' has only 'Control parameters for device property or service', no explanation of what fields it accepts. Violates pattern:tool-description (every parameter needs non-empty description explaining what it controls).
No pagination, result limits, or list handling documented. Tools like 'readData', 'readEvent', 'getMcpServerList' return data but no specs for limits, pagination, or how to handle large result sets. Violates pattern:paginated-result, tools returning lists must accept page/offset/limit and return counts.
Destructive operations lack confirmation/dry-run support. 'deleteProductToolBan', 'deleteProductToolsBan', 'deleteMcpServer' are irreversible but have no mention of confirmation steps or dry-run capability. Violates pattern:confirmation-request, agents make mistakes and need reversible paths for destructive ops.
No permission/scope declarations visible. Tools handle device control, MCP server management, and product configuration but lack explicit permission requirements (e.g., 'requires: write:device', 'requires: admin:mcp-servers'). Violates pattern:scope-declaration, each tool should declare what permissions it requires for least-privilege agent setup.
Tools accept complex object parameters (readData, control, aiControl, metaData, aiControlStream) but do not specify the schema of those objects. 'control' accepts 'controlParam' as object with zero documentation of its shape. LLMs cannot know what fields to pass. Violates pattern:constrained-input, use structured schemas with typed fields and descriptions.
ProductToolsBan tools (addProductToolBan, postProductToolsBan) use enum constraints on toolsName parameter with cryptic values ['1','2','3','4','6','7','8','9','10','knowledge','knowledgeGraphic']. Numeric enums are not self-documenting, 'toolName: 1' is meaningless to an LLM. What is tool '1'? Violates pattern:constrained-input (enums must be human-readable).