Bitbucket Cloud MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in the Bitbucket Cloud domain. For example, 'get_pull_request' retrieves details while 'approve_pull_request' performs an action, and tools like 'list_pr_comments' vs 'add_pr_comment' handle different aspects of PR comments without overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case throughout, such as 'create_branch', 'list_issues', 'update_pull_request'. There are no deviations in naming conventions, making the set highly predictable and readable.
Tool Count3/5
With 34 tools, the count is borderline high for a single server, potentially feeling heavy and overwhelming for agents. While it covers many Bitbucket Cloud operations, a more modular approach might improve usability without sacrificing functionality.
Completeness5/5
The tool surface provides comprehensive CRUD and lifecycle coverage for repositories, branches, commits, issues, pull requests, pipelines, and code search. It includes all essential operations like create, get, list, update, delete, and specific actions such as merge, approve, and trigger, with no obvious gaps for the domain.
Average 3/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 29, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Approve') but doesn't explain what happens after approval (e.g., does it trigger a merge, change status, require additional steps?), potential side effects, or any permissions or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This is an example of efficient communication where brevity aligns with clarity for the basic purpose stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of approving a pull request (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, error conditions, or how it fits with sibling tools. For a tool that likely changes state in a version control system, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three parameters (workspace, repo_slug, pr_id). The description adds no additional meaning beyond what the schema provides, such as format examples or contextual usage. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter semantics adequately.
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 states the action ('Approve') and resource ('a pull request'), which is clear but basic. It doesn't distinguish this tool from its sibling 'decline_pull_request' or 'merge_pull_request', which are related pull request actions. The purpose is understandable but lacks specificity about what 'approve' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'decline_pull_request', 'merge_pull_request', or 'request_changes'. The description doesn't mention prerequisites, such as needing review permissions or the pull request being in a mergeable state. It's a standalone statement with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'request changes' but doesn't clarify if this is a mutating operation, what permissions are required, how it affects the pull request state, or what the expected outcome is. This is a significant gap for a tool that likely modifies data.
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, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized for a simple tool, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a likely mutating operation (implied by 'request changes'), the description is incomplete. It doesn't cover behavioral aspects like side effects, return values, or error conditions, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (workspace slug, repository slug, pull request ID). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage nuances, so it meets the baseline for high schema coverage.
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 'Request changes on a pull request' clearly states the action (request changes) and target resource (pull request), but it's vague about what 'request changes' entails—does it submit a review, add comments, or trigger a workflow? It doesn't distinguish from siblings like 'add_pr_comment' or 'decline_pull_request', which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'add_pr_comment', 'approve_pull_request', 'decline_pull_request', and 'update_pull_request', the description lacks context on prerequisites, timing, or distinctions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update an existing issue' implies a mutation operation but doesn't disclose any behavioral traits: no information about permissions needed, whether updates are partial or complete, what happens to unspecified fields, error conditions, or rate limits. This leaves significant gaps for an agent to understand the tool's 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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core action and resource. While it lacks detail, what's present is structured efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, mutation operation) and absence of both annotations and output schema, the description is incomplete. It doesn't explain what fields can be updated, what the response looks like, error handling, or any behavioral context needed for a mutation tool. The 100% schema coverage helps with parameters but doesn't compensate for the lack of operational guidance.
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 information beyond what's already in the schema. Since schema description coverage is 100% (all 9 parameters have descriptions, including 3 with enums), the baseline score of 3 is appropriate. The description doesn't compensate with additional context about parameter relationships or usage patterns.
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 'Update an existing issue' clearly states the action (update) and resource (issue), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like 'update_pull_request' or explain what differentiates issue updates from other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing issue), when not to use it, or how it differs from related tools like 'create_issue' or 'delete_issue' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write operation, it doesn't address permission requirements, whether the branch becomes the current working branch, error conditions (e.g., duplicate branch names), or what happens if the target doesn't exist. This leaves significant behavioral gaps 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?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a straightforward creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., does it return the new branch object?), error conditions, or integration with sibling tools. The context signals show this is a 4-parameter tool with significant behavioral implications that aren't addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema by implying the relationship between 'name' and 'target' parameters, but doesn't provide additional context about parameter constraints or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new branch') and specifies the source ('from a specific commit or existing branch'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_branches' or 'delete_branch' beyond the obvious action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when not to use it, or how it relates to sibling tools like 'create_pull_request' or 'merge_pull_request' in a typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates a new issue but doesn't mention whether this requires specific permissions, what happens on success/failure, whether it's idempotent, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential 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?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions, side effects, or error conditions, nor does it explain what happens after creation or how to handle the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions and enums. The description adds no parameter information beyond what's in the schema, so it meets the baseline of 3 but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new issue in a repository'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_issue' or specify what distinguishes creating an issue from other creation tools like 'create_pull_request' or '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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'update_issue', 'delete_issue', and 'list_issues', there's no indication of prerequisites, when this is appropriate versus updating existing issues, or what context requires issue creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is 'create' (implying a write/mutation operation) but doesn't disclose permissions needed, rate limits, whether it triggers notifications, what happens on failure, or typical response format. For a mutation tool with zero annotation coverage, this is inadequate.
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, efficient sentence that front-loads the core action without unnecessary words. Every word earns its place by specifying the tool's primary function concisely.
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 tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., PR status, review workflow initiation), error conditions, or relationship to sibling tools like 'merge_pull_request'. The agent lacks critical context for proper invocation.
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 parameters are well-documented in the schema itself. The description adds no additional parameter context beyond implying source/destination branch involvement, which is already covered in schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a new pull request') and specifies the key resources involved ('from a source branch to a destination branch'), which distinguishes it from sibling tools like 'create_issue' or 'create_branch'. However, it doesn't explicitly differentiate from 'update_pull_request' or mention that it's for initiating code review processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_branch' for branch creation or 'update_pull_request' for modifying existing PRs. It doesn't mention prerequisites (e.g., needing existing branches) or contextual triggers (e.g., after completing feature development).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as required permissions, whether creation is idempotent, rate limits, error conditions, or what happens on success (e.g., returns a repository object). This leaves significant gaps 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?
The description is a single, clear sentence with zero waste. It's front-loaded with the core action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks context on permissions, behavioral details, and expected outcomes, which are crucial for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no additional meaning beyond implying a 'workspace' parameter, which is already covered. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new repository in the specified workspace'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_branch' or 'create_issue' beyond the resource type, which is why it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workspace permissions), when not to use it, or how it relates to siblings like 'get_repository' or 'list_repositories' for checking existing repos first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a decline/close action, implying a destructive mutation, but doesn't disclose critical behavioral traits: whether this is reversible, what permissions are required, if it sends notifications, or what happens to associated branches. For a mutation tool with zero annotation coverage, this is inadequate.
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, efficient sentence that front-loads the core action and outcome. Every word earns its place: 'Decline/close' specifies the action, 'a pull request' identifies the resource, and 'without merging' clarifies the distinction from merging. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation on a pull request), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral implications, error conditions, or return values. For a tool that permanently alters PR state, more context on effects and requirements is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (workspace, repo_slug, pr_id). The description adds no parameter-specific information beyond what the schema provides—it doesn't explain parameter relationships or usage context. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Decline/close') and resource ('a pull request') with the specific outcome 'without merging'. It distinguishes from sibling tools like 'merge_pull_request' by explicitly excluding merging, but doesn't differentiate from other PR modification tools like 'update_pull_request' or 'request_changes' beyond the decline action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user permissions), typical scenarios for declining vs. merging, or how it differs from simply closing a PR through other means. With multiple PR-related siblings (merge_pull_request, update_pull_request, request_changes), this lack of context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description lacks critical details: it doesn't specify if deletion is permanent or reversible, what permissions are required, whether it affects associated data (e.g., pull requests), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. It immediately conveys the core action without unnecessary elaboration, which is ideal for quick comprehension in a tool list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is insufficiently complete. It doesn't address critical aspects like return values (e.g., success confirmation or error details), side effects, or safety warnings. For a mutation tool that permanently removes data, more context is needed to ensure proper and safe usage by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions (workspace slug, repository slug, branch name). The description adds no additional semantic context beyond implying these parameters are needed to identify the branch. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance or clarify parameter usage further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a branch from a repository'), making the purpose immediately understandable. It distinguishes itself from siblings like 'delete_repository' or 'delete_issue' by specifying the branch resource. However, it doesn't explicitly differentiate from other branch operations like 'create_branch' or 'get_branch' beyond the verb, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., branch must exist, user permissions), exclusions (e.g., cannot delete protected branches), or related tools like 'create_branch' or 'list_branches'. Without such context, an agent might misuse it or overlook necessary checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Delete') but doesn't clarify if this is permanent, requires specific permissions, triggers notifications, or what happens on success/failure. For a destructive operation, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it easy to parse and front-loaded with the core action. It efficiently conveys the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with 3 parameters) and the absence of both annotations and an output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error handling, or return values, leaving critical gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter names and descriptions. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('an issue from a repository'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_branch' or 'delete_repository' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_issue' or 'list_issues', nor does it mention prerequisites (e.g., needing proper permissions) or consequences (e.g., irreversibility). It's a bare statement of function without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets details' but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what happens with invalid inputs. For a read operation with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the purpose and key details. Every word earns its place with no redundancy or fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It mentions what details are returned but doesn't cover the return format, error handling, or behavioral context. For a tool with three parameters and no structured output documentation, more completeness is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (workspace, repo_slug, commit_hash) with descriptions. The description adds no additional parameter semantics beyond implying 'commit_hash' is needed to identify the commit, which is already clear from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific commit including its message, author, and parent commits.' It specifies the verb ('Get'), resource ('commit'), and key details returned. However, it doesn't explicitly differentiate from sibling tools like 'list_commits' or 'get_commit_diff', which would require 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_commits' for multiple commits or 'get_commit_diff' for changes, nor does it specify prerequisites or exclusions. Usage is implied by the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'showing all changes' which hints at output behavior, but lacks critical details like format (e.g., unified diff, patch), pagination, error conditions, or authentication needs for a read 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?
Single sentence, front-loaded with the core purpose, no redundant words. Efficiently conveys the essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on output format, error handling, or behavioral traits, leaving gaps for an AI agent to correctly interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional parameter context beyond implying 'commit_hash' identifies the target, which the schema already covers. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the diff') and resource ('for a specific commit'), specifying it shows 'all changes'. It distinguishes from sibling 'get_pr_diff' by focusing on commits rather than pull requests, but doesn't explicitly contrast them.
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 on when to use this tool versus alternatives like 'get_pr_diff' or 'get_commit', nor any prerequisites or contextual constraints. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action but lacks details on permissions, rate limits, error conditions, or output format (e.g., text, binary, size limits). This is a significant gap for a tool that likely interacts with a version control system.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of file retrieval (likely involving Git operations) and the absence of both annotations and an output schema, the description is insufficient. It doesn't cover behavioral aspects like authentication, error handling, or what the returned content looks like (e.g., raw text, encoding), leaving critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (workspace, repo_slug, path, ref). The description adds no additional meaning beyond implying these parameters are needed to locate the file, which is already clear from the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the content') and resource ('a file from a repository'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'search_code' or 'get_commit_diff' that might also retrieve file content in different contexts, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for raw file content retrieval versus metadata or if other tools like 'search_code' should be used for broader queries. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action ('Get details'). It doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or the format of returned details. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, direct sentence with no wasted words. It front-loads the core action ('Get details') and specifies the target ('a specific issue'), making it efficiently structured for quick comprehension by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving issue details in a version control system, the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to address key aspects like authentication needs, error cases, or the structure of returned data. This makes it inadequate for reliable tool invocation in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all three parameters (workspace slug, repository slug, issue ID). The description adds no additional semantic context beyond what the schema provides, such as explaining how these identifiers relate or where to find them. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific issue'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_issues' or 'get_pull_request' which also retrieve issue-related information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_issues' (for multiple issues) or 'get_pull_request' (for pull requests, which are a type of issue in some systems). It lacks explicit context about prerequisites or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without specifying what details are returned, whether it's a read-only operation, or any behavioral traits like error handling or rate limits. This leaves significant gaps for a tool with three required parameters.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with three required parameters, no annotations, and no output schema, the description is incomplete. It fails to explain what details are returned, how errors are handled, or any contextual nuances, leaving the agent with insufficient information for reliable use.
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 meaning beyond the input schema, which has 100% coverage with clear parameter descriptions. The baseline score of 3 is appropriate since the schema adequately documents the parameters, but the description doesn't enhance understanding of their semantics or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('specific pipeline run'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_pipelines' or 'get_pull_request' beyond the resource name, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_pipelines' or other get_* tools. It lacks context about prerequisites, such as needing a specific pipeline UUID, or exclusions for 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions the output shows 'all changes', hinting at comprehensiveness, but lacks details on format, size limits, pagination, authentication needs, or error conditions. For a read operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids unnecessary elaboration. Every word contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, usage guidance, and details on output format or limitations. While concise, it doesn't compensate for the missing structured information, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying the tool operates on a pull request, which is already clear from the parameter names. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the diff') and resource ('for a pull request'), specifying it shows 'all changes'. It distinguishes from siblings like 'get_commit_diff' by focusing on pull requests, but doesn't explicitly differentiate from similar tools like 'get_pull_request' which might also provide diff information.
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 on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, when not to use it, or compare with siblings like 'get_pull_request' or 'get_commit_diff'. The description only states what it does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get details'), which implies non-destructive behavior, but doesn't disclose authentication requirements, rate limits, error conditions, or what 'details' specifically include beyond the mentioned branches/pull requests. For a tool with no annotation coverage, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by explicitly separating the action from the included details for even clearer scanning.
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?
Given the tool's moderate complexity (fetching repository details with multiple sub-resources), no annotations, and no output schema, the description is minimally adequate. It specifies the scope of returned data (branches, pull requests, metadata), but lacks details on authentication, error handling, pagination, or exact response structure. This leaves the agent with incomplete context for reliable use.
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 both parameters ('workspace', 'repo_slug') clearly documented in the schema. The description adds no parameter-specific information beyond implying these are needed to identify 'a specific repository'. This meets the baseline of 3 when schema coverage is high, but doesn't provide additional value like format examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('repository') with specific details about what information is retrieved ('details... including its branches, pull requests, and other metadata'). It distinguishes from sibling tools like 'list_repositories' (which lists multiple) and 'get_branch'/'get_pull_request' (which focus on specific sub-resources). However, it doesn't explicitly contrast with all similar siblings like 'get_commit' or 'get_issue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like authentication needs), when not to use it, or how it differs from related tools like 'list_repositories' (for listing all) or 'get_branch'/'get_pull_request' (for specific sub-resources). The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists commits with optional filtering, but doesn't describe what the output looks like (e.g., commit metadata format), whether it's paginated (though 'page' and 'pagelen' parameters hint at this), rate limits, authentication requirements, or error conditions. This leaves significant gaps for an agent to understand the tool's 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, efficient sentence that states the core purpose upfront with no wasted words. It's appropriately sized for a list operation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, pagination behavior (implied by parameters but not stated), error handling, or how filtering works beyond branch. Given the complexity and lack of structured data, more contextual information would be needed for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value by mentioning optional filtering by branch, which aligns with the 'branch' parameter but doesn't provide additional context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('commits in a repository'), making the purpose immediately understandable. It distinguishes from some siblings like 'get_commit' (singular) but doesn't explicitly differentiate from other list operations like 'list_branches' or 'list_pull_requests' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by branch, which provides some usage context, but offers no guidance on when to use this tool versus alternatives like 'get_commit' (for a single commit) or 'list_pull_requests' (which might contain commits). There's no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List') but doesn't describe whether this is a read-only operation, how pagination works (implied by 'page' and 'pagelen' parameters but not explained), rate limits, authentication needs, or what the output format looks like. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly calling out key parameters or usage scenarios without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list operation with filtering and pagination, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or behavioral nuances like pagination handling, which are critical for an agent to use the tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description adds minimal value by mentioning 'optional filtering' (hinting at parameters like 'q', 'sort'), but doesn't provide additional context beyond what's in the schema, such as examples of query strings or sort fields. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('issues in a repository'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar siblings like 'get_issue' or 'search_code', which could also retrieve issue-related data, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives like 'get_issue' for single issues or 'search_code' for broader searches. There's no mention of prerequisites, such as requiring repository access, or exclusions for when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('List') but doesn't disclose behavioral traits such as pagination behavior (implied by parameters but not described), rate limits, authentication requirements, or response format. For a list operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a list tool with 4 parameters. It doesn't explain return values, pagination behavior, or error conditions. While the purpose is clear, the lack of behavioral and output context makes it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional meaning beyond implying a repository context, which is already covered by 'repo_slug' in the schema. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('pipeline runs for a repository'), making the purpose unambiguous. It distinguishes itself from sibling tools like 'get_pipeline' (singular) and 'trigger_pipeline' (action). However, it doesn't specify scope (e.g., all runs vs. recent runs), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), differentiate from similar tools like 'list_repositories' or 'get_pipeline', or indicate when not to use it (e.g., for single pipeline details). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states it 'lists' comments (implying read-only) but doesn't cover critical behaviors: pagination details (implied by page/pagelen params but not explained), authentication requirements, rate limits, error conditions, or output format. For a tool with 5 parameters and no annotations, this is inadequate.
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, efficient sentence that states the core functionality without waste. It's front-loaded with the essential action ('List all comments') and resource ('on a pull request'). Every word earns its place, and there's no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is insufficiently complete. It lacks behavioral context (pagination, auth, errors), output details (comment structure, fields), and usage guidance. While the schema covers parameters, the description fails to address broader operational needs, leaving significant gaps 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 description coverage is 100%, so parameters are fully documented in the schema itself. The description adds no additional meaning about parameters—it doesn't explain relationships (e.g., workspace/repo_slug hierarchy), constraints (e.g., valid PR IDs), or usage patterns (e.g., pagination defaults). With high schema coverage, the baseline 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('comments on a pull request'), making the purpose immediately understandable. It distinguishes from siblings like 'add_pr_comment' (which creates comments) and 'get_pull_request' (which retrieves PR metadata). However, it doesn't specify scope details like 'all' vs 'filtered' or mention pagination behavior, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing workspace/repo access), compare to similar tools like 'get_pull_request' (which might include comments), or indicate use cases (e.g., reviewing feedback, auditing). Without any usage context, the agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional filtering by state but doesn't describe other critical behaviors: whether results are paginated (implied by page/pagelen parameters but not stated), what the return format looks like, rate limits, authentication requirements, or error conditions. For a list operation with 5 parameters, this leaves significant 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 a single, efficient sentence that front-loads the core purpose ('list pull requests for a repository') and adds one key detail ('with optional filtering by state'). There's zero waste or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the return format, pagination behavior (despite page/pagelen parameters), error handling, or how it differs from sibling tools. For a list operation in a rich API context, more contextual information is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by mentioning optional state filtering, which is already covered in the schema's enum for the 'state' parameter. No additional parameter context, examples, or constraints beyond the schema are provided, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list') and resource ('pull requests for a repository'), making the purpose immediately understandable. It also mentions optional filtering by state, which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'get_pull_request' (singular) or 'list_pr_comments', which would have earned 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_pull_request' (for a single PR) or 'list_pr_comments' (for comments on PRs). It mentions optional state filtering but doesn't explain when this filtering is appropriate or what the default behavior is. No prerequisites or context for usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation (implying read-only), but doesn't mention pagination behavior (implied by parameters), rate limits, authentication requirements, or what the output looks like. This is inadequate for a tool with 4 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters, the description is insufficient. It doesn't explain the pagination behavior (critical for list operations), authentication needs, or return format. For a tool in this context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter context beyond implying the tool operates on a repository. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('forks of a repository'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_repositories' or 'list_pull_requests' beyond the specific resource type, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing repository access) or compare it to similar list operations in the sibling set, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches code, implying a read-only operation, but doesn't describe key behaviors like pagination handling (implied by 'page' and 'pagelen' parameters but not explained), rate limits, authentication needs, error conditions, or what the search results include (e.g., file paths, snippets). This is a significant gap for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the main action and scope, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior (e.g., pagination, result format), usage context, and doesn't compensate for the absence of structured output information, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (workspace, search_query, page, pagelen) with basic descriptions. The description adds no additional meaning beyond implying a workspace context and search functionality, which is already covered by the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for code') and scope ('across all repositories in a workspace'), which is specific and distinguishes it from sibling tools that operate on specific resources like branches, issues, or pull requests. However, it doesn't explicitly differentiate from potential similar search tools (none are listed among siblings), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a workspace), exclusions, or compare it to other search-related tools (none are listed, but general context like 'use this for code search vs. issue search' is missing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose effects (e.g., whether stopping is reversible, if it requires specific permissions, or what happens to pipeline artifacts), which is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core action without unnecessary words. Every part earns its place by directly conveying the tool's purpose, making it optimally concise.
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 tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, or return values, leaving significant gaps that could hinder an agent's ability to use it correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters clearly documented in the schema. The description adds no additional meaning beyond implying the pipeline is identified by workspace, repo, and UUID, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Stop') and resource ('a running pipeline'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_pipeline' or 'trigger_pipeline' beyond the action itself, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the pipeline must be running), exclusions, or related tools like 'get_pipeline' for status checks, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a mutating operation (implied by 'trigger'), what permissions are required, whether it's idempotent, rate limits, or what happens if a pipeline is already running. For a tool that likely modifies system state, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope. Every word contributes essential information with zero redundancy. It's appropriately sized for a tool with clear parameters documented elsewhere.
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 mutating tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after triggering (e.g., returns a pipeline ID, runs asynchronously), error conditions, or system impact. Given the complexity of pipeline execution and the lack of structured behavioral information, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'branch, tag, or bookmark' which corresponds to the 'ref_type' enum, but doesn't explain parameter relationships or provide additional context about how these parameters interact during pipeline triggering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger') and target ('new pipeline run') with specific scope ('on a branch, tag, or bookmark'), making the purpose immediately understandable. It distinguishes from siblings like 'stop_pipeline' or 'get_pipeline' by focusing on initiation rather than termination or retrieval. However, it doesn't explicitly differentiate from all pipeline-related tools in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'stop_pipeline' or 'list_pipelines'. The description mentions triggering on specific reference types but doesn't explain prerequisites, dependencies, or typical use cases. Without annotations, this leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions what can be updated but doesn't disclose permissions needed, whether updates are reversible, rate limits, error conditions, or what happens to unspecified fields. For a mutation tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states the tool's function and scope, making it easy to parse and understand quickly.
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 tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or return values, leaving gaps that could hinder an AI agent's ability to use the tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value by listing updatable fields (title, description, destination branch), which aligns with schema properties but doesn't provide additional context like format constraints or examples beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('pull request'), specifying what fields can be modified (title, description, destination branch). It distinguishes from siblings like 'create_pull_request' or 'merge_pull_request' by focusing on updates, but doesn't explicitly contrast with 'update_issue' which has similar semantics for a different resource.
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 on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., needing an existing pull request), exclusions (e.g., cannot update merged PRs), or comparisons to siblings like 'update_issue' for issue modifications. The description assumes context without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool adds comments but doesn't disclose behavioral traits such as required permissions, whether comments are editable/deletable, rate limits, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating general vs. inline comment guidance, but it avoids waste and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool with 6 parameters. It lacks details on behavioral context (e.g., auth needs, error handling) and doesn't explain return values. For its complexity, it should provide more guidance to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value by hinting at the purpose of 'path' and 'line' for inline comments, but doesn't provide additional semantics beyond what the schema offers. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment') and resource ('to a pull request'), distinguishing it from sibling tools like 'list_pr_comments' or 'update_pull_request'. However, it doesn't explicitly differentiate from all siblings (e.g., 'request_changes' might also involve commenting).
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 mentioning 'general comment or an inline comment', suggesting when to use path/line parameters. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'request_changes' or 'update_pull_request', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details and latest commit, implying a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it correctly implies non-destructive 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, efficient sentence that front-loads the core purpose ('Get details of a specific branch') and adds a useful detail ('including its latest commit'). There's no wasted language, repetition, or unnecessary elaboration—every word earns its place in conveying essential 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?
Given the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks usage guidelines, behavioral details, and output information. Without annotations or output schema, the agent must infer behavior from the description alone, which is incomplete for reliable tool invocation.
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 all three parameters clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining how 'branch_name' interacts with 'latest commit' or format examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get details') and resource ('a specific branch'), including what information is retrieved ('including its latest commit'). It distinguishes from sibling tools like 'list_branches' (which lists multiple branches) and 'get_commit' (which focuses on commits rather than branches). However, it doesn't explicitly contrast with all siblings, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_branch' over 'list_branches' for branch information, or how it relates to 'get_commit' for commit details. There are no explicit when/when-not instructions or named alternatives, leaving usage entirely implied from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves details but doesn't disclose behavioral traits such as whether it's read-only (implied by 'Get'), authentication requirements, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get details of a specific pull request') and includes key specifics (source, destination, status). There is no wasted verbiage, and every word contributes to understanding the tool's function.
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?
Given the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects, usage context, and output format. With no output schema, the description should ideally hint at return values, but it doesn't, leaving the agent to guess what 'details' include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three required parameters (workspace, repo_slug, pr_id). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'pull request details', specifying what information is retrieved (source, destination, status). It distinguishes from siblings like 'list_pull_requests' by focusing on a specific PR rather than listing multiple. However, it doesn't explicitly differentiate from 'get_pr_diff' which also retrieves PR-specific data.
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for retrieving details of a specific pull request, but it doesn't mention prerequisites (e.g., needing a PR ID) or contrast with similar tools like 'get_pr_diff' or 'list_pull_requests'. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('List all branches') without mentioning key traits like pagination behavior (implied by 'page' and 'pagelen' parameters but not explained), rate limits, authentication requirements, or error handling, which are critical for a tool with multiple parameters.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly and accurately.
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?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic action but lacks context on usage, behavioral traits, and output details, which are needed for effective tool invocation in a multi-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters (e.g., 'workspace', 'repo_slug', 'q', 'sort', 'page', 'pagelen'). The description adds no additional meaning beyond the schema, such as explaining how filtering with 'q' works or default values for optional parameters, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all branches in a repository'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_branch' (which retrieves a single branch) or 'list_repositories' (which lists repositories rather than branches), so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like filtering needs (e.g., using 'q' parameter vs. other tools), prerequisites (e.g., required authentication), or comparisons to siblings such as 'get_branch' for single-branch retrieval, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds that results are paginated, which isn't obvious from the schema alone. However, it doesn't describe authentication requirements, rate limits, error conditions, or what 'repository details' specifically includes. For a read operation with 6 parameters, more behavioral context would be helpful.
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 perfectly concise at two sentences. The first sentence states the core purpose, and the second adds critical behavioral context about pagination. Every word earns its place with zero redundancy or unnecessary elaboration.
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 list operation with good schema coverage but no output schema, the description provides adequate but minimal context. It covers the basic purpose and pagination behavior, but lacks details about authentication, error handling, or what specific repository details are returned. Given the 6 parameters and no annotations, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond mentioning pagination (implied by page/pagelen parameters) and filtering (implied by role/q parameters). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List repositories') and resource ('in a workspace'), making the purpose immediately understandable. It distinguishes itself from other list operations like list_branches or list_issues by specifying repositories. However, it doesn't explicitly differentiate from list_repository_forks, which is a similar but distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose list_repositories over get_repository (for single repo details) or list_repository_forks (for fork-specific listings). No context about prerequisites, typical use cases, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions supported merge strategies. It doesn't disclose critical behavioral traits like required permissions, whether merging is irreversible, rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that front-loads the core purpose and adds useful detail about merge strategies. Every word earns its place with zero redundancy or unnecessary elaboration.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after merging (success/failure outcomes), return values, error conditions, or prerequisites beyond the implied 'open' state. More behavioral context is needed given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value by mentioning merge strategies (which the schema's enum already covers), but doesn't provide additional context like default behaviors or parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('merge') on a specific resource ('an open pull request'), distinguishing it from sibling tools like 'decline_pull_request' or 'update_pull_request'. It provides the exact verb and target without being tautological.
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 mentioning 'an open pull request', suggesting it should only be used when a PR is open. However, it doesn't explicitly state when NOT to use it (e.g., for closed/merged PRs) or name alternatives like 'decline_pull_request' for rejection scenarios.
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 effectively communicates the irreversible nature of the deletion, which is a critical behavioral trait. However, it does not mention potential side effects (e.g., impact on forks, permissions required, or error conditions), leaving some 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 extremely concise and front-loaded, consisting of just two sentences that directly convey the core action and its critical implication. Every word serves a purpose, with no wasted information 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?
Given the tool's complexity (a destructive operation with 2 parameters) and the absence of both annotations and an output schema, the description is somewhat incomplete. It covers the irreversible nature but lacks details on permissions, confirmation steps, or what happens post-deletion (e.g., return values or error messages).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'workspace' and 'repo_slug' parameters. The description does not add any additional semantic meaning beyond what the schema provides, such as explaining how to obtain these slugs or their format, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a repository'), making the purpose immediately obvious. It distinguishes this from sibling tools like 'create_repository', 'get_repository', and 'list_repositories' by specifying the destructive nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is an irreversible action, which implicitly guides when to use it (for permanent deletion) versus alternatives like 'delete_branch' or other non-destructive tools. However, it does not explicitly name alternatives or specify prerequisites beyond the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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