No output schema documentation. Tools provide no documented structure for responses, agents cannot plan downstream calls, extract fields, or validate results. This violates the 'SCHEMAS & OUTPUT' pattern and forces LLMs to infer response format.

Generic 'client_' prefix does not convey action semantics. Names like 'client_summarize' tell the LLM 'this runs in the browser' but not 'this extracts key points' or 'this produces a summary'. The verb is buried. Consider 'summarize_text', 'analyze_sentiment', 'translate_text', clearer intent.

Parameter descriptions lack format guidance and constraints. 'language' in client_transcribe_audio says 'auto-detect' as an option but does not specify valid language codes, format (ISO 639-1? BCP 47?), or what happens if the code is invalid. This invites LLM hallucination of invalid values.

No error handling guidance. Tools do not document failure modes (network unavailable, model not loaded, invalid URL, unsupported format). LLMs have no recovery hint, they cannot retry intelligently or fall back to alternatives.

Descriptions are below LLM-optimized length. Best practice is 50 - 200 characters; these average 40 characters. For example, 'Analyze sentiment (positive/negative/neutral) in browser' (54 chars) omits WHEN to call it, what it returns, and when to prefer it over a server-side sentiment tool.

No documentation of client-side prerequisites or fallback behavior. For browser-based tools, document: Is the model pre-downloaded? Does it work offline? What happens if the browser does not support the API? What is the expected latency? This is crucial for agents making real-time decisions.