Bitbucket MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions actions but doesn't describe permissions needed, rate limits, pagination behavior (beyond parameters), whether operations are read-only or mutative, or what the return values look like. The description adds minimal behavioral context beyond the action names.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a brief overview followed by a bulleted list of actions. Each bullet is clear and specific. No wasted words, though it could be slightly more front-loaded with the overall purpose before diving into actions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 12 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return formats, error conditions, authentication requirements, or how actions map to parameters. The complexity demands more contextual information than provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds value by explaining the action parameter options and giving examples for diff specs ('branch1..branch2'), but doesn't provide additional semantic context beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Manage Bitbucket commits and diffs' with specific actions listed (list, get, get_diff, get_diffstat). It distinguishes from siblings by focusing on commits/diffs rather than branches, issues, pipelines, etc. However, it doesn't explicitly differentiate from sibling tools in the description text itself, just by topic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the action list (list commits, get commit details, get diffs), but provides no explicit guidance on when to choose this tool over alternatives like bitbucket_pull_requests for diff-related tasks, or when to use specific actions. No prerequisites, exclusions, or sibling tool comparisons are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.