Four tools with complete schemas and descriptions. Tool names follow verb_noun pattern (bitbucket_get_*, bitbucket_code_search). Descriptions are substantive (100-250 chars), explaining WHAT and WHEN. All parameters have types and descriptions. However, descriptions lack dependency hints and recovery guidance. Output schemas are not explicitly documented. Error handling is minimal, no guidance on retryability or user-fixable vs fatal errors. Parameters accept string IDs without accepting human-friendly alternatives (e.g., file paths, branch names). No pagination guidance in code_search despite potentially large result sets.

• Document output schemas for all tools. Specify field names, types (string, integer, array, object), and what each field represents. Example: 'Returns array of {file_path: string, line_number: integer, code_snippet: string, repository: string}'.
• Add error handling guidance to each tool description. State: 'If search returns 0 results, verify the Lucene query syntax and that Bitbucket Search is enabled on the Data Center instance.' Include retryability classification.
• Accept human-friendly identifiers alongside IDs. E.g., bitbucket_get_commits should accept branch_name or commit_message_pattern in addition to commit_id. Resolve them to IDs inside the tool.
• Document pagination strategy for bitbucket_code_search. Clarify: 'Use start + limit for pagination. Response includes total_count. If total_count > start + limit, more results exist.'
• Add dependency hints to tool descriptions. E.g., 'To get a commit_id, call bitbucket_get_commits first with project_key and repository_slug.' This guides multi-step planning.

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

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