Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-100 chars, mostly adequate) and input schemas using Zod validation. However, descriptions lack depth on WHEN to use tools and dependencies between them. Parameter descriptions are minimal or absent. Output schemas are not documented, responses are free-text content arrays rather than structured objects. No error handling guidance (e.g., what to do if a tab ID is invalid). Tool names follow verb_noun convention but lack clarity on mutual exclusivity and side effects. Risk annotations (WRITE, DESTRUCTIVE, READ_ONLY) are present but not surfaced in schema or descriptions for LLM visibility.

• Convert free-text responses to structured JSON objects. E.g., get-list-of-open-tabs should return {tabs: [{id: number, url: string, title: string}]} instead of text strings. This enables reliable field extraction for downstream tool calls.
• Add descriptions to all parameters. E.g., 'tabIds: Array of numeric tab identifiers to close. Each ID must be a positive integer returned by get-list-of-open-tabs.' Include constraints (min/max, format) in descriptions.
• Document output schemas for each tool. Specify the structure, field types, and ranges of returned data. E.g., 'Returns {openTabs: Array<{id: number, url: string, title: string}>}'.
• Add error recovery guidance. Replace 'Failed to X' with actionable messages: 'Tab ID 999 not found. Call get-list-of-open-tabs to see available tab IDs.' This guides LLM retry logic.
• Expose tool risk annotations in descriptions using structured hints. E.g., 'close-browser-tabs: [DESTRUCTIVE] Permanently closes tabs. Cannot be undone. Requires confirmation.' This helps LLMs reason about side effects.