Server has 20 tools with basic schemas and descriptions present for all tools. Naming follows verb-first convention (search_, recommend_, get_, set_, toggle_, navigate_, enter_, exit_, browse_, commit_, cancel_). However, descriptions are often generic or under-specified. Several critical gaps: (1) parameters lack type information in many cases (e.g., device_name parameter in get_device_info has no type constraint), (2) descriptions lack clarity on side effects and context (e.g., set_device_parameter doesn't explain which device, how to select it, or what param_index means), (3) output schemas are not documented anywhere in visible code, (4) error handling is absent, no guidance on recovery steps, (5) no tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY distinction in metadata, (6) parameter constraints are minimal (no enums where appropriate, e.g., direction in navigate_device uses enum but most parameters don't). Tool definitions are visible in source code (bitwig_mcp_server/mcp/tools.py), confirming registration. Per-tool analysis shows inconsistency: discovery tools (search_device_browser, recommend_devices) have reasonable descriptions (~100-150 chars), but control tools (set_tempo, set_track_volume) lack detail on acceptable ranges, units, and side effects.

• Add explicit output schemas to all tool definitions. For search_device_browser, return {results: [{name, category, type, creator, description}], total_count}. For set_tempo, return {success, new_bpm, previous_bpm}. Document what IDs/references downstream tools can consume.
• Annotate all write tools with destructiveHint=true and set idempotentHint accordingly. Add readOnlyHint=true to all GET/LIST/SEARCH tools. This enables agents to understand retry safety and side-effect scope.
• Add parameter constraints to numeric ranges: set_tempo bpm should have minimum=0, maximum=666 with description 'Tempo in beats per minute (0 - 666; Bitwig max)'. set_track_volume volume should clarify '0 - 128 (MIDI scale; 64 = 0dB)'. set_device_parameter value should explain the 0 - 128 mapping relative to the actual parameter range.
• Document device selection context. Add a tool like 'get_selected_device() → {name, index, category}' so agents know what device they're operating on. Alternatively, add a 'device_context' parameter to tools that need it, or describe in each tool's description how to ensure the right device is selected.
• Add recovery hints to parameter descriptions. Example: set_device_parameter, 'To find the parameter index, use get_device_info(device_name) first.' This guides multi-step workflows.
• Expand error descriptions. In get_device_info, add: 'Returns error if device not found. Ensure device name matches search results from search_device_browser exactly.'
• Add confirmation/dry-run for destructive operations. For set_tempo, offer a dry_run=true parameter: 'If true, return what the new tempo would be without applying it.'

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

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