MOAB-generated MCP server for browser automation. Provides tools for launching sites, navigating, interacting with pages, mining UI elements, and executing saved automation workflows.
MOAB MCP server has 6 tools with complete input schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (launch, navigate, interact, snapshot_ui, get_page_content, list_sessions), which is good. However, parameter descriptions are sparse or missing entirely. The 'interact' tool has an 'items' schema with type 'object' but no description of what properties those objects should contain, LLMs cannot infer valid step structures. The 'selectors' parameter in 'interact' has a description but no schema constraints. Output schemas are not documented anywhere, LLMs must guess what fields are returned. Error handling exists (problem() function) but provides generic guidance ('This may succeed on retry') rather than actionable recovery steps. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in the spec.
Read previously captured page content from disk. Does not launch a browser.
Run a sequence of fill / select / click / press / wait steps against the site, then capture the result.
Open the site's landing page with the cached session (falls back to an interactive sign-in window when required) and capture the page. Returns redacted page text wrapped as untrusted content.
List cached sessions with capture time and freshness. No cookie values are stored or returned.
Navigate to a route within the site using the existing session and capture the page.
Mine the current page for automatable features (accessibility tree first, DOM second) and return ranked candidates with suggested selectors. Use this before authoring a feature file.
interact tool has untyped 'steps' array with items of type 'object' but no schema for step properties. Description mentions 'navigate, fill, select, click, press, check, uncheck, waitFor, waitForTimeout, capture' but does not specify required fields, parameter types, or constraints for each action type. LLMs cannot construct valid steps without explicit schema.
No output schemas documented for any tool. LLMs must infer return structure from descriptions alone. E.g., 'launch' returns 'Title, URL, Saved' but the actual JSON structure is not specified. This forces LLMs to guess field names and types, increasing errors in downstream tool chaining.
Parameter 'selectors' in interact tool has description but no type constraints or schema. It accepts 'Named selector definitions, e.g. { search: { strategy: 'getByRole', role: 'searchbox' } }' but does not specify valid strategies, required fields, or format. Example values in descriptions invite literal reuse rather than adaptation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Error handling via problem() function returns generic guidance ('This may succeed on retry') without categorizing errors as retryable, user-fixable, or fatal. No actionable recovery steps, e.g., 'Session expired. Call launch() to re-authenticate' or 'Invalid selector. Use snapshot_ui() to discover available elements.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications in spec. 'interact' is marked WRITE but tool definition lacks destructiveHint. 'launch', 'navigate', 'snapshot_ui', 'get_page_content', 'list_sessions' are READ_ONLY but lack readOnlyHint annotation. Agents cannot infer safety properties from names alone.