BrowserControl has 7 tools with complete Zod schemas and descriptions. Naming follows verb_noun convention (open-browser-tab, close-browser-tabs, get-list-of-open-tabs). Descriptions are present but vary in quality (10 - 200 chars). All parameters have type definitions and most have descriptions. However, several descriptions are terse (e.g., 'Close tabs in the user's browser by tab IDs' lacks context on when to use it). Output schemas are not formally documented, responses are inferred from code. Error handling is minimal (basic success/failure returns). No parameter validation guidance (e.g., valid tab ID ranges, URL format constraints). Tool composition is sound (each does one thing), but descriptions could better guide LLM selection and error recovery.

• Document output schemas for all tools. Specify return type (e.g., 'Returns object with content array of text items and optional isError flag') so LLMs know what fields to expect.
• Expand descriptions to 50 - 150 characters with WHEN and WHY context. E.g., 'Close one or more browser tabs by their IDs. Use after get-list-of-open-tabs to find tab IDs. Returns success or error if tab ID is invalid.'
• Add parameter constraints in descriptions. E.g., 'tabId (number): The ID of the tab (valid range 1 - 9999, obtained from get-list-of-open-tabs).'
• Implement error recovery guidance. E.g., 'Failed to open tab: URL may be invalid. Try a simpler URL or check browser console for errors.'
• Add tool annotations via MCP SDK (readOnlyHint for get-* tools, destructiveHint for close-* and reorder-* tools) to help LLMs reason about side effects.