bitbucket-standalone-mcp

by jabdon00

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools map to a clear resource+action (repositories, branches, pull requests, files, commits), and the bb_ prefix plus descriptive names help separate them. The main ambiguities are bb_get_file vs bb_raw_file, which both read file content, and the several diff tools, but their parameter scopes and descriptions are usually enough to disambiguate.
Naming Consistency4/5
All tools share a consistent bb_ prefix and overwhelmingly follow a verb_noun pattern such as list_repositories, create_pull_request, and delete_file. Minor deviations like bb_raw_file, bb_application_properties, and bb_detect_repo break the pattern slightly but remain understandable.
Tool Count2/5
41 tools is well into the heavy range for a single MCP server, and the count is inflated by overlapping file readers, multiple diff variants, and a nonfunctional bb_search_code tool. While each tool is individually scoped, the surface is larger than an agent needs for most workflows.
Completeness4/5
The tool set covers the core developer lifecycle well: project/repo listing, branches, full pull request management with comments, diffs, commits, file read/write, build statuses, and local repo detection. Notable gaps such as repository/project update/delete, tags, and code search are present but do not block the primary Bitbucket workflows.
Average 3.8/5 across 41 of 41 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 provided, so the description carries the full burden of behavioral disclosure. It reveals only that confirmation is returned ('Returns confirmation') and implies destruction via the verb 'Delete', but it does not state whether deletion is permanent, whether replies are cascade-deleted, what permissions are required, or whether the action is reversible. For a destructive operation with zero annotation coverage, this is a meaningful gap.
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 two short sentences with zero wasted words, and the action verb is front-loaded. It is lean and easy to parse, though arguably terse to the point of under-specification. On purely structural grounds it scores well for efficiency.
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 is structurally simple (four flat scalar parameters, no nesting), but it is destructive, has no annotations, no output schema, and 0% schema description coverage. The description leaves the agent unaware of side effects, permissions, and how this operation compares to bb_update_comment or bb_resolve_comment. 'Returns confirmation' is the only nod to output behavior, which is insufficient for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the four parameters. The parameter names themselves (projectKey, repoSlug, prId, commentId) are reasonably self-explanatory for a Bitburger context, which prevents a total failure, but the description contributes nothing to parameter understanding and does not compensate for the absent schema descriptions.
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 specific verb ('Delete') and a specific resource ('a comment'), so an agent immediately knows what operation is being exposed. The verb itself distinguishes it from the comment-related siblings like bb_update_comment and bb_resolve_comment, since none of those perform deletion. However, it does not explicitly call out that distinction or clarify which comment is targeted, relying on the parameter names to convey scope.
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 delete a comment versus when to update or resolve it. Given siblings like bb_update_comment and bb_resolve_comment operate on the same resource, an agent gets no decision support for choosing among them. There is no mention of prerequisites, exclusions, or a preferred alternative.
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 behavioral burden, but it only states the return value ('Returns the merged PR') and an open-state precondition. It does not disclose side effects of merging, permission requirements, reversibility, or consequences for the source branch.
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 compact, front-loads the action, and every clause adds information: the OPEN precondition, the strategy options with default, and the return value.
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?
Without an output schema or annotations, the minimal return description and strategy list are insufficient for a 6-parameter mutation. Missing details include which strategy requires squashedCommitMessage, what the merged PR response contains, and any auth/state-change caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents version, strategy, and squashedCommitMessage; the description adds default meaning for noFF and mentions a custom variant string, but that custom variant conflicts with the enum's closed value list. It also omits several enum values and leaves projectKey/repoSlug/id to be inferred.
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?
Description opens with 'Merge an OPEN PR' — a specific verb and resource with a state precondition. It clearly distinguishes itself from sibling decline/approve/update pull-request tools.
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?
There is no explicit guidance on when to use this tool over alternatives such as bb_decline_pull_request or bb_update_pull_request, nor when to choose one merge strategy over another. The only hint is the 'OPEN PR' precondition.
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 the mutation ('Edit the text') and the return value ('Returns the updated comment'), but it does not discuss reversibility, permissions, side effects, or whether the edit can fail under certain conditions.
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 wasted words. It front-loads the core action and adds a useful return-value note, with every clause contributing meaningful information.
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 five required parameters, no output schema, and no annotations, yet the description explains almost none of the identifier semantics or invocation context. An agent cannot fully determine how to construct a valid request beyond guessing from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with 'text' being the only described parameter. The description reiterates that 'text' is edited but provides no explanatory value for projectKey, repoSlug, prId, or commentId, leaving the agent to infer their roles from names alone.
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 'Edit' and identifies the resource ('existing comment') and the target attribute ('text'). It clearly distinguishes this from sibling tools that create, delete, resolve, or list comments.
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_create_pull_request_comment, bb_delete_comment, or bb_resolve_comment. It does not mention exclusions, prerequisites, or conditions that would make this the correct choice.
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 full behavioral burden. It adds a meaningful idempotency note—re-approving is a no-op—and indicates an authenticated user context. But it doesn't disclose mutation consequences, required permissions, error/edge-case behavior, or the outcome beyond the approval.
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 core action and the key idempotency caveat are front-loaded.
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 mutation with three required params and no annotations/output schema, the description is thinner than ideal. It doesn't state what a successful approval returns, whether prior decline/merge changes behavior, or any permission/error conditions, so an agent may be uncertain about call outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
None of the three required parameters (projectKey, repoSlug, id) are described in the schema, and the description doesn't explain that id refers to the pull request ID or how the values combine to locate the PR. The parameter names are reasonably self-explanatory, so this isn't a complete failure, but the tool provides no added semantics.
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 specific action ('Approve a PR') on a clear resource and identifies the acting principal ('as the authenticated user'). Although it doesn't explicitly name sibling tools, the approve action is clearly distinct from unapprove/decline/merge siblings, so the purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the intended use: when the authenticated user wants to approve a pull request. However, it gives no explicit guidance on when to choose this tool instead of bb_unapprove_pull_request, bb_decline_pull_request, or bb_merge_pull_request, and no caveats about PR state.
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 present, so the description carries the full burden of behavioral disclosure. It notes that only the authenticated user's approval is removed, which is useful, but it does not disclose side effects, idempotency, reversibility, or permission 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 a single, front-loaded sentence with no filler. Every word contributes to the meaning, and it is appropriately sized for a simple operation.
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 tool with three obvious parameters and no output schema, the description is minimally viable. However, it lacks usage context, parameter semantics, and behavioral detail, leaving the agent to infer some important aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters, but it does not. The parameter names (projectKey, repoSlug, id) are somewhat self-explanatory, yet the description does not clarify that 'id' refers to the pull request ID.
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 states a specific verb ('remove') and resource ('the authenticated user's approval from a PR'), making the tool's function unmistakable. It also clearly differentiates from siblings such as bb_approve_pull_request and bb_decline_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 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, nor any exclusions or conditions. There is no mention of prerequisites like having previously approved the PR or needing certain permissions.
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 of behavioral disclosure. It adds an important behavioral trait: resolving a parent resolves the entire thread. However, it does not mention idempotence, reversibility, permissions, or what happens when a child is resolved directly.
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?
Two short sentences with no filler. The core action is stated first, and the most important edge behavior is added in the second sentence. 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?
For a simple 4-required-parameter mutation tool, the description conveys the core action and the key thread-resolving behavior. It is minimally adequate but lacks usage guidance, result/return expectations, and any elaboration of the required object identifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds parent-child semantics to commentId via the thread note, but gives no meaning for projectKey, repoSlug, or prId. The parameter names are self-explanatory, but the description does little beyond 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 ('Mark') and resource ('a comment as resolved'), which clearly distinguishes this from siblings like bb_update_comment, bb_delete_comment, and bb_create_pull_request_comment. The 'resolved' action is immediate 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?
The description does not state when to use this tool versus alternatives such as updating or deleting a comment, nor does it mention preconditions like the comment needing to be open. The parent-thread note is behavioral, not selection guidance.
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 behavioral burden. It clearly states the core mutation, but it does not disclose permission requirements, behavior when the branch already exists, whether the operation is idempotent, or what the response looks like. This is a significant gap for a write 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?
One sentence with no filler; the essential verb, object, and source qualifier are front-loaded. Every word contributes.
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 create-branch operation, the required parameters are all present and the core behavior is clear, but with no annotations and no output schema the description leaves out error conditions, default-branch nuance, and response shape. It is minimally viable but not fully 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?
The description ties 'given start point' to the optional start parameter and 'new branch' to branch, but this largely repeats the schema's existing descriptions. It adds no explanation for the undocumented projectKey and repoSlug parameters, so it only partly compensates for the 50% 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?
States a specific verb ('Create') and resource ('new branch') plus the start point, so an agent can identify it as the branch-creation tool and distinguish it from bb_list_branches, bb_get_branch, and bb_delete_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 action 'Create' implies the appropriate use case, and the start-point qualifier provides context, but the description does not explicitly state when to prefer it over related operations or mention prerequisites such as repository write access. The guidance 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?
With no annotations, the description carries the full burden, but it reveals only the return value and the inline/plain distinction. It does not disclose side effects, strict legacy validation of 'text', review-policy filtering of severity, or behavior when replying via parentCommentId—critical traits for a mutation tool.
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 three short sentences with the main purpose front-loaded and no filler. It loses a point because the inline-citation sentence introduces an inaccurate parameter name, which makes the concise phrasing less reliable.
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?
This is an 18-parameter mutation tool with no annotations and no output schema, yet the description only covers basic inline vs text comments. It omits the structured-finding variant, reply flow, anchor diff/file/type options, and the strict validation on free-form text, so an agent cannot confidently invoke all supported behaviors from this description alone.
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 83%, so the schema does most of the parameter documentation; the description adds useful grouping (inline vs plain text) but refers to a non-existent property, 'anchoredTo', where the schema actually defines 'anchoredToFile'. That naming mismatch offsets the added value, keeping this at the baseline.
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 opens with a specific verb+resource, 'Add a comment on a PR,' which unambiguously identifies the create operation and distinguishes it from sibling update/delete/list/resolve comment tools. The closing 'Returns the created comment' confirms the operation's purpose and expected result.
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?
It gives clear usage context by separating the two main modes: inline comments require an anchor (file path + line + lineType) while plain text goes in 'text'. It does not explicitly name alternatives or say when-not-to-use, but 'Add' is sufficiently distinct from the update/delete/approve siblings.
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 discloses the key behavioral trait (cardinality: one parent normally, two for merges), which is genuinely useful. However, it does not mention behavior for root commits, missing commits, or the response shape.
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?
A single front-loaded sentence with no filler. Every word earns its place, and the useful cardinality note is included 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?
For a simple read-only getter, the description is minimally sufficient and the cardinality insight helps. But with no output schema, no annotations, and no parameter descriptions, there are notable gaps around return format and how commitId is identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. Only commitId is vaguely implied by 'a commit'; projectKey and repoSlug are left entirely unexplained, so an agent has no guidance on how to fill two of three required 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 a specific verb ('Get') and a precise resource ('parent commits of a commit'), which clearly separates it from sibling tools like bb_get_commit and bb_list_commits. The parenthetical cardinality note adds precision.
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 — whenever parent commits are needed — but it never explicitly contrasts it with alternatives or states when not to use it. An agent must infer the selection criteria from the phrasing and sibling names.
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 burden of explaining behavior. It discloses that content is returned as-is, which is useful, but it does not mention error cases, size limits, encoding, or side-effect status beyond the implied read-only nature.
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?
Two short sentences, each earning its place: the first states the action/resource, the second clarifies the return behavior. No filler 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 description is adequate for a simple file-read tool and covers the return shape, but it lacks guidance on sibling-tool routing and does not compensate for the undocumented projectKey/repoSlug parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description adds little beyond repeating the concepts of 'file' and 'ref'. It does not clarify projectKey or repoSlug, leaving two required parameters effectively undocumented.
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?
States a specific action ('Read'), a specific resource ('file at a ref'), and clarifies scope ('full content'). The added 'text content as-is' distinguishes it from metadata or diff 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 the tool is for retrieving raw file content and explicitly notes there is no wrapping, which gives some context. However, it does not mention alternatives such as bb_raw_file or bb_get_file_metadata, nor does it 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, 'Get' communicates a read-only operation and the listed response fields give some output behavior. However, the description does not disclose error conditions, required permissions, or other API-specific behaviors, leaving some burden unmet.
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 names the action and lists the key returned fields without unnecessary words. It is appropriately sized for a simple GET tool.
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 read-only GET with three required parameters, the description gives a reasonable sense of the result contents. However, with no annotations, no output schema, and incomplete parameter descriptions, it lacks guidance on parameter meaning and edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: only 'id' has an example description while projectKey and repoSlug are undocumented. The description itself adds no parameter-level meaning, so it does not compensate for the low 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 uses a specific verb ('Get') and a specific resource ('a single PR'), and enumerates the returned fields: state, branches, author, reviewers, participants, version, and web link. This clearly distinguishes it from list_pull_requests and PR mutation 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 phrase 'single PR' implies the tool is for retrieving one specific pull request rather than listing or modifying PRs, but it does not explicitly name alternatives or state when not to use it. The intended use is inferable but not directly stated.
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 makes the read-only nature clear via 'Get' and lists return fields, but it does not mention authentication requirements, error behavior, or that an invalid project key causes a 404 (though that is noted in the schema parameter description). The description is adequate but not richly transparent.
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 tightly worded sentence that front-loads the core purpose ('Get full details for a single repository') and then delivers value by enumerating the returned fields. There is no wasted or duplicated 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 simple 2-parameter read operation with fully documented schema properties, the description covers the purpose and return content without an output schema. The main gap is the absence of usage guidance relative to sibling lookup tools, but nothing critical is missing for a straightforward get 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%, with detailed descriptions for both projectKey and repoSlug, including exact casing rules and example values. The tool description adds no additional parameter meaning beyond the schema, 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 uses a specific verb ('Get') and resource ('full details for a single repository'), then enumerates the exact information returned: project key, slug, name, state, default branch, fork source, clone URLs, and web link. This clearly distinguishes it from list/search siblings, which operate on multiple repositories.
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 implies usage when full details for a known single repository are needed, but it gives no explicit guidance on when to use this tool versus alternatives such as bb_search_repositories, bb_detect_repo, or bb_list_repositories. No when-not-to-use conditions or prerequisites are stated.
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 behavioral disclosure burden. It usefully discloses that binary files are base64-encoded and that output is plain text. But it does not mention error behavior, encoding nuances, or what happens for large files or missing refs, leaving some behavioral gaps.
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 with no filler. The core action and return type are front-loaded, and the base64 note appears immediately afterward. 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?
Given no output schema, the description covers the main return behavior (plain text, base64 for binary) and the use case (reading files). It does not discuss error handling or the relationship to sibling read-type tools, but for a simple raw-file fetch the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: repoSlug and projectKey have no descriptions. The description mentions 'at a ref' and 'file', aligning with existing descriptions for 'at' and 'path', but adds no meaning for the two undocumented required parameters. Since coverage is moderate and the description does not compensate, the score is below 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 ('Fetch the raw bytes of a file at a ref') and states the return format ('plain text', with binary base64-encoded). It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like bb_get_file or bb_get_file_metadata, so it does not earn a 5.
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 instruction 'Use this to read files' provides clear when-to-use context. However, there is no mention of when not to use it or how it relates to alternatives such as bb_get_file or bb_get_file_metadata, so it stops short of explicit alternative routing.
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 behavioral disclosure burden. It does add useful semantics: omitted fields are left unchanged, and the updated PR is returned. However, it does not disclose permission requirements, reviewer replacement semantics, or any side effects beyond the update itself.
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, front-loaded sentence with no filler. Every phrase adds meaning: what is updated, the omitted-field behavior, and the return value.
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 relatively simple partial-update operation, the description covers purpose, patch semantics, and return value. However, with no output schema and no annotations, more detail about reviewer add/remove behavior and required identifiers would improve completeness. The schema partially fills these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description needs to compensate for under-documented parameters. It names 'title/description/reviewers' but does not explicitly map to reviewerAdd/reviewerRemove, and it does not explain the required identifier parameters (projectKey, repoSlug, id) or their role in addressing the PR. The partial-update note is helpful but insufficient.
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 ('Update'), names the resource ('a PR'), and enumerates the exact aspects being updated (title/description/reviewers). This clearly distinguishes it from sibling tools like create, merge, decline, approve, or list pull requests.
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 rather than explicit: 'Update title/description/reviewers of a PR' suggests modifying an existing PR versus creating or merging it. However, the description does not explicitly state when to prefer this tool over alternatives or when not to use it.
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 behavioral burden. It usefully discloses accepted commit identifier forms (full SHA, short SHA, HEAD) and mention of relevant PRs is helpful. However, it does not cover error behavior, authentication needs, or read-only guarantees, leaving some transparency gaps.
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?
Two sentences, front-loaded with the primary purpose and return fields. It is efficient, but the second sentence introduces a misleading parameter name ('slug' instead of 'commitId'), slightly reducing clarity.
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 explains the return fields and accepted commit identifier forms, but with no annotations and no output schema it is not fully complete. It omits any guidance about the meaning of projectKey/repoSlug and does not address failure cases or sibling-tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only commitId is described). The description adds little for commitId because the schema already says 'Commit SHA (full or short) or HEAD', and it confusingly refers to 'slug' rather than the actual parameter name commitId. projectKey and repoSlug remain semantically undocumented.
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 ('details for a single commit') and enumerates exact return fields: message, author, date, parents, and relevant PRs. This clearly distinguishes it from list-oriented siblings like bb_list_commits.
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 a single commit' establishes clear usage context and implies this is not for listing commits or retrieving diffs. It does not explicitly name alternatives or exclusion conditions, but the single-commit scope is strong enough for an agent to select it appropriately.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly indicates this is a read-only 'Get' operation and discloses the output shape: per-file status, +N/−N counts, and first hunk. It does not mention rate limits or auth, but for a simple read tool the behavior is sufficiently transparent.
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 tightly written sentence that front-loads the operation and then lists the exact output fields. Every word earns its place; there is 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?
For a simple three-parameter read tool, the description is largely complete: it identifies the target resource and the key parts of the return value. The absence of an output schema is mitigated by the explicit field list, though a brief note distinguishing this tool from bb_get_diff_summary would make it fully unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-level detail. The parameter names are self-explanatory (projectKey, repoSlug, prId), and the PR focus of the description relates to prId, but the description does not compensate for the missing schema 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 names a specific verb and resource: it gets a per-file summary of a pull request's changes, and lists the exact contents (status, +N/−N counts, first hunk). This clearly differentiates it from sibling tools like bb_get_pull_request_diff (full diff) 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as bb_get_diff_summary or bb_get_pull_request_diff. The word 'summary' implies a use case, but no exclusions or sibling comparisons are provided, leaving the agent to infer routing.
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 behavioral transparency burden. It does disclose important traits: it returns a list, supports server-level or project-scoped listing, includes specific item fields, and is paginated. However, it does not describe the response envelope, default pagination behavior, or any error/auth requirements, which is a noticeable 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?
Two tight sentences deliver the core behavior, scope options, item contents, and pagination. There is no filler or repetition, and the most important scoping information is front-loaded.
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 list tool with 4 parameters and no output schema, the description gives a reasonable overview but omits details an agent needs for robust invocation: pagination parameter semantics, default limits, response structure, and how the filter interacts with server-level vs project-scoped listing. It is adequate but not fully 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 50%, and the description adds only modest value: it restates the projectKey scoping concept ('no filter' vs 'scoped to one project') and mentions pagination generally. The limit and start parameters remain undocumented in both schema and description, and the filter parameter's meaning is only fully explained in the schema. The description partially compensates but does not close the gaps.
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 names the verb (List), the resource (GIT repositories), and the two scopes (all server-level or one project). It also lists the returned per-item fields, making the tool's purpose concrete. It does not explicitly contrast with siblings like bb_search_repositories or bb_get_repository, so it stops short of a 5.
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: use no filter for server-wide listing or provide a project scope. It does not explicitly state when not to use this tool or when to prefer bb_search_repositories or bb_get_repository, but the scope guidance is strong enough for an agent to decide basic usage.
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 burden of behavioral disclosure. It adds the return behavior (created PR with id) and notes that reviewer is optional, but it does not mention permissions, branch-existence requirements, or error behavior. This is adequate but not rich.
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 with the primary operation front-loaded and no wasted words. Every sentence adds useful information.
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 seven-parameter mutation with no annotations and no output schema, the description gives the essential operation and return value but leaves some parameter roles and failure conditions implicit. The self-explanatory parameter names mitigate the gaps, so it is minimally viable rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description should compensate, but it does not explain projectKey, repoSlug, title, or description. It adds reviewer optionality and source/destination branch roles, but these largely duplicate existing schema 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 states a specific verb and resource: creating a new pull request from a source branch to a destination branch. This clearly differentiates the tool from sibling PR operations like update, merge, decline, and approve.
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?
It clearly signals the use case: creating a new PR, which distinguishes it from tools that modify or act on existing PRs. It does not explicitly name alternatives or state when not to use it, but the 'new PR' wording gives clear context.
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 provided, the description carries the full burden and does a good job: it discloses the non-obvious reconstruction mechanism (walking /commits/<sha>/diff along branch lineage), the exclusive/inclusive bounds of from/until, and the preview truncation to ~400 chars. It does not mention potential failures or auth requirements, but the disclosed behavior is substantial.
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 dense sentences with no filler. It front-loads the core purpose, then adds default behavior, reconstruction mechanics, and output format—each sentence earns its place without unnecessary elaboration.
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?
Since there is no output schema, the description appropriately explains the shape of each entry. It covers defaults, semantics, and reconstruction. It could mention ordering or error cases, but for a read-only diff summary the provided information is largely sufficient for an agent to 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?
Schema coverage is 50%, with from and until already described in the schema. The description reinforces the semantic relationship (from is base/exclusive, until is head/inclusive, defaults to default branch) and adds the lineage walking detail, but it adds nothing for projectKey and repoSlug, which remain undocumented in both schema and description. The description partially compensates but not fully.
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 gets a per-file summary of a diff between two refs, identifying the specific resource and verb. It also lists the output structure (path, status, +N/−N counts, preview), which distinguishes it from full-diff siblings like bb_get_diff.
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?
There is no explicit guidance on when to use this tool versus alternatives such as bb_get_diff, bb_get_commit_diff, or bb_get_pull_request_diff_summary. The description implies usage by framing it as a per-file summary, but it never states conditions or points to sibling tools.
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 behavioral disclosure burden. It conveys a read-only metadata operation and hints at behavior through 'existence checks,' but it does not explain behavior for nonexistent files, revision semantics, authentication needs, or error cases. Adequate but not rich.
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?
Two sentences with no filler. The first sentence front-loads the core action and return fields; the second adds practical use cases. 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?
No output schema exists, so the description usefully names the three returned metadata fields and gives use cases. But it omits the meaning of the 'at' parameter and any invocation context for the repository identifiers, making it only partially complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all four parameters. It does not explain projectKey, repoSlug, path, or at, nor their formats or relationships. Only the word 'file' vaguely implies what path refers to, leaving the required parameters largely undocumented.
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?
States a specific verb and resource: 'Get metadata about a file' and enumerates exact returned fields (name, parent directory, last-touching commit). This clearly differentiates it from content-returning siblings like bb_get_file and bb_raw_file, and its 'existence checks and audit trails' purpose further distinguishes it.
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?
Explicitly says 'Use for existence checks and audit trails,' giving clear context for when to select this tool. However, it does not name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
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 full burden of behavioral disclosure. It communicates the key behavioral trait: the tool returns one large unified diff text covering all changed files. This is meaningful context beyond the tool name, though it does not mention read-only guarantees or error 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?
A single, focused sentence with a clarifying parenthetical. Every word earns its place, and the key output characteristic is front-loaded.
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 read operation the description is mostly sufficient: it states exactly what is returned. However, without annotations or an output schema, and with limited parameter documentation, an agent gets no guidance on parameter semantics or how this differs from closely related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only prId having a description. The description adds little to the meaning of projectKey or repoSlug and does not compensate for the low schema coverage, beyond broadly referencing 'a PR'.
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 states a specific verb ('Get'), a precise resource ('full unified diff for a PR'), and clarifies the output as 'all changed files as one large diff text'. This clearly distinguishes the tool from summary or individual-file diff siblings like bb_get_pull_request_diff_summary and bb_get_diff.
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 use case: when you need the complete unified diff of a pull request. However, it does not explicitly say when to prefer this tool over alternatives such as bb_get_diff or bb_get_pull_request_diff_summary, leaving the agent to infer the boundary.
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 behavioral burden. It explains the data source and the fields returned, which is useful. However, it does not disclose pagination, ordering, error behavior, or any read-only guarantees beyond the verb 'list', which is a moderate 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?
Two tight sentences with no filler. The core purpose is front-loaded, and the return field details are presented compactly. Every sentence adds value.
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 adequately sketches the return shape ('key, state..., and URL'), which is helpful since there is no output schema. However, it is incomplete regarding parameter semantics and behavioral details like pagination, and it does not say what happens when no builds exist or the commit is not found. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate for the undocumented repoSlug and projectKey parameters. It only reinforces that commitId corresponds to 'a commit', which the schema already states as 'Commit SHA'. No additional parameter meaning is provided.
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 ('List') and a specific resource ('build statuses for a commit'), and even names the data source ('CI providers reporting to Bitbucket'). This clearly distinguishes it from siblings like bb_get_commit or bb_list_commits, which serve different purposes.
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: use this when you need CI build statuses for a specific commit, identified by the required commitId. It does not explicitly name alternatives or exclusions, but no sibling tool covers build statuses, so the usage context is sufficiently 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 full burden of behavioral disclosure. It does add useful specifics: OPEN is the default state, results are paginated, and projectKey is case-sensitive and must be uppercase. However, it does not disclose the return shape, pagination parameter semantics, or API limitations beyond what the schema already mentions.
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?
Two sentences with no filler: purpose, filters, pagination, and a critical case-sensitivity warning are all included in a compact, front-loaded structure. Every sentence 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 an 8-parameter tool with no output schema and no annotations, the description covers the essential call-time facts: what it lists, available filters, default state, pagination, and the key projectKey case constraint. It is slightly incomplete because start/limit semantics are not explained and the returned PR object shape is not indicated, but the core invocation is well supported.
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 already documents 6 of 8 parameters, so the description does not need to repeat them. It adds a pagination mention and reinforces the uppercase projectKey rule, but it does not explain start/limit or add substantial meaning to the filters beyond the schema. This aligns with a baseline 3 given strong 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 opens with a specific action and resource: 'List pull requests in a repository,' and then names the available filters (state, author, reviewer, text match). This clearly identifies the tool's function and distinguishes it from sibling tools like bb_get_pull_request or bb_merge_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 communicates clear context: this is for listing/searching PRs with filters and pagination. However, it never explicitly tells the agent when to prefer this over bb_get_pull_request for a single PR, or provides exclusions/alternatives. Usage is implied rather than explicitly routed.
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 discloses a useful non-obvious behavior: refusal to delete the default branch. However, it does not mention the destructive/permanent nature of branch deletion beyond the verb 'Delete', nor any permission or error 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 filler. Every phrase adds value, especially the refusal warning.
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 3-parameter delete operation, the description conveys the core action, target resource, and the main edge case (default branch). Minor gaps remain around return or error behavior, but the tool is simple enough that this is not a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'branch' has a description), and the description adds little detail about repoSlug or projectKey beyond the phrase 'from a repository'. Given the low coverage, the description should compensate but does not explain parameter formats or relationships.
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 ('Delete') and resource ('a branch from a repository'), and adds a distinguishing constraint ('Refuses to delete the default branch'). This clearly separates it from sibling tools like bb_list_branches, bb_get_branch, or bb_create_branch.
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?
It states a clear context for use (deleting a branch) and an explicit exclusion (default branch). While it does not name alternatives like bb_create_branch, the refusal warning gives practical guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'Get' indicates a read-only operation with no side effects, and the description discloses the specific data fields included in the response. It does not cover error behavior or auth requirements, but for a simple fetch operation this is reasonably transparent.
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, information-dense sentence with no wasted words. It front-loads the core action ('Get details for one branch') and then lists the specific return fields, making it easy to parse quickly.
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 get operation with no output schema, the description adequately communicates the tool's purpose and the data returned. However, it lacks any mention of possible error conditions (e.g., branch not found) or how 'relation to default branch' is expressed, which would make it more complete. Given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'branch' documented in the schema. The description reiterates 'one branch' but provides no meaning for projectKey or repoSlug, and does not explain how the parameters relate to the resource beyond the schema already does. With low coverage, the description should compensate but fails to do so.
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') with a clear resource ('details for one branch') and enumerates exactly what is returned: name, latest commit id and author, relation to default branch. This clearly distinguishes it from sibling tools like bb_list_branches, bb_create_branch, and bb_delete_branch without needing to open schemas.
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 'one branch' implies this is for fetching details about a single branch rather than listing branches, but it does not explicitly name alternatives or state when not to use this tool. Usage context is clear but left to inference, with no explicit routing to bb_list_branches or other siblings.
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 discloses the core behavior: a read-only operation returning the raw diff relative to the commit's parent. However, it does not mention behavior for merge commits, root commits, response format, or error conditions.
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?
A single, focused sentence that front-loads the verb and object, with a parenthetical clarifying the diff scope. No filler or redundant 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?
exit
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; only commitId is documented. The description adds no parameter-level information for projectKey or repoSlug, and while their names are somewhat self-explanatory, the description does not compensate for the missing schema documentation.
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 states a specific verb ('Get'), a precise resource ('raw diff introduced by a single commit'), and clarifies the semantics with 'changes the commit makes relative to its parent'. This clearly distinguishes the tool from sibling diff tools like bb_get_diff or bb_get_pull_request_diff.
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: use this when you need the diff from a specific commit, not a pull request or a summary. It does not explicitly name alternative tools or state when not to use them, but the 'single commit' framing is enough to guide selection.
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 provided, the description carries the full behavioral burden. It discloses the sort order, per-commit fields, default-branch behavior, and pagination, which gives an agent a clear sense of what to expect. It does not cover edge cases like invalid branch names, but the disclosed traits are substantive.
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 concise sentences front-load the core operation, then specify return fields, default behavior, and pagination. Every sentence adds information and there is no redundant 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?
For a moderately simple list operation, the description covers purpose, output shape, ordering, default branch, and pagination. The main gap is the missing semantics for the pagination parameters, which an agent needs for precise invocation. Overall it is nearly complete for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate, but it only clarifies the 'branch' default and mentions 'Paginated'. It does not explain the semantics of 'start' and 'limit', nor the required 'projectKey' and 'repoSlug' fields. The pagination claim hints at those parameters but leaves their behavior ambiguous.
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 ('List commits on a branch') and adds a meaningful ordering detail ('newest-to-oldest'). It clearly differentiates from sibling tools like bb_get_commit (single commit) and bb_list_branches (branches), so an agent can distinguish it without opening schemas.
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 by describing the operation and noting that 'branch' defaults to the default branch. However, it gives no explicit guidance about when to choose this tool over alternatives such as bb_get_commit or when to avoid it. The context is present but not explicit.
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 provided, the description carries full behavioral burden. It clearly discloses that this tool will not work on this Bitbucket Server (v7.12.1) and directs the agent away. It doesn't describe would-be success/error behavior, but that is largely moot because the endpoint is disabled.
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?
One compact sentence states unavailability, the server version, and the replacement tools. No filler or repetition; the most important warning is front-loaded.
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 disabled endpoint, the description tells an agent everything needed to avoid a doomed call and pick alternatives. It could be more complete by briefly noting what code search would have done and why get_file/list_directory are substitutes, but the guidance is still actionable.
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 description adds no parameter-level meaning, but the input schema already documents most parameters (text, path, repo, project, branch, since, start) with high coverage. Since the tool is disabled, parameter details are secondary; the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a code-search endpoint but does not explicitly state its intended action (searching code content) with a verb and resource; instead it mainly says the endpoint is disabled. It conveys enough for a rough idea but doesn't differentiate it from related 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent not to use this tool ('Not available', 'endpoint is disabled') and names concrete alternatives ('use get_file / list_directory instead'). This is exactly the when-not/alternative guidance needed for a disabled 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?
There are no annotations, so the description carries the full burden. It discloses that this is a read-only search and what fields are returned, but it omits behavioral details like case-insensitive matching, pagination behavior, or what happens when projectKey is omitted versus provided.
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?
Two short sentences with no filler. The core purpose is front-loaded, and the return shape is summarized efficiently.
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 read-only search tool the description is adequate, but it lacks pagination guidance, explicit alternative routing, and any behavior beyond the basic search/return statement. With no annotations and no output schema, it leaves the agent to infer some call semantics.
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 description adds meaning by tying the text parameter to name/description matching and by noting searches span the whole server. However, limit and start have no schema descriptions, and the description does not explain their pagination semantics, leaving a partial gap.
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 begins with a specific verb (Search) and a specific resource (repositories), plus the matching criteria (name/description). It clearly differentiates from siblings like bb_list_repositories and bb_search_code by emphasizing server-wide repository search.
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 makes the intended context clear: use this to find repositories by name/description, not to list all repositories or search code. However, it does not explicitly state when not to use it or mention alternatives such as bb_search_code.
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 must disclose behavior. It states that it creates a file, allows an optional commit message, and returns the commit id and file path. However, it does not explain what happens if the file already exists (overwrite vs. error) or whether parent directories are created. This is a meaningful gap for a mutation 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?
Two efficient sentences. The core action and parameters are front-loaded, followed by the optional parameter and return value. No wasted words.
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 six-parameter tool with no output schema, the description provides the key return value (commit id and file path) and the default commit message. It is missing conflict/overwrite behavior, which is important for a create operation, but overall the description covers the essential information an agent needs to invoke it.
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 67%, and the schema already explains path, branch, content, and message. The description adds the commit message default value and the return values but does not clarify repoSlug or projectKey, which are undocumented in both schema and description. Overall it adds modest value beyond 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 has a specific verb and resource: 'Create a new file' at a path on a branch. It clearly differentiates itself from siblings like bb_update_file and bb_delete_file by stating it creates, not updates or deletes.
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 its use case: creating a new file. It does not explicitly name alternatives or exclude existing files, but 'New' in the first sentence provides clear context. No explicit when-not-to-use guidance, but the intent is unambiguous.
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 provided, the description carries the full burden and does well: it discloses the state change (closes without merging), the precondition (OPEN), and the return value (declined PR). It does not mention permissions or reversibility, but the core behavioral outcome is transparent.
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?
Two short sentences, each with a distinct job: define the action/effect and state the return value. No filler or redundant phrasing.
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 three-parameter action the behavioral description is adequate, but with no annotations, no output schema, and no parameter descriptions, the agent must infer several details from names and sibling tools. It is sufficient but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define projectKey, repoSlug, or id beyond implying that id identifies an OPEN PR. This gives minimal semantic help but leaves the meaning of the repository-scoping parameters to inference from names.
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 (Decline) with a clear resource (an OPEN PR) and explicitly distinguishes the outcome from merging by saying 'closes it without merging.' This separates it from sibling tools like bb_merge_pull_request and bb_update_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly scopes the operation to OPEN pull requests and contrasts it with merging, giving an agent enough context to know when this tool is appropriate. It does not explicitly name alternative tools or state when not to use it, so it stops 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the operation creates a commit and that the commit message defaults to 'Delete <path>', providing useful side-effect and message behavior. It could add permission or irreversibility details, but what it provides is meaningful.
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?
Two short sentences, action first and default message second. No filler; every clause 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 5-parameter flat delete call with no annotations or output schema, the description covers the core behavior and commit-message semantics. It is slightly incomplete in not addressing permissions or alternative tools, but an agent can correctly select and invoke it using schema names plus 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 description coverage is 0%, so the description must compensate. It connects 'branch' to the branch parameter and 'Delete <path>' to path, and the default-message phrasing implies the optional message parameter. However, projectKey and repoSlug are left entirely to name inference.
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?
States a specific verb 'Remove' with resource 'file' and target 'branch', and notes the commit side effect. It is clearly distinct from sibling tools like bb_delete_branch and bb_delete_comment.
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?
Implies when to use it: to delete a file in a branch with a commit. However, it does not explicitly say when not to use it or name alternatives such as bb_update_file, leaving exclusion to inference.
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 provided, the description carries the full behavioral burden and delivers substantively: it discloses non-recursive scope ('immediate'), the default branch behavior, and the per-item return shape (name, type, path) — genuinely valuable given there is no output schema. It omits pagination and error behavior for nonexistent paths, but the core behavioral traits an agent needs are explicit.
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?
Two sentences with no filler: the first front-loads the action and scope, the second delivers the return item shape — which earns its place precisely because no output schema exists. Every word contributes.
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 listing tool, the description covers the essentials: what is listed (immediate children), where (repo at a ref), and what comes back (name, type, path). Remaining gaps — pagination behavior and error handling for invalid paths — are minor for a first correct call, and the non-obvious root convention is already handled by the schema's path 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 description coverage is exactly 50%: `at` and `path` are well documented in the schema (ref type, empty-string root convention), while `projectKey` and `repoSlug` are bare. The description's prose ('in a repo', 'directory', 'given ref') maps loosely to all four parameters but does not compensate for the undocumented ones, and its ref wording largely echoes the schema. It adds return-shape information, not parameter semantics.
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 states a specific verb and resource: 'List immediate children of a directory in a repo at a given ref'. The phrase 'immediate children' sharply distinguishes it from sibling listing tools (bb_list_branches, bb_list_commits, bb_get_file) and clarifies this is a scoped, non-recursive directory listing. The return item format (name, type FILE/DIRECTORY, path) further disambiguates what a call produces.
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 through the ref semantics ('default branch or commit SHA') and the repo/directory framing, so an agent can infer this is for exploring directory structure. However, it never explicitly names alternatives (e.g., bb_get_file for single-file content, bb_search_code for content search) or states when not to use it, leaving sibling differentiation to inference.
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 usefully discloses per-branch output fields, the ahead/behind-default-branch comparison, the 'when available' caveat, and pagination. Auth and rate limits are not mentioned, but the read-only nature is clear.
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?
Two sentences with no filler: purpose is front-loaded, and the branch-content details plus pagination follow directly. Every sentence 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?
No output schema or annotations exist, so the description is the only contract. It gives the core return shape and notes pagination, but it omits pagination mechanics such as limit defaults, offset semantics, response envelope, and explicit parameter mappings. Adequate but not fully 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 only 20%, so the description needed to compensate. It maps 'repository' to projectKey/repoSlug and 'Paginated' hints at limit/start, but it does not explain limit/start semantics or the text filter in prose. The text property already has its own schema 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?
Uses a specific verb ('List') and resource ('branches in a repository'), and enumerates what is returned for each branch. This clearly distinguishes it from singular branch tools like bb_get_branch and from commit-listing siblings.
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 'List branches in a repository' gives clear usage context for enumerating branches. It does not explicitly name alternatives or exclusions, so it stops 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It reveals the output shape (id, text, author, state, anchored line/lineType, web link) and states that results are paginated. It does not cover ordering, filtering details, or auth requirements, but it is transparent about the core read 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 three sentences with no filler: verb and resource are front-loaded, then output fields and pagination are listed compactly. Every sentence adds value.
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 list tool with no output schema or annotations, it provides the return-field details and pagination behavior. The important path-filtering semantics are present in the schema description, which mitigates the gap, though the tool description itself could have repeated that requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description does not compensate. It adds only the generic hint 'Paginated' for limit/start, while omitting crucial guidance about the path parameter's required role and the meanings of other 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 opens with a specific verb 'List' and resource 'comments on a PR', and clarifies scope with 'including global and inline code comments'. This clearly distinguishes it from sibling comment mutation tools like create/update/delete/resolve comment.
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 a clear context for use: retrieving PR comments, including global and inline ones. It does not explicitly name alternatives or exclusions, but the stated purpose makes the appropriate use case unambiguous.
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 provided, the description carries the burden of behavioral disclosure. It goes beyond the basic 'create' by stating defaults: empty repo with initial 'master' branch, private visibility. It also notes the forkFrom behavior. It does not mention permissions or irreversibility, but the core behavioral traits are disclosed.
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 with no redundant language. It front-loads the main purpose and then adds key defaults and a conditional. Every word contributes information.
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 7-parameter creation tool with no output schema and no annotations, the description conveys the essential behavior and defaults while the schema handles parameter details. It could add a note about the interaction between forkFrom and emptyRepo, and what happens on success, but overall an agent has enough to call 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?
Schema coverage is high at 86%, so the description need not explain every parameter. It adds minor value by clarifying the default branch name ('master') and tying 'private' to isPublic. However, most parameter meaning is already captured in the input 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 states a specific verb and resource: 'Create a new repository under an existing project.' It clearly distinguishes from siblings like list, get, search, file, and branch operations. The defaults and fork option further define the tool's scope without ambiguity.
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?
It gives clear context by stating this is for creating a repository under an existing project, implying the prerequisite that a project already exists. It also explains the fork condition ('Set forkFrom to fork from another repo'). It does not explicitly name alternative tools, but the usage context is clear enough.
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 provided, the description carries the burden of disclosing behavior. It does so well: it says the full content is replaced, that a commit message can be supplied with a default, and that a new commit id is returned. It does not mention permissions or branch-existence requirements, but the core mutation behavior and return value are clear.
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 compact sentences with no filler. The primary action and target come first, followed by the optional parameter default and the return value. Every sentence contributes useful information.
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 six-parameter mutation with no output schema and no annotations, the description is largely complete: it states what is replaced, where, the default message, and the return value. It could be even more complete by explicitly routing new-file creation to bb_create_file or noting branch requirements, but nothing essential to invoking the tool is missing.
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 50%, and the description adds some meaning by explaining the message default and confirming the path is an existing file. However, it does not describe branch, repoSlug, or projectKey semantics beyond what their obvious names and the 'on branch' phrase suggest. This is minimally acceptable but not strong compensation for the schema gaps.
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 states a specific verb ('Replace the full content'), a specific resource ('an existing file'), and a target branch. The word 'existing' clearly distinguishes this from sibling bb_create_file, and 'Returns the new commit id' announces the outcome.
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 signals that this tool is for replacing existing files, implying it is not for creating new files. It does not explicitly name bb_create_file as the alternative or state exclusions, but the 'existing file' condition provides clear context for selection.
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 provided, the description carries the full behavioral burden. It discloses authentication scope ('visible to the authenticated user'), result content (project key, name, description, visibility, lock state), and pagination behavior. It does not mention ordering, rate limits, or API-side effects, but as a read-only list operation the disclosed traits are reasonably sufficient.
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 three short sentences, each earning its place: the action and scope, the returned fields, and pagination. It is front-loaded and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 required parameters and no output schema, the description covers purpose, access scope, returned fields, and pagination. The schema handles parameter details. Nothing essential for an agent to invoke it correctly is missing.
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 input schema already documents limit, start, and filter thoroughly, including filter examples. The description does not add parameter semantics beyond the schema, 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 uses a specific verb and resource: 'List Bitbucket Server projects visible to the authenticated user.' It also enumerates the returned fields (key, name, description, visibility, lock state), making the tool's purpose unmistakable and distinguishing it from repository-focused siblings.
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?
It clearly states this is for listing projects visible to the authenticated user, which provides context for when the tool applies. It does not explicitly contrast it with alternatives like bb_list_repositories or bb_search_repositories, so it lacks explicit when-not-to-use guidance, but the resource and scope are clear.
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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only and that modifications require admin, which tells an agent this is a safe, non-destructive call. It could also mention permission requirements or output shape, but the core safety profile is clear.
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 primary purpose and read-only nature are front-loaded, and the practical use case is stated in the second sentence.
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?
This is a simple, zero-parameter read tool with no output schema, and the description covers its purpose, safety, and a concrete use case. It could be slightly more complete by noting what the response generally contains, but for such a low-complexity tool the description is sufficient for an agent to invoke it correctly.
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?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds context about what the returned properties represent (application properties, server version), which is useful even though there is nothing to parameterize.
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 ('Read') and resource ('server-wide application properties'), clearly distinguishing it from the repository, branch, and pull-request tools in the sibling list. It also adds the key detail that this is a server-level operation, not a resource-specific one.
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 states when this tool is useful: confirming connectivity and server version. It does not explicitly list when not to use it or name alternatives, but the zero-parameter, server-wide scope is sufficiently distinct from all sibling tools that no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the git inspection process, the two-level child search fallback, the multi-result listing behavior, and the complete return shape. This is unusually transparent for a tool description.
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 compact and information-dense: it defines the primary behavior, the fallback behavior, the ambiguity case, and the return shape in two sentences. No filler or repetition of schema details.
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 is almost complete: it explains inputs, edge cases, and the returned object. The only notable gaps are the unspecified behavior when no git repo is found at all and the exact shape of the multi-candidate output, though the instruction to re-invoke mitigates this.
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 already documents the single `dir` parameter well, including relative/absolute paths and examples, so schema coverage is 100%. The description reinforces that it accepts a project folder but adds little parameter-specific meaning beyond what the schema already states.
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 names a specific action: given a folder, locate its .git directory, read the origin remote URL, and parse out project key and repo slug. This clearly differentiates it from the server-side Bitbucket sibling tools, which operate on remote repositories rather than local folders.
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 states when the tool searches children, how deep it searches, and what to do when multiple repos are found ('you must re-invoke with one of them'). It does not explicitly name alternatives or say when not to use it, but the intended use case is strongly implied by the behavior and return value.
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 provided, the description takes on the full transparency burden and does it well. It reveals that the diff is reconstructed by walking /commits/<sha>/diff along branch lineage from 'until' down to but not including 'from', and it documents the per-file output structure. It stops short of describing error behavior, authentication expectations, or performance implications of large diffs.
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?
Two dense, purposeful sentences with no filler. The primary action and scope come first, then the default behavior, then the reconstruction mechanics and return format. Every clause 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 tool with no annotations and no output schema, the description provides enough operational detail: required ref semantics, defaults, endpoint-walking behavior, and return contents. It could be more complete by explicitly contrasting with sibling diff endpoints or warning about non-linear history, but an agent can invoke it correctly from what is written.
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 50%: 'from' and 'until' have descriptions, while projectKey and repoSlug are self-evident from their names. The description adds meaningful semantics by saying 'from' is the exclusive base and 'until' is the inclusive head, and by stating the default for 'until'.
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?
States a specific verb and resource: 'Get the full diff between two refs (commit SHA or branch name).' It also clarifies the exclusive/inclusive semantics of the refs and describes the return shape, making it reliably distinguishable from sibling diff tools like bb_get_diff_summary or bb_get_pull_request_diff.
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 clear usage context by defining the tool as a ref-to-ref diff operation, with the 'until' default and the walk direction explicitly explained. It does not name alternatives or state exclusions, but the ref-based scope is concrete enough for an agent to decide when to invoke it.
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-standalone-mcp MCP server](https://glama.ai/mcp/servers/jabdon00/bitbucket-standalone-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jabdon00/bitbucket-standalone-mcp)

Score Badge

Copy to your README.md:

[![bitbucket-standalone-mcp MCP server](https://glama.ai/mcp/servers/jabdon00/bitbucket-standalone-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jabdon00/bitbucket-standalone-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/jabdon00/bitbucket-standalone-mcp'

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