Parameter descriptions are generic and do not explain constraints, formats, or use cases. Examples: 'Bitbucket workspace slug' (appears 32 times) provides no context about what a workspace slug is, valid format, length, or when to use it. 'Repository slug' and similar descriptions repeat without actionable guidance.

Output schemas are not documented in source code. No return type documentation visible for any of 32 tools. LLMs cannot plan downstream tool calls or extract required fields (e.g., workspace_id for follow-up queries) without knowing what each tool returns.

Incomplete parameter schemas for many tools. Examples: bitbucket_get_workspace_member only shows 'workspace' parameter but presumably requires 'member' identifier (username, email, or ID) which is not in the provided schema. bitbucket_search_workspace_accounts only shows 'workspace' but needs a 'query' or 'search_term' parameter. This pattern repeats across ~15 tools, making schemas appear incomplete or inferred rather than explicit.

No error handling documentation visible. No guidance on recovery strategies, error categorization, or actionable error messages. Destructive tools like bitbucket_delete_project and bitbucket_delete_repository have no confirmation or dry-run pattern documented.

No parameter constraints documented (enums, min/max bounds, format patterns). For example, bitbucket_create_project takes 'key' but provides no guidance on valid format (length, characters, case sensitivity). reviewers array in bitbucket_create_pull_request has no indication of max length or format of reviewer identifiers (username vs email).

List tools lack pagination documentation. bitbucket_list_workspaces, bitbucket_list_projects, bitbucket_list_repositories, and others do not expose limit, page, offset, or cursor parameters visible in schemas, yet likely return paginated results. LLMs cannot fetch large result sets or control page size.

Tool descriptions at tool level (not just parameters) are missing or not visible in provided code. The tool registration function shows only parameter names and descriptions but no top-level tool documentation explaining what each tool does, when to use it, or what it returns.

No distinction between human-friendly identifiers (usernames, emails, display names) and system IDs. Parameters like 'member', 'reviewer', 'parent_id' do not indicate accepted input format. Agents require explicit guidance: does create_pull_request accept 'reviewer' as a username, email, or internal ID?