Banshee provides 17 tools with basic descriptions and some schema information, but lacks the depth and precision required for production-grade agent integration. Most tool descriptions are terse (10-50 chars, below the 194-char baseline) and lack actionable guidance. Parameter descriptions are minimal or absent. No input/output schemas are formally documented. Tool naming is generally acceptable but several tools combine multiple concerns or lack verb-noun clarity. The codebase shows this is primarily a daemon control system (start/restart/status) with voice I/O features (list_voices, preview_voice, download_models), but the tool definitions do not match Arcade's 54 patterns for error recovery, idempotency, composition, or LLM-optimized descriptions. Schemas are inferred from sparse function signatures; explicit JSON Schema registration is not visible in the provided source snippets.

• Expand every tool description to 100-250 chars, following the format: 'Does X [when Y]. Returns [fields]. Prerequisites: Z.' Example for status: 'Returns daemon status (running/stopped/error). Call this first to check connectivity before operations. Returns: {status: string, uptime_seconds: number, version: string}.'
• Document all parameters with type, constraints, and dependency hints. For set_setting, specify: 'key: string (e.g. "language", "voice_id", "noise_threshold"); value: object matching the schema for that key, see docs/settings.md for the full schema and validation rules.'
• Provide explicit JSON Schema output schemas for all tools. E.g., list_voices should return {voices: [{id: string, name: string, language: string, gender?: string}], total: number}.
• Split plan_connect and apply_connect into a single tool with a 'dry_run: boolean' parameter, or clearly document when to call each one. If they are distinct workflows, rename one to clarify intent (e.g., 'validate_connect' vs 'apply_connect').
• Add error handling and recovery guidance. For clear_history: 'Destructive operation. Consider export_history() first if you need a backup. On failure, returns {error: string, retry_after_seconds: number}. Retryable: true.'
• Mark destructive tools with explicit guidance. For each DESTRUCTIVE or WRITE tool, include: '⚠️ This operation is irreversible. Confirm with the user before calling.' Or add a confirmation_token workflow.
• Document which tools are idempotent (safe to retry). E.g., start_daemon is idempotent; calling twice is safe. clear_history is NOT idempotent, retrying after partial success loses data.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry