Loading ToolBench
wpa-mcp has 22 well-named tools organized into 5 domains (WiFi, browser automation, connectivity, credentials). Tool names follow verb-noun patterns (wifi_connect, browser_click, credential_store_add) and are generally descriptive. Descriptions are present for all tools and range from 40-120 characters, meeting baseline expectations. However, parameter descriptions vary significantly in quality, some are minimal (e.g., 'Credential identifier' without format guidance), and several tools lack output schema documentation. Error handling is basic; no recovery guidance provided. Security concern: credential_store_add exposes sensitive paths as parameters, though passwords are documented as optional. Most parameter schemas are well-typed with enums where appropriate (e.g., auth_type in wifi_connect, wifi_set_country). Output schemas are not documented in visible source, which is a significant gap for LLM planning. Tool composition is good, each tool has a single clear responsibility, and related tools (wifi_*, browser_*, etc.) form coherent chains. Browser automation tools lack mention of async/state management, which could confuse agents about tool sequencing.
Click an element in the browser
Close the browser
Fill a form field in the browser
Get text content from an element
Open a URL in the browser running in the container's network namespace
Take a screenshot of the current page
Select an option from a dropdown in the browser
Wait for an element to appear
Check if internet connectivity is available
Output schemas not documented. No evidence of return type documentation for any tool. LLMs cannot infer expected response structure, breaking downstream tool composition planning and forcing exploratory calls.
credential_store_add exposes file paths (client_cert_path, private_key_path, ca_cert_path) as mutable parameters. Best practice requires server-side secret injection via environment or vault. Paths in params get logged and could leak sensitive file locations.
No error recovery guidance. Error responses likely return raw status codes or exceptions without actionable guidance. E.g., 'Connection failed' vs 'Connection timeout, check network, retry in 10 seconds.' Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Check if WiFi is available and connected
Add or update a credential in the credential store
List available credentials
Remove a credential from the store
Perform DNS lookup
Ping a host to verify connectivity
Connect to a WiFi network using wpa_supplicant
Disconnect from the current WiFi network
Remove a saved WiFi network
List saved WiFi networks from wpa_supplicant config
Scan for available WiFi networks
Set WiFi regulatory country code
Get current WiFi connection status
Browser tools lack state/sequencing documentation. browser_click, browser_fill, browser_select do not explain whether the browser is persistent across calls, how to chain operations, or error states if selectors don't match. Agents may assume wrong execution model.
Selector parameter descriptions lack format guidance. 'CSS or XPath selector' is present, but no examples of valid selectors, syntax rules, or error cases when selector is invalid. LLMs may pass malformed selectors.
credential_store_add password parameter documented as optional but no guidance on which auth_type enums require it vs allow omission. Dependency between parameters (auth_type → password optionality) is undocumented.
Timeout parameters (wifi_connect.timeout_sec, browser_wait.timeout_ms) lack min/max bounds. No guidance on reasonable ranges, agents could pass negative or 0 values, or unreasonably large timeouts.
No pagination or result-limiting documented for list tools (wifi_list_saved, wifi_scan, credential_store_list). If lists are large, output could exhaust context window without agent awareness.