cdpx defines 5 browser automation tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are terse (10-80 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit error recovery guidance. Parameter descriptions are minimal. Output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. browser_act and browser_goal are WRITE operations but lack confirmation/dry-run patterns. No pagination, batching, or composition guidance. Tool naming follows verb_noun convention (positive), but descriptions fail to explain dependencies (e.g., browser_act requires prior browser_navigate; browser_suggest vs browser_goal distinction unclear).

• Expand tool descriptions to 100-200 chars. For browser_goal vs browser_suggest: 'browser_goal: Executes a single best action to achieve a goal. Use when you want immediate progress. browser_suggest: Ranks all visible elements by relevance. Use to explore options before acting.'
• Document output schemas for all tools. Example: browser_navigate returns {elements: [{id: string, ref: string, text: string, type: string}], token_count: number}. This enables LLMs to extract element references for downstream browser_act calls.
• Add tool annotations: browser_navigate/browser_snapshot/browser_suggest → readOnlyHint: true; browser_act/browser_goal → destructiveHint: true. Enables LLM safety reasoning.
• For browser_act, clarify parameter dependency: 'value: Required when action=type; omit for action=click. Specifies text to input into the element.'
• Add error recovery guidance: 'If browser_act fails with ElementNotFound, call browser_snapshot to refresh the element map and retry with a valid @eN reference.'