Loading ToolBench
ssid.ai MCP server: manufacturer-cited router default logins and the Router Compliance Index (409 models), plus MAC/OUI vendor lookup with randomized-address detection. Free, no API key.
Four tools with complete input schemas and descriptions. Naming is clear and verb-driven (get_, check_, lookup_, submit_). Descriptions are detailed (150-250 chars) and explain WHEN to use each tool. Parameters have types, descriptions, and constraints (regex patterns, min/max lengths). Error handling is thoughtful, tools return actionable messages ('Not found: no router...', 'ambiguous: matches N models'). Main gaps: no output schema documentation, no per-parameter type hints in descriptions (e.g., 'string' is implicit from schema but not stated in prose), and no explicit idempotency or retry guidance for submit_correction.
Whether a router model still ships a universal default password, the pattern prohibited for consumer connectable products under the UK PSTI Act and targeted by the EU Cyber Resilience Act, based on the manufacturer-cited credential type, with the ssid.ai Router Compliance Index totals for context. Pass the ssid.ai slug (get it from get_router_defaults). Documentation reading, not legal advice.
Default gateway IP, admin username and password (or the fact that there is none), credential type and factory-reset steps for a router or gateway model, each cited to the manufacturer's own documentation with the source URL. Pass the ssid.ai slug, or brand plus model. Use after lookup_mac identifies the vendor, or whenever a user asks for a router's default login, factory password, gateway address or reset procedure. Covers the 409-model ssid.ai directory; no listing or wildcard search.
MAC address or OUI (Organizationally Unique Identifier) to vendor name, with randomized-address detection. Pass a full 48-bit MAC or a 24-bit OUI (the first three octets). Returns the vendor, whether the address is randomized (per RFC 7844), and the OUI registration date. Use before get_router_defaults to identify a device's manufacturer from its MAC address.
Propose a fix to a router record in the ssid.ai directory: correct a default password, gateway IP, credential type, factory-reset procedure, or source URL. The correction is queued for verification by ssid.ai staff and never auto-applied. Corrections are not for adding new models (use ssid.ai/submit instead). Pass the slug (from get_router_defaults), the field name (e.g. 'defaultPassword', 'credentialType'), the proposed value, and the URL of an official manufacturer page that cites it.
Output schemas not documented. Tools return JSON but LLMs cannot infer field names, types, or structure. E.g., get_router_defaults returns device data but no schema is visible for what fields (defaultPassword, gatewayIp, credentialType, etc.) are included.
submit_correction lacks idempotency and retry guidance. Tool description does not state whether repeated calls with identical parameters are safe or if the correction is queued once. Agents may retry on transient failures and create duplicate submissions.
lookup_mac parameter 'mac' lacks explicit format guidance in description. Schema shows no pattern constraint; description says 'MAC address (48-bit, e.g. aa:bb:cc:dd:ee:ff) or OUI (24-bit, e.g. aa:bb:cc)' but does not state whether colons are required, case-insensitive, or if dashes are accepted.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
get_router_defaults and check_router_compliance accept optional slug OR brand+model, but no description clarifies mutual exclusivity or precedence. If both are provided, which takes priority? This ambiguity forces LLMs to guess.
Error messages reference 'ssid.ai directory' and 'ssid.ai staff' but do not explain what happens next. E.g., 'Correction is queued for verification by ssid.ai staff', how long does verification take? Can the user check status? This leaves agents without recovery guidance.