Loading ToolBench
Devices MCP Platform - Universal IoT and surveillance dashboard with support for Tapo cameras, smart devices, and various integrations (Ring, Nest Protect, Philips Hue, Netatmo, ONVIF, etc.)
This server exhibits multiple critical definition quality gaps. Of the 4 tools, only 2 have complete input schemas (initiate_oauth_flow, handle_oauth_callback, refresh_access_token). The about_server tool has a schema but it is overly simplistic. Descriptions exist for all tools but are superficial (ranging 44-146 chars), lacking WHEN to use, prerequisites, or recovery guidance. The tool names are reasonable (verb_noun pattern for about_server, initiate_oauth_flow, handle_oauth_callback, refresh_access_token) but descriptions do not explain the OAuth flow dependencies or security implications. No output schemas are documented. Error handling is absent, there is no guidance on what to do if OAuth fails, token refresh fails, or state validation fails. The server is a STDIO-only transport (hard cap at 50), and the tool definitions do not reach the baseline quality expected even for that constraint.
Get information about what this MCP server is and what it can do.
Handle OAuth 2.0 callback from Nest API.
Initiate OAuth 2.0 flow for Nest API.
Refresh OAuth 2.0 access token using refresh token.
All tool descriptions are under 150 characters and lack actionable context. 'Initiate OAuth 2.0 flow for Nest API' does not explain WHEN to call it, what happens next, or error recovery. Descriptions should be 50-200 chars with explicit WHEN/HOW/WHY guidance.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract fields without knowing what each tool returns. Document the response shape (success case, error case, pagination if applicable).
No error handling or recovery guidance. If OAuth fails (invalid code, CSRF mismatch, token expiration), the description provides no hint. Add pattern:recovery-guide with examples: 'If state mismatch, the callback was intercepted; regenerate the auth URL.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | 2.12.0+ | v1 |
handle_oauth_callback and refresh_access_token are marked WRITE but have no confirmation or dry-run pattern. Agents may call refresh_access_token without realizing it modifies state, causing unintended side effects. Consider pattern:confirmation-request for destructive operations.
OAuth flow assumes sequential execution (initiate → callback → refresh), but tool descriptions do not document this dependency. An LLM does not know it must call initiate_oauth_flow before handle_oauth_callback. Add explicit dependency hints: 'Call initiate_oauth_flow first, then pass the callback code to this tool.'
Parameter 'state' in handle_oauth_callback is nullable but the description does not explain when it is null vs required. Undocumented dependencies cause silent misuse. Clarify: 'State is optional; if set, must match the state from initiate_oauth_flow. Omitting it disables CSRF protection.'
about_server has a 'level' enum (simple, intermediate, technical) but the description does not explain what each level returns. LLMs cannot predict output or decide which level to request. Expand: 'simple returns: capabilities overview. intermediate returns: available devices and features. technical returns: API version, dependencies, and limits.'