Bitbucket MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.7.4
Disambiguation3/5
Several tools have overlapping purposes, such as bb_get_diff vs bb_get_pull_request_diff, bb_get_diffstat vs bb_get_pull_request_diffstat, and bb_get_pr_commits vs bb_get_commits. While descriptions provide some clarity, an agent could easily select the wrong tool when looking for diff or commit information.
Naming Consistency4/5
The naming follows a consistent 'bb_verb_noun' pattern, with plural nouns for list operations and singular for single items. However, there is inconsistency in abbreviation: 'pr' is used in some tools (bb_get_pr_commits) while 'pull_request' is fully written out in others (bb_get_pull_request), creating minor confusion.
Tool Count2/5
With 38 tools, the server far exceeds the 25-tool threshold, making the set feel bloated. Many tools are highly specific read operations (e.g., bb_get_merge_base, bb_get_comment_thread), which may overwhelm agents and increase selection difficulty.
Completeness2/5
The tool set is entirely read-only, with no create, update, delete, or comment operations for repositories, pull requests, or issues. This is a significant gap for a Bitbucket MCP server, as agents cannot perform common workflows like creating PRs, commenting on code, or managing issues.
Average 3.5/5 across 38 of 38 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on May 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the basic action without addressing pagination behavior, rate limits, authentication needs, or response structure, leaving the agent with significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded, but it is under-specified. It omits potentially useful context that could be added without significant verbosity, missing the opportunity to be both brief and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description should provide more contextual completeness. It fails to explain pagination behavior, the difference between branches and tags, or what the response contains, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are fully described in the schema (100% coverage), providing clear semantics for workspace, repo_slug, pagination, filtering, and output format. The description adds no extra parameter context, but the schema alone meets the baseline requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb and resource ('Get branches for a repository'), accurately stating the tool's purpose. However, it lacks distinguishing details that would set it apart from sibling tools like bb_get_branch, though the name 'branches' already provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as bb_get_branch for a single branch or bb_get_tags for tags. There is no mention of prerequisites, typical use cases, or conditions that would favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get information', implying a read-only operation but does not describe response structure, authentication requirements, or any side effects. The behavioral contract is underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It is not verbose, yet it lacks the detail needed to fully inform the agent, making it minimally acceptable rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what information is returned. It only says 'information' without detailing fields or format. Given the many sibling tools, this lack of specificity reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents all three parameters. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('workspace'), making it distinct from sibling tools focused on other entities like repositories or users. However, it is vague about what specific workspace information is returned (e.g., name, UUID, permissions), so it lacks full specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not state use cases, prerequisites, or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of behavioral disclosure. It merely restates the tool's name with minimal added context, offering no details about return value structure, authentication requirements, rate limits, or potential errors. It is not misleading, but it adds little beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does. There is no redundancy or unnecessary detail, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description is expected to explain what the response contains. It only says 'information about the currently authenticated user,' which is vague and does not specify the user object fields, response format defaults, or how the filter/output_format parameters affect the result. This leaves an agent guessing about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for both parameters (`filter` with JMESPath examples and `output_format` with enum meanings), achieving 100% schema description coverage. The tool description itself adds no parameter information, but the high schema coverage makes this acceptable per the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get information about the currently authenticated user.' It clearly indicates the tool retrieves the current user's data, with the qualifier 'currently authenticated' distinguishing it from sibling `bb_get_user`. However, it does not explicitly name or reference alternatives, so it falls short of the highest bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `bb_get_user` or `bb_get_workspace`. There are no prerequisites, exclusions, or context about typical usage. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, default result limits, ordering, authentication requirements, or rate limits. It also does not state whether it returns all issues or requires filters. The minimal text leaves the agent guessing about important behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. It contains no filler or redundant information, and the key information is front-loaded. This is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema or annotations, the description provides no context about filtering options, pagination, or output formats. The schema covers parameters, but the description fails to explain the tool's behavior, return values, or when to use filters. This is a significant gap for a potentially complex list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all eight parameters have descriptions in the schema. The tool description itself adds no parameter semantics beyond the schema. According to the rubric, a baseline of 3 is appropriate when schema coverage is high, and the descriptions for parameters like 'filter', 'state', and 'kind' are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get issues for a repository' clearly identifies the action (get) and resource (issues for a repository). It distinguishes from similar sibling tools like bb_get_issue (singular, for one issue) and bb_get_pull_requests (different resource). It could be slightly more specific (e.g., 'List issues') but is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that bb_get_issue is for a single issue, nor does it explain any prerequisites or context where this tool is appropriate. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but says nothing beyond the basic operation. It does not mention authentication needs, potential errors, rate limits, or what 'detailed information' entails. The return format and any data transformations are left to the schema, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. While it is minimal, it effectively states the core purpose. It could be slightly more informative without losing conciseness, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, three required, and no output schema or annotations, the description is too sparse. It does not explain return values, how 'filter' or 'output_format' alter behavior, or what data the user can expect. A tool of this complexity needs more context to support correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter details beyond the schema, but the schema already documents all five parameters with descriptions, enums, and defaults, so the parameter semantics are adequately covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed information about a specific pull request.' The verb 'get' and the singular resource 'specific pull request' distinguish it from sibling tools like bb_get_pull_requests (list) and bb_get_pull_request_comments (comments on a PR).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a pull_request_id), exclusions, or preferred contexts. The word 'specific' implies use for a single PR, but this is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It does not mention pagination, ordering, response shape, or any side effects. While it is clearly a read operation, the lack of behavioral detail (e.g., paginated by default, possibly large result set) leaves the agent to infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point. However, it is minimal to the point of under-specification, but that is more a completeness issue than a conciseness issue. It earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 params, no annotations, no output schema), the description is too minimal. It does not mention pagination, filtering, or the relationship to sibling tools like bb_get_pull_request_comment. The schema covers parameter semantics but not overall behavior, leaving the agent without sufficient context to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 7 parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides. It does not explain how parameters like 'filter' or 'page' affect the call, but the schema covers them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'comments for a specific pull request'. It distinguishes from sibling tools such as bb_get_pull_request (which fetches the pull request itself) and bb_get_pull_request_comment (which may fetch a single comment). The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tool bb_get_pull_request_comment is ambiguous, and the description does not clarify that this tool returns all comments or how it differs from a single-comment fetch. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It implies a read operation but fails to mention any specifics like required permissions, error behavior for nonexistent repositories, or whether results are paginated. This is a minimal disclosure for a tool that may have significant side effects or limitations unknown to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. Every word contributes to stating the tool's purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 'get details' tool with no output schema and moderate parameter complexity, the description is minimally viable but leaves gaps. It does not clarify what fields of the repository are returned, how the filter and output_format interact with the response, or whether this tool is appropriate for large repositories. The agent would need to infer these details from the schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (workspace, repo_slug, filter, output_format) already have detailed descriptions. The tool description adds no additional meaning about parameters, so it correctly stays at the baseline of 3, relying on the schema to carry the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('repository'), with 'specific' indicating this tool targets a single repository rather than listing many. This distinguishes it from sibling tools like bb_list_repositories, though it lacks detail about what 'detailed information' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as bb_browse_repository or bb_list_repositories. There is no mention of exclusions, prerequisites, or contextual cues, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only says 'Get commits' without revealing that the tool returns a paginated list, defaults to the main branch, supports filtering and output formats, or any other behavioral traits. The description is too sparse to inform the agent about side effects, response characteristics, or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'Get commits for a repository branch,' which is extremely concise and front-loaded. There is no wasted wording or repetition of schema information, making it appropriately sized for a minimal-purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is inadequate. It does not mention pagination behavior, default branch handling, response format options, or any other contextual details needed for correct invocation. The rich schema offsets some gaps but the description itself remains incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter (page, branch, filter, pagelen, repo_slug, workspace, output_format) having a clear description. The tool description itself adds no parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get commits for a repository branch' clearly specifies the action (get), the resource (commits), and the scope (repository branch). This differentiates it from sibling tools like bb_get_pr_commits (PR-specific), bb_get_commit (single commit), and bb_get_file_history (file history). The purpose is unambiguous and effectively names the primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it lists commit history on a branch, nor does it point to bb_get_pr_commits for pull request commits or bb_get_commit for a single commit. There is no exclusionary or contextual information to help the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation is a 'get' but does not mention return format, pagination behavior, or authentication requirements. This is insufficient for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, nine words, front-loaded with the action verb, and contains zero wasted words. It is concise and appropriately sized for a straightforward GET-like tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and touches on pagination and output format parameters, the description is too brief to be complete. It does not explain what the response looks like or what 'CI/CD build statuses' includes. The agent must rely entirely on the schema and API knowledge, making it inadequate for a tool with 7 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The description adds minimal semantic value beyond the schema, only clarifying the general purpose (statuses for a commit) but not elaborating on how parameters interact (e.g., pagination).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('CI/CD build statuses'), and the scope ('for a specific commit'). This distinguishes it from sibling tools like bb_get_commit (commit details) and bb_get_pr_statuses (PR statuses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparative context with sibling tools like bb_get_pr_statuses or bb_get_pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description doesn't state what data is returned, error behavior, rate limits, or whether it modifies anything. 'Detailed information' is vague and doesn't disclose the actual response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded with the action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse to be fully actionable. It doesn't explain what 'detailed information' includes, how to handle missing issues, or how the output_format parameter affects the response. The tool's simplicity mitigates this somewhat, but the lack of supplementary detail leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, documenting workspace, repo_slug, issue_id, filter, and output_format. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific issue' uses a specific verb (Get) and resource (specific issue), clearly distinguishing it from sibling bb_get_issues which lists issues. However, it doesn't explicitly mention Bitbucket issues or contrast with any sibling, leaving slight room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: call this when you need details on one issue versus listing issues with bb_get_issues. But there is no explicit 'when to use' or 'when not to use', and no mention of alternatives or prerequisites like requiring an issue ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description does not disclose any behavioral traits beyond the basic operation. It does not mention pagination limits, state filtering, or response format, which are relevant for a list endpoint. The description adds no safety/permission context, so the agent is left without insight into the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose and is appropriately concise for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters including filter and output_format, and no output schema is present, the one-line description is insufficient. It does not explain the rich filtering/transformation capabilities or the pagination and formatting options available, making it under-specified for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description itself adds no parameter-level meaning, but per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get pull requests for a repository' clearly states the action (get) and resource (pull requests) with a repository scope. It distinguishes from sibling bb_get_pull_request (singular) by using the plural form, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as bb_get_pull_request or bb_get_pull_request_comments. No context, exclusions, or recommended scenarios are offered, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the basic function and does not disclose pagination behavior, default page size, whether all repositories are returned, or any potential limitations. This is a significant gap for a tool with no other behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. Every word contributes to meaning, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, and the presence of several sibling tools, the description is too sparse. It does not explain what the response contains, how pagination works, or how this tool differs from bb_search_repositories. A more complete description would include default pagination info and cross-references to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters (100% coverage), so the description does not need to add parameter details. The description itself adds no semantics beyond the schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (repositories), and the scope (in a workspace). It distinguishes from sibling tools like bb_search_repositories (which implies a query) and bb_get_repository (single repository).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as bb_search_repositories or bb_browse_repository. There is no mention of exclusions, prerequisites, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that it returns text/plain diff output, but does not mention that the output_format parameter can return JSON or Toon, nor any other behaviors like authentication, rate limits, or side effects. The description is minimal and somewhat inconsistent with the schema's output_format options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the action and return type. Every word contributes to understanding the tool's core function, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description is adequate but has gaps. It mentions the default text/plain return, but does not mention the alternative output formats (json, toon) or the filtering/context parameters. Relying on the schema for parameter details, but missing the output format flexibility makes it less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description itself does not add parameter semantics beyond what the schema provides; it does not explain the path, context, filter, or output_format parameters. The schema already covers these details, so the description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('raw unified diff for a pull request'), clearly distinguishing it from sibling tools like bb_get_pull_request_diffstat (which returns stats) and bb_get_diff (generic diff). It also states the return type ('text/plain diff output').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like bb_get_pull_request or bb_get_diff. It does not mention any exclusions or conditions, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that only public information is returned and that private profiles may have limited fields, which is useful context. However, it omits other behavioral aspects like authentication requirements, return format, or error handling, leaving gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and includes the fallback and caveat without any fluff. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool, the core purpose and a key caveat are covered, but given the existence of sibling bb_get_current_user, the description lacks guidance on when to use which tool. With no output schema and no annotations, the description also does not mention return value structure or authentication expectations, leaving the agent partially uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description text adds little beyond what the schema already explains—'by username or UUID' is redundant with the selected_user parameter description. It does not clarify the filter or output_format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves public Bitbucket user information by username or UUID, satisfying the verb+resource requirement. It does not explicitly differentiate from the sibling bb_get_current_user, despite both being able to return the authenticated user, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that omitting the user returns the authenticated user, but it never explicitly tells when to use this tool over the sibling bb_get_current_user. No alternatives or exclusions are provided, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions pagination support and does not describe what the response looks like, how pagination works, error behavior, or any side effects. This is insufficient for a file-content retrieval tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. Every word adds value, and it directly communicates the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich schema descriptions, the tool has 8 parameters, no annotations, and no output schema. The one-sentence description does not explain the return format, pagination semantics, or how filter and output_format affect results. This is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description (e.g., limit, start, filter, output_format). The description adds little beyond the phrase 'pagination support', so it does not improve on the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the content of a file from a repository', clearly identifying the tool's core function. It also mentions pagination support, which adds useful distinguishing detail. This tool is distinct from siblings like bb_get_file_history or bb_browse_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('get the content of a file') and hints at large-file scenarios via 'pagination support', but it does not explicitly state alternatives or exclusions. There is no mention of when to prefer bb_get_file_history, bb_get_diff, or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not explicitly confirm read-only behavior, mention error conditions, permissions, or response format details. The content note about target commit and merge strategies adds some context but does not address behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It front-loads the action and resource, and every word contributes to the meaning. This is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description gives a basic sense of purpose and some content details, but it doesn't cover potential response shape, usage examples, or limitations. For a simple read-only get, it's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters—it doesn't elaborate on how parameters like 'name' or 'filter' should be used. It merely references the branch subject, which is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'Get detailed information about a specific branch' and further specifies the scope with 'including target commit and merge strategies'. This clearly distinguishes it from sibling tools like bb_get_branches (which lists branches) by emphasizing 'specific branch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving details of a single branch, but it does not explicitly contrast with alternatives such as bb_get_branches or provide when-not-to-use guidance. There is no mention of exclusions or alternative tools, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function without addressing return structure, error handling, authentication, or read-only nature. The 'Get' verb weakly implies non-mutation but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource getter with a well-described schema, the description is minimally sufficient but lacks output structure or behavioral context. Since there is no output schema and no annotations, the description could be more complete about what 'detailed information' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all five parameters described in the schema. The tool description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'detailed information about a specific pipeline run', clearly distinguishing it from sibling tools like bb_list_pipelines and bb_get_pipeline_steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The word 'specific' implies single-run retrieval, but no alternatives are named or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the purpose without detailing behavior such as pagination, ordering, error handling, or permission requirements. The reader learns nothing about how the tool behaves beyond the literal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately conveys the action and subject. There is no extraneous information or redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only listing tool, and the schema covers all parameters. However, there is no output schema and the description does not mention return value shape, pagination behavior, or sorting, which leaves some uncertainty about what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no parameter-specific meaning. The baseline of 3 is appropriate since the schema already thoroughly documents each parameter, and the description does not introduce any additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('List'), the resource ('commits'), and the scope ('belong to a pull request'). This distinguishes it from sibling tools like bb_get_commits (repo-wide commits) and bb_get_pull_request (PR metadata), making the tool's purpose immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving PR-related commits, but does not explicitly mention alternatives or conditions when this tool should be preferred over similar siblings. No exclusions or when-not-to-use guidance is provided, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the high-level outcome ('checks whether builds pass or fail') and does not mention pagination behavior, result shape, error conditions, or how `output_format` and `filter` affect the response. This leaves the agent under-informed about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant text. The parenthetical 'checks whether builds pass or fail' adds valuable clarification without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only lookup but is not rich. With 7 parameters, no output schema, and no annotations, it would benefit from mentioning pagination or the return format. However, the 100% schema description coverage reduces the need for the description to repeat parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3. The description adds little parameter-specific meaning beyond identifying the target as a pull request, but the schema already documents each parameter clearly, so no significant gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the target resource ('pull request'), and the specific domain ('CI/CD build statuses') while clarifying the output's meaning ('checks whether builds pass or fail'). This distinguishes it from sibling tools like bb_get_commit_statuses (statuses for a commit) and bb_get_pull_request (PR metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a pull request' implies when this tool should be used, but there is no explicit guidance contrasting it with alternatives like bb_get_commit_statuses or stating when not to use it. Usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states what information is returned (reviews, approvals, comments) but does not mention pagination behavior, response format, ordering, or clearly state that it is a read-only operation. This is a minimal disclosure, not a transparent behavioral specification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key categories of activity. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, but the schema itself documents all parameters and the output_format parameter covers response style. The description gives enough to select the tool, yet it omits any guidance on pagination, filtering, or what the response structure looks like, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema; the parenthetical about activity types relates to the endpoint's purpose, not to specific parameters like page, pagelen, or filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('activity for a specific pull request'), and immediately clarifies what counts as activity ('reviews, approvals, comments'). This clearly distinguishes it from sibling tools like bb_get_pull_request_comments or bb_get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need activity for a specific pull request, not a list of pull requests. However, it does not explicitly state when to prefer this over sibling tools such as bb_get_pull_request_comments, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get a single comment' with no information about error handling, response shape, authentication needs, or rate limits. For a read tool, this is minimal but lacks non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is immediately front-loaded with the core action and resource, earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters, but the description does not explain return values (no output schema exists) or how it differs from the plural variant. It is adequate for a obvious get-by-ID operation but leaves some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (every parameter has a description), so the baseline is 3. The tool description adds no parameter-specific meaning beyond the schema, but it is not required to compensate since the schema is fully descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a single comment by ID from a pull request'), clearly distinguishing it from sibling tools like bb_get_pull_request_comments (plural) and bb_get_comment_thread. It fully states what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the wording ('by ID') but there is no explicit mention of when to use this tool versus alternatives like the plural list tool. No exclusions or alternative suggestions are provided, so the agent must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that the tool 'shows build status, trigger, and duration' but does not mention that the operation is read-only, that results are paginated, or any other behavioral traits like default limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the main purpose and then add a brief detail about the output. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter list tool with no output schema, the description provides the core purpose and some output fields, but it omits important context such as pagination behavior, default page size, and whether all runs are returned. The schema covers parameters, but the description is not fully self-sufficient for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, including page, pagelen, and filter. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'CI/CD pipeline runs', clearly scoped to 'a repository'. This distinguishes it from sibling tools like bb_get_pipeline (which retrieves a single pipeline) and bb_get_pipeline_steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when listing pipeline runs, but it does not explicitly state when to use it over alternatives like bb_get_pipeline or mention any exclusions. No alternative tools are referenced, so guidance is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention key details like whether the listing is recursive, pagination behavior, default limits, or what kinds of items are returned. The one-line description offers minimal insight into the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that clearly states the tool's purpose without redundancy. It is concise and front-loaded, containing no filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description is too sparse. It does not explain the return value, whether the listing includes nested items, or how the 'path' and 'limit' parameters affect results. The schema covers parameters but not the behavior expected, leaving significant gaps for an agent trying to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the baseline is 3. The tool description adds no parameter details itself, but the schema already documents parameters like 'path', 'limit', and 'filter'. Thus, the description does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'browse' with a clear resource ('files and directories in a repository') and states the purpose ('explore structure'). It distinguishes itself from sibling tools like bb_get_file_content, which retrieves file content, by emphasizing structural exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'explore structure' gives clear context that this tool is for browsing directory layouts, not for fetching file contents. However, it does not explicitly mention alternatives or when-not-to-use scenarios, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses the core behavior (retrieving a thread with root and nested replies) but omits any mention of side effects, required permissions, pagination, or error handling. The 'get' verb implies a read-only operation, but explicit caveats are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the verb and resource, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with well-documented parameters, the description is adequate. It explains the scope of the returned data. However, the absence of an output schema and any usage boundaries means the description doesn't fully explain the response structure or integration with related tools, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters already have detailed descriptions. The tool description itself adds no additional parameter semantics, which is acceptable given the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting a comment thread including the root comment and all nested replies. This specific verb+resource combination distinguishes it from sibling tools like bb_get_pull_request_comments or bb_get_pull_request_comment, which handle bulk or single comments respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It doesn't mention alternatives, exclusions, or scenarios where a different tool would be more appropriate. The agent is left to infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly implies a read-only operation via 'Get' and discloses some return fields (hash, message, author, parents), but it does not elaborate on authentication, rate limits, or other behavioral aspects. For a simple getter, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and resource, with the parenthetical adding relevant details. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but the description mentions key return fields. It does not explain the optional filter/output_format parameters or error behavior, but the schema covers those. For a simple single-commit getter, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all 5 parameters including allowed values for commit (hash, branch, tag) and output_format. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get detailed information about a specific commit' and lists key fields (hash, message, author, parents). This clearly distinguishes it from sibling tools like bb_get_commits (list) and bb_get_commit_statuses (statuses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific commit' implies it is used for fetching a single commit's details, as opposed to bb_get_commits for listing. However, there is no explicit mention of when to use this tool vs alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states purpose and a use case, but does not disclose output format, size limits, authentication needs, failure behavior, or whether the log is raw text or structured. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main purpose is front-loaded, and the second sentence adds a practical use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what the return value looks like or how the output_format parameter affects it. The schema covers all six parameters well, but the description remains thin on response semantics and operational behavior. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific detail beyond what is already in the schema. The phrase 'for a specific pipeline step' echoes the step_uuid parameter but does not add new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource: 'build log output for a specific pipeline step.' This distinguishes it from siblings like bb_get_pipeline_steps, which lists steps rather than logs. The connection to diagnosing build failures adds practical clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful for diagnosing build failures' provides a clear when-to-use context. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only discloses the core action. The verb 'List' implies a read-only operation, yet no mention is made of pagination, filtering, output formats, permissions, or rate limits. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action and resource efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters including pagination and filtering, but the description gives only the basic purpose. The schema is rich, but without annotations, the description alone is insufficient to fully understand the tool's capabilities. For a simple list operation, this is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no additional parameter semantics, merely restating the repository context that is already captured by the required parameters (workspace, repo_slug).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('tags') for a repository, using the plural 'tags' to distinguish from the singular sibling tool bb_get_tag. It is specific and unambiguous, though the parenthetical 'release tags, version tags' adds slight clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a list of repository tags but provides no explicit guidance on when to use this tool versus alternatives such as bb_get_tag. There are no exclusions or contextual cues beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and spec format, but does not disclose read-only status, pagination behavior, error handling, or the nature of the output beyond 'raw unified diff'. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, immediately states the core function, and provides essential spec examples without unnecessary filler. Excellent structure and front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a rich schema covering 9 parameters and all descriptions, the description focuses effectively on the key spec parameter. It does not cover the filter, topic, or output_format options, but these are well-documented in the schema, so the description is adequate for the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the 9 parameters, so the description adds little beyond repeating the spec semantics already present. The description's mention of spec usage mirrors the schema's description, thus the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the raw unified diff between commits' with a specific verb, resource, and output format. It distinguishes itself from sibling tools like bb_get_pull_request_diff by focusing on commit-to-commit comparisons, and the spec syntax is explicitly clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions for the spec parameter: single commit hash for parent diff, or 'commit1..commit2' for comparing two commits. While it doesn't name alternative tools, the context for when to use this tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals that the tool returns a per-file summary, which is behavioral. However, it does not disclose potential behaviors like how a single commit diffs against its parent, the meaning of the 'topic' flag, or any side effects. The 'Get' verb implies a read operation, but additional context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the tool's purpose and key usage. Every word adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, all documented in the schema. While the description is brief, it gives a clear one-liner of the tool's purpose and the core spec format. The lack of an output schema is mitigated by the description's 'per-file change summary' hint, which sets expectations. However, subtle features like the 'topic' flag's 3-dot diff behavior are left to the schema, which is acceptable given the schema's richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 8 parameters, including the exact semantics of 'spec', 'topic', and 'filter'. The description briefly reinforces the spec syntax but adds no new meaning beyond the schema. Per the baseline for high schema coverage, this scores a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a per-file change summary (diffstat) between commits. It uses a specific verb ('Get') and resource, distinguishing it from PR-specific diffstat tools like bb_get_pull_request_diffstat by scoping it to commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs how to specify commits ('Use a single commit hash or "commit1..commit2"'), which is a guideline for the spec parameter. However, it does not explicitly contrast with sibling tools like bb_get_diff or state when to prefer this tool over alternatives. The 'between commits' phrasing implies context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only mentions the output content ('shows which commits modified the file and when') but does not disclose potential pagination, ordering, permissions, or error behavior. This adds minimal value beyond what the schema already indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It contains no filler or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read tool with no output schema, the description covers the core purpose and return value. The schema adequately documents parameters, including pagination options. Missing explicit mention of pagination or result ordering is a minor gap, but not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 8 parameters, so a baseline score of 3 is appropriate. The description does not add parameter-level details, but it doesn't need to since the schema already explains each field clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Get the commit history for a specific file' and explains what it shows ('which commits modified the file and when'). This distinguishes it from sibling tools like bb_get_commits and bb_get_file_content by specifying the resource (file history) and scope (a specific file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when a user needs commit history for a specific file. However, it does not explicitly mention alternatives or when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation is a 'Get' (implying read-only) and reveals that the response includes the target commit, but it does not disclose error behavior, authentication requirements, rate limits, or response format. For a tool with zero annotation coverage, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that is front-loaded with the action and resource. It contains no filler or redundant phrasing, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and notes that the response includes target commit info, which is useful given the lack of an output schema. It is slightly thin on what 'detailed information' entails, but given the tool's simplicity and the rich schema, it is largely complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter (name, workspace, repo_slug, filter, output_format) having its own description. The tool description adds no parameter-specific insight beyond what the schema already documents, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('detailed information about a specific tag') plus a distinguishing detail ('including its target commit'). This clearly differentiates it from sibling tools like bb_get_tags (which lists tags) and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: retrieving details for a single tag by name. Context is clear, but it does not explicitly mention alternatives or exclusions (e.g., 'Use bb_get_tags to list tags'). This is borderline between 3 and 4; the clarity of the resource makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that it searches across all repositories (not just the first page) and supports sorting, but does not mention read-only nature, authentication, or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, and every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and no output schema, the description covers the core behavior (search, all repositories, sorting) and relies on the schema for pagination and filtering details. It could mention the response format but is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides for all seven parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search for' with a clear resource ('repositories within a workspace') and modifiers ('by name or description'), clearly distinguishing it from listing or code search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding repositories by name/description and mentions server-side filtering across all repositories, but it does not explicitly name alternatives or state when not to use this tool versus list or code search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the core output (steps with status and duration) but does not mention pagination, filtering, authentication, or other behavioral traits. The schema provides parameter details, but the description adds limited behavioral context beyond the obvious list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and key output fields. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values more explicitly. It states the tool lists steps with status and duration, which gives a basic expectation, but it doesn't describe the response structure (e.g., array of objects) or pagination behavior. Given the simplicity of the tool and rich schema, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides; it only renames the pipeline_uuid concept implicitly. Parameters like page, pagelen, filter, and output_format are well-documented in the schema, so no further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('steps/stages of a pipeline run'), and the specific data returned ('with their status and duration'). This distinguishes it from sibling tools like bb_get_pipeline (which fetches pipeline details) and bb_get_pipeline_step_log (which retrieves logs for a specific step).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you have a pipeline_uuid and need to see the steps of that run. However, there is no explicit mention of alternatives or when-not-to-use, such as distinguishing from bb_get_pipeline_step_log, but the purpose is sufficiently distinct that a user can infer the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the read-only nature ('Get') but does not disclose edge cases, required permissions, or response details. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and immediately followed by the key usage detail. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and all parameters are well-documented in the schema. The description conveys purpose and a critical usage format. However, without an output schema, it does not explain the response format, though this is acceptable for a read-only get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description's format note ('branch1..branch2') is redundant with the revspec schema description, adding no new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('common ancestor (merge-base)'). It uniquely identifies this as distinct from sibling tools, which focus on other repository objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (retrieving merge-bases) and gives a specific format instruction ('branch1..branch2'). It does not explicitly mention alternatives or exclusions, but the unique resource and sibling list make usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately conveys that this is a read-only operation returning a per-file summary, which is the core behavior. However, it does not explicitly state the lack of side effects, how the file list is ordered, or whether all files are included or only changed ones. The description is adequate but not detailed enough to fully anticipate edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action ('Get the diffstat') and provides only essential details about the output. It is concise without being under-specified, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must hint at what the response contains; it does this by specifying 'per-file summary of lines added/removed and change status.' Given the tool's moderate complexity (6 params, no output schema) and read-only nature, the description covers the essential return structure and operation. It could mention filtering via parameters, but that is already in the schema, so the description is sufficiently complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all six parameters, each clearly documented. The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies. No extra context like default behavior or parameter interactions is offered in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's function: 'Get the diffstat for a pull request' and enriches it with a per-file summary of lines added/removed and change status, which clearly distinguishes it from sibling tools like bb_get_pull_request_diff (full diff) and bb_get_pull_request (PR metadata). The verb 'Get' plus resource 'diffstat' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate usage context: when you need aggregated, per-file change statistics for a pull request rather than the full diff or detailed PR info. No explicit alternatives are named, but the phrasing provides situational clarity without misleading the agent. Missing explicit exclusion of when *not* to use it, but the stated purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the tool lists 'accessible' workspaces, implying a read-only operation and access constraints. However, it does not describe pagination behavior, authentication requirements, or that no modifications occur, leaving some gaps for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action ('List all accessible workspaces') followed by a short purpose clause. Every word contributes, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and well-documented parameters, the description is adequate. It covers the core functionality and purpose. It could be slightly more complete by mentioning the return format or that results are paginated, but the schema already covers pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 4 parameters (page, filter, pagelen, output_format). The description adds no extra meaning beyond the schema, so it meets the baseline without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List'), resource ('workspaces'), and scope ('all accessible'). This distinguishes it from sibling tools like bb_get_workspace (singular) and other list tools (bb_list_repositories, bb_list_pipelines).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for discovery and exploration' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions (e.g., 'use bb_get_workspace for a single workspace'), so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It conveys the core search behavior and filter capabilities but does not disclose pagination behavior, output defaults, or any potential side effects. For a search tool, this is adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 9 parameters, the description captures the essential function and primary filters. Pagination and output_format are documented in the schema, so their absence is not a gap. The lack of an output schema means return values are not explained, but that is not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters. The description's mention of filters (repo, language, extension) mirrors existing schema descriptions and adds no new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines a specific action ('search') on a specific resource ('code content within a workspace') and mentions key filtering dimensions (repository, language, file extension), which distinguishes it from sibling tools like bb_search_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for using this tool is clear: it is for searching code content. However, it does not explicitly mention when not to use it or point to alternatives like bb_search_repositories, which would be helpful but is not strictly necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the bundle contents, the effect of detail_level, and the accepted input forms. While it doesn't cover auth or rate limits, it provides essential behavioral context for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, front-loading the core purpose and then providing concise guidance on inputs and detail_level. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use cases, input forms, and verbosity control. Given no output schema, it does not detail the response structure, but the high-level contents list suffices. Slight gap: output_format options are left to the schema, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by synthesizing parameters into usage patterns (URL or workspace/repo with id/branch) and specifying what detail_level 'full' returns beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a curated bundle of PR context in a single call' and lists exactly what's included (PR metadata, diffstat summary, build/review status, comment previews). This distinguishes it from sibling tools that fetch individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when you need a consolidated PR context bundle in one call. It also explains alternative input patterns (URL vs workspace/repo + id/branch) and suggests using 'full' detail level for richer output. However, it does not explicitly name sibling alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bitbucket-mcp MCP server](https://glama.ai/mcp/servers/tugudush/bitbucket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tugudush/bitbucket-mcp)

Score Badge

Copy to your README.md:

[![bitbucket-mcp MCP server](https://glama.ai/mcp/servers/tugudush/bitbucket-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tugudush/bitbucket-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tugudush/bitbucket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server