Vessel Browser exhibits significant definition quality gaps across its 22 tools. While tool names follow verb_noun conventions and risk levels are properly classified, critical deficiencies emerge in parameter documentation, schema completeness, and output specifications. Most tools lack detailed parameter descriptions, they declare parameter existence but do not explain format, constraints, or valid ranges. For example, 'click' accepts 'text', 'selector', and 'index' parameters with minimal guidance on when to use each or what happens if multiple match. Several devtools tools (tools 20-22) have completely empty input schemas ({}), violating baseline requirements. Error handling is largely absent; tools do not guide recovery or categorize failures as retryable vs. fatal. The 'read_page' tool with 'debug' mode suggests sophisticated functionality but lacks documentation on output differences between modes. Output schemas are not formally documented in source code, responses appear to be inferred from tool behavior rather than explicit schema definitions. No evidence of per-tool audit trails, rate limiting, or permission gates. Security posture is undocumented; no clear separation of credentials vs. tool parameters.

• Add formal output schema documentation for all tools. For list_* tools, specify whether results are paginated, what the page/limit parameters are, and what fields each item contains. For read_page, document output format differences for 'default' vs. 'debug' modes and provide example output.
• Document every parameter constraint. For 'click', add guidance: 'Match priority: selector (exact CSS) > text (substring match) > index (integer 0+). If multiple elements match, uses first match. Return error if zero matches.'
• Add error handling recovery guides. Example: 'If navigate fails with ERR_INVALID_URL, check that URL starts with http:// or https://. If click fails with ERR_NO_MATCH, call read_page(mode="debug") to see current DOM.'
• Implement confirmation pattern for destructive operations. devtools_modify_dom and archive_bookmark should accept optional dry_run=true parameter and return predicted changes before execution.
• Define per-tool pagination limits and document them in descriptions. For list_tabs, list_bookmarks, and web_search, specify max result count (e.g., 'Returns up to 50 items; use offset parameter for pagination').
• Add tool composition documentation in a README or pattern guide. Explain: 'Typical workflow: read_page() → extract selectors/text → click(selector=...) or inspect_element(selector=...). Selectors remain valid until next navigation.'
• Create explicit input schemas for devtools_execute_js, devtools_modify_dom, and devtools_set_storage. At minimum, add 'code' (string) parameter to devtools_execute_js, 'dom_changes' (array) to devtools_modify_dom, and 'key'/'value' (strings) to devtools_set_storage.