Bitbucket Server MCP

Server Quality Checklist

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

Latest release: v1.7.0
Disambiguation4/5
Tools are largely distinct, but there is redundancy between create_pull_request (which has a draft parameter) and create_draft_pull_request; also browse_files vs list_files could confuse agents. Overall, most tools have clear boundaries.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_projects, get_commit, create_branch). No mixing of conventions or irregular naming.
Tool Count2/5
With 57 tools, the surface is overly large for a typical Bitbucket server integration. Many specialized tools (e.g., for attachments, versioned comments) contribute to bloat; a more focused set of 25-35 tools would be more appropriate.
Completeness4/5
Covers the core PR lifecycle, commits, branches, repos, projects, search, and comments comprehensively. Minor gaps: no delete_branch, delete_repository, or update_repository tools, but these are not critical for most workflows.
Average 3.5/5 across 57 of 57 tools scored. Lowest: 2.4/5.
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 March 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action without explaining implications like notifications, permissions, or reversibility. The existence of unwatch_pull_request is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence and a parameter list. However, it omits necessary context, making it under-specified for practical use. Conciseness is achieved at the expense of completeness.
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 three parameters and no annotations, the description is minimal. It does not explain the purpose or side effects of watching a pull request, nor does it reference the output schema. More context is needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the three parameters by name only, adding no meaning beyond the input schema. Since schema description coverage is 0%, the description should compensate but fails to provide any additional details like formats, constraints, or examples.
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 'Subscribe as a watcher on a pull request', which is a specific verb and resource. It distinguishes from siblings like unwatch_pull_request by indicating the opposite action, but it does not explicitly differentiate from other pull request actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to watch a pull request instead of commenting or approving. The description lacks context for appropriate usage.
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 does not mention whether the operation is read-only, any required permissions, rate limits, or what the output format looks like. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the argument list is redundant with the schema. While the purpose sentence is front-loaded, the parameter list does not earn its place as it adds no new information. A more concise description could omit the parameter listing entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and an output schema exists (but is not described), the description fails to provide sufficient context. It does not explain the response content, pagination, or any side effects. The description is too minimal for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. However, it merely repeats the parameter names and trivial descriptions (e.g., 'The project key') that add no value beyond the schema titles. It does not explain how to obtain these identifiers or any constraints on their values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a specific comment on a pull request,' which clearly identifies the action and resource. It effectively distinguishes this tool from siblings like list_pull_request_comments (which returns all comments) and get_pull_request (which returns the PR itself).
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 does not mention that this tool is for retrieving a single comment by ID, while list_pull_request_comments should be used to fetch all comments on a PR.
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?
For a mutation tool with no annotations, the description should disclose side effects (e.g., notifications, state changes, blocking merges) and required permissions. It only states the action and user context, missing critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus a list of args) and the action statement is front-loaded. However, it could include more useful information (e.g., behavioral context) without becoming overly long.
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 simplicity (3 required parameters, no enums, output schema exists), the description should cover purpose, usage, and behavior. It fails on usage guidelines and behavioral transparency, making it incomplete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The parameter explanations ('The project key.', etc.) are minimal and essentially duplicate the property titles without adding value. They do not explain how to obtain these values or any 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 first sentence clearly states the action ('Approve') and resource ('a pull request'), and specifies it is as the authenticated user. While there are many sibling pull request tools, the verb 'approve' distinguishes this tool from others like 'decline_pull_request' or 'request_changes_pull_request'. However, there is no explicit differentiation from siblings.
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 other pull request actions, nor any prerequisites (e.g., user must be a reviewer, pull request must not be already approved). No alternatives or when-not-to-use instructions are given.
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 provided, so the description must disclose behavior. It fails to mention side effects (e.g., whether comments are closed, permissions required, or if the action is reversible). The 'version' parameter implies optimistic locking but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the parameter list repeats schema information. The core statement is concise, but lacks additional context that could be added without being verbose (e.g., explaining locking).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters with no descriptions, no annotations, and an output schema not described. The description does not explain return values, error conditions, or behavior, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description simply lists parameter names without adding meaning beyond the schema. With 0% schema description coverage, the description is the only source of parameter semantics, but it provides none. For example, 'project_key' is just named with no context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Decline a pull request.' which is a specific verb-resource pair. It distinguishes from sibling tools like approve_pull_request, merge_pull_request, etc. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 other pull request actions such as reject, request changes, or remove change request. The description does not mention prerequisites or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions pagination but omits details like order of results, error handling, or authentication requirements. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus parameter list is concise, but the parameter list is redundant with the schema and could be shortened or omitted if schema descriptions were present.
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?
Tool has output schema, lowering burden, but description fails to set expectation for the output content or use cases. Pagination is noted, but ordering and filtering are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It lists parameters with brief notes but adds little beyond the schema defaults. No explanation of what start/limit mean in context beyond defaults.
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?
Description clearly states it gets the activity feed for a pull request and mentions pagination. It distinguishes from siblings like list_pull_request_comments by focusing on the broader activity feed.
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_pull_request or list_pull_request_comments. No context on appropriate scenarios 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 provided, so the description carries the burden. It only says 'get,' implying read-only but lacks details on permissions, error states, or rate limits. Minimal disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant list of arguments that duplicates the schema. While not overly verbose, the list adds no value and could be omitted for better conciseness.
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 4-required-param tool with no annotations but an output schema, the description is minimal. It does not explain what the returned task data contains or other useful context, leaving gaps for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description merely lists parameter names (project_key, repo_slug, pr_id, task_id) without adding meaning, format, or relationships. Fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific task on a pull request,' which defines the action (get) and the resource (specific task). This distinguishes it from siblings like list_pull_request_tasks (list all) and create_pull_request_task.
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 such as list_pull_request_tasks or other get tools. The description does not provide contexts for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects, state changes, permissions, or error conditions. It only states the action and lists parameters, offering no transparency beyond the minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. However, the 'Args' section redundantly mirrors the schema without adding value, making it slightly less concise than optimal.
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 4 required parameters, no annotations, and an output schema, the description should cover success/error scenarios and usage context. It lacks information on version mismatch errors, required permissions, or what happens on success, making it incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It restates parameter names for project_key, repo_slug, and pr_id without extra context. Only the 'version' parameter gets additional explanation ('required for optimistic locking'), which is helpful but insufficient for full semantic clarity.
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 'Reopen a previously declined pull request.' uses a specific verb (reopen) and resource (previously declined pull request), clearly distinguishing it from siblings like 'decline_pull_request' or 'merge_pull_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (e.g., 'convert_to_draft' or 'publish_draft_pull_request'). The name implies usage for declined PRs, but no explicit context or prerequisites 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?
Lacks annotations and only says 'Remove your approval'; does not disclose behavior like what happens if no prior approval exists, or if the pull request is already closed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and to the point, but lacks any explanatory context; the 3 required parameters are listed but not elaborated upon.
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 minimal annotations, no parameter descriptions, and a simple action, the description fails to compensate for missing context such as prerequisites or return values, despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely repeats parameter names without adding any meaning; schema has 0% coverage and no parameter descriptions are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove your approval') and the resource ('pull request'), distinguishing it from sibling 'approve_pull_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'approve_pull_request' or 'request_changes_pull_request'; usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'unsubscribe from watching' without clarifying whether it removes only the current user, if it's idempotent, or what happens if not currently watching. Critical behavioral traits like permissions or reversibility are missing.
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 concise and front-loaded with the action. It uses a single informative sentence plus parameter listing. However, the parameter descriptions are redundant with the schema, which slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a simple input schema, the description should provide more context about what 'unwatching' entails, such as whether it requires prior subscription, effects on notifications, or relation to the 'watch_pull_request' counterpart. The presence of an output schema is unknown, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should add meaning beyond the schema. However, it merely lists parameter names (project_key, repo_slug, pr_id) without providing format, examples, or context. The schema already defines them, so no value is added.
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 'unsubscribe from watching a pull request.' It uses a specific verb+resource combination that distinguishes it from the sibling tool 'watch_pull_request.' However, it does not elaborate on the scope (e.g., for the current user or all watchers).
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 'watch_pull_request' or other PR tools. The description only implies the action but lacks context on prerequisites, side effects, or whether the user must be currently watching.
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 provided, so description must carry the behavioral burden. It only mentions pagination via start and limit parameters but does not disclose specifics like chronological ordering, whether merge commits are included, or any permissions or rate limits. Minimal behavioral insight.
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 very short and front-loaded with the main action. The parameter list is structured clearly. However, the parameter descriptions are repetitive and could be condensed. One unnecessary sentence structure but overall efficient.
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 large set of sibling tools and 5 parameters, the description provides insufficient context. It does not differentiate from list_commits or explain how the output relates to other PR tools. The existence of an output schema reduces burden, but behavioral and usage context are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter description coverage, so description must compensate. It provides one-line explanations (e.g., 'The project key.'), but these add little beyond the schema titles. The defaults for start and limit are mentioned but no details on valid ranges or formats.
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 'List commits included in a pull request (paginated).' This specifies the verb (list), resource (commits in a PR), and pagination. It distinguishes from sibling tools like list_commits (all repo commits) and get_commit (single commit).
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. Does not mention when not to use it or provide any comparison to siblings such as list_commits or get_pull_request. Without this, an agent may misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema details in the description, the behavioral disclosure is insufficient. Only pagination is mentioned; nothing about read-only nature, result structure, or potential limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a parameter list, which is moderately concise but could be more front-loaded. The list duplicates schema information without adding significant insight.
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 only a basic description, the tool lacks complete context. The output schema exists but is unmentioned; the description does not explain response structure or common use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While it lists each parameter with a brief label ('The project key'), these add minimal semantic value beyond the parameter names and schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List tasks') and the resource ('on a pull request'), including the pagination aspect. It effectively distinguishes from sibling tools like 'get_pull_request_task' (singular) and 'create_pull_request_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_pull_request_task' for a single task. The mention of pagination is the only usage hint, but no context about filtering or interpreting results.
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. It discloses that the tool sets participant status to NEEDS_WORK, but does not mention permissions, reversibility, or side effects. Minimal behavioral insight.
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 concise with a clear first sentence. The docstring format is acceptable, though some redundancy exists (e.g., 'as the authenticated user' is implied).
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 a minimal description, the tool lacks context on side effects, error conditions, and prerequisites. The output schema may cover return values, but the description does not provide a complete picture for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only lists parameter names in the docstring without adding any semantic meaning, constraints, or examples. It adds no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (request changes) and the resource (pull request). It distinguishes from sibling tools like approve, decline, or comment by specifying 'request changes' and setting status to NEEDS_WORK.
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. There is no mention of scenarios, prerequisites, or comparisons with siblings like decline or convert_to_draft.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions that metadata must be valid JSON but does not disclose idempotency, destructive nature, or what happens if metadata already exists. Lacks behavioral details expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. It uses a docstring-like structure with Args, which is clear. No unnecessary words, though it could be slightly more 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?
Output schema exists, so return values are covered, but the description lacks details on success indicators, error handling, or side effects. For a tool with 4 required params and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It lists all four parameters but only adds meaningful info for metadata (must be valid JSON). For project_key, repo_slug, attachment_id, it merely repeats names, adding little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create or update metadata for an attachment,' which is a specific verb-resource combination. This clearly differentiates it from sibling tools like get_attachment_metadata and get_attachment, which are for retrieval.
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 (e.g., get_attachment_metadata for reading). The description does not provide any context or exclusions, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read operation (browsing) but does not explicitly state read-only nature, permissions, or error behaviors. It adds only basic parameter explanations.
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?
Front-loaded with a clear first sentence stating purpose. The parameter list is necessary given the lack of schema descriptions, but it is somewhat verbose. Structured and easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not cover returns. However, it lacks comparative context with sibling tools (e.g., browse_files vs list_files) and does not mention read-only behavior, leaving the agent with incomplete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides clear, functional explanations for all six parameters (project_key, repo_slug, path, at, start, limit), adding meaning beyond the schema's type/default fields.
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 browses the file tree of a repository at a given path and revision. However, it does not differentiate from the sibling tool 'list_files', which might have overlapping functionality.
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 'list_files' or 'find_file'. The description lacks context about prerequisites or scenarios.
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 provided. Description does not state that the tool is read-only, mention permissions, or describe side effects. Lists return fields but lacks behavioral context beyond that.
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?
Description is concise with a one-line summary and return info, but the args section is repetitive. Could be more structured, but overall efficient.
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?
Output schema exists but not shown; description mentions key return fields. Lacks error cases, auth requirements, or rate limits. Adequate for a simple checking tool but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description provides minimal parameter info (e.g., 'The project key') which adds little beyond schema titles and types. For 0% coverage, more detailed semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'check' and resource 'pull request merge readiness', lists key outputs (canMerge, conflicted, vetoes). Clearly distinguishes from sibling tools like merge_pull_request (which performs merge) and get_pull_request (which gets full details).
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 vs alternatives. Implies a pre-merge check but doesn't explicitly contrast with merge_pull_request or other PR tools. No when-not or alternative recommendations.
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?
Description implies read-only retrieval but provides no further behavioral details (e.g., error handling, authorization needs, side effects). With no annotations, description should be more informative.
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?
Very concise with clear argument list. However, lacks additional structure like examples or notes, which would improve usability without much length.
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 output schema exists, description need not detail return values. Tool is simple (3 scalar params). Completeness is adequate but minimal; more context about return type would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description merely repeats parameter names from schema without adding format constraints, examples, or clarifying distinctions (e.g., project_key vs repo_slug format). Schema coverage is 0%, so description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves metadata of an attachment, using specific verb and resource. Distinguishes from siblings like get_attachment (likely file content) and save_attachment_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_attachment or save_attachment_metadata. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only states 'Get details' without addressing read-only nature, error responses, or side effects. This minimal disclosure is insufficient for informed invocation.
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: one sentence and a parameter list. It front-loads the primary purpose and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema reduces the need for detailed return value documentation. However, the description lacks essential context such as typical scenarios, error handling, or relationship to sibling tools (e.g., get_commit_changes). It is adequate for a simple get operation but leaves gaps for complex decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by clarifying each parameter: 'the project key', 'the repository slug', and 'the full commit hash' (specifying full hash vs. short). This provides value over the schema's bare titles, but given 0% schema description coverage, more detail (e.g., format, constraints) would be beneficial.
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 'Get details of a specific commit,' providing a specific verb and resource. However, it does not distinguish itself from sibling tools like get_commit_changes or get_commit_diff, which could cause confusion in tool selection.
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 offers no guidance on when to use this tool versus alternatives. It lacks context about prerequisites, input validation, or preferred scenarios, leaving the agent to infer usage 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 provided, so description bears full burden. Beyond parameter list, it discloses no behavioral details (e.g., idempotency, side effects, error conditions). The description adds nothing that the schema does not already show.
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?
Front-loaded with clear main action. Parameter list is concise but somewhat redundant with schema. Could be more compact, but not excessive.
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?
Covers purpose and parameters, but lacks usage context, behavioral attributes, and does not mention return value (even though output schema exists). Adequate for basic understanding but incomplete for a new 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 0%, but description explains each parameter with type and default. It adds minor context (e.g., 'typically git' for scm_id), but largely repeats schema information. Some value added, but not extensive.
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 'Create a new repository in a project.' It uses a specific verb ('create') and resource ('repository'), and distinguishes from sibling tools like create_branch or create_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., need a project key), or cases where this tool is not 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, and the description does not disclose behavioral traits such as read-only nature, authorization needs, or side effects. For a simple getter, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant 'Args:' block that repeats parameter names. It could be more concise without this repetition.
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 simplicity (2 params) and existence of an output schema, the description is adequate but lacks guidance on when to use it and what the default branch represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds only basic explanations ('The project key', 'The repository slug') that add little beyond the parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('default branch of a repository'), distinguishing it from sibling tools like 'list_branches' or 'get_repository'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_branches' or 'get_repository'. Usage is implied but not contextualized.
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 provided; the description only states it 'gets the diff' without detailing read-only nature, permission requirements, diff format, or any side effects. It lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and neatly organized with a bullet list of parameters. Every sentence adds value, though the Arg list could be integrated into the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to cover return values. However, it lacks details on the diff format, filtering behavior, or any edge cases, making it only partially complete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: 'context_lines' has default and max, 'src_path' is optional and purpose is given. However, it does not explain the format or constraints for other parameters like project_key or repo_slug.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the diff of a pull request,' specifying the verb and resource. It distinguishes itself from siblings like get_pull_request, get_pull_request_activities, etc.
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_commit_diff or get_pull_request_diff_stat. There is no mention of prerequisites, exclusions, or 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?
The description mentions that 'version' is required for optimistic locking, which adds behavioral context. However, with no annotations provided, it does not disclose other behavioral traits such as side effects, error conditions, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose sentence followed by a parameter list. No extraneous content. However, the parameter list could be more integrated into the behavioral narrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere. The description covers the basic operation and optimistic locking but lacks context on error handling, prerequisites, or interaction with other tools. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides brief explanations for each parameter (e.g., 'The new comment text'). These add some meaning beyond field names, but are minimal and do not include constraints or format details.
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 updates the text of a comment on a pull request, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'add_pull_request_comment', though the action is distinct.
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 adding or deleting a comment. The description only states what it does without indicating prerequisites or choice criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and lists parameters, but does not disclose side effects, permissions, error conditions, or behavior on conflicts.
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 short and front-loaded with the purpose, listing parameters in a clear bullet format. Every sentence is useful, though the parameter explanations could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the output schema, return values, error handling, or prerequisites. With no annotations, the description should provide more operational context for this creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides brief explanations for all four parameters (e.g., 'start_point: Commit ID or branch name to branch from'). These add some meaning beyond the schema, but are minimal and lack detail.
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 'Create a new branch in a repository.' This is a specific verb and resource, and it distinguishes the tool from siblings like list_branches and create_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Since there are no sibling tools for branch creation, the lack of exclusion criteria is acceptable, but the description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation ('suggested commit message') based on PR title and commits, with no hint of destructive side effects, which is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes an 'Args' section that largely duplicates input schema parameter names and titles. Could be more concise by removing redundant 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?
Output schema exists, so return values are covered. However, description lacks edge cases, limitations, or workflow context (e.g., when to call this before merging). It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. However, the 'Args' section only repeats parameter names with trivial descriptions like 'The project key.' This adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a suggested commit message for merging a pull request,' which specifies the verb and resource. It distinguishes from sibling tools like merge_pull_request or get_pull_request, though not explicitly.
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 mentions 'Based on the PR title and included commits,' implying how the suggestion is generated, but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings.
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 provided. The description does not disclose behavioral traits such as side effects, authentication needs, or rate limits. It only states the obvious retrieval purpose.
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?
Extremely concise: one line for purpose and a simple args list. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values. However, it lacks usage guidelines and behavioral transparency, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds minimal meaning by explaining each parameter as 'The project key', 'The repository slug', 'The pull request ID'. This compensates slightly but lacks detail on formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific pull request', using a specific verb and resource. It distinguishes from sibling tools like list_pull_requests and get_pull_request_activities.
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. The description only repeats parameter names without any context about appropriate use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get details' which implies a read operation, but fails to disclose behavior on missing repositories, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two lines of text and a parameter list, no fluff. However, it could be restructured to be more readable, but overall it is efficient.
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 that an output schema exists, the description does not need to explain return values. However, for a simple retrieval tool, it lacks details on authorization or potential errors, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely lists the parameter names without adding any additional meaning beyond the schema titles (e.g., 'Project Key'). No format or constraints are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific repository' using a specific verb and resource. It distinguishes from sibling tools like 'list_repositories' (which lists all) and 'create_repository' (which creates).
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 does not provide explicit guidance on when to use this tool versus alternatives. It only states what it does, leaving the agent to infer its use case from the name and parameters.
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?
Lacks annotations, so description must bear the load. Mentions Elasticsearch requirement and limit defaults, but does not disclose return format, pagination, error behaviors, or whether results include snippets.
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?
Description is concise with a clear first sentence followed by structured Args. No superfluous text, though the Args block could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite, scope parameters, and limit. With output schema existing, missing return details are acceptable. Minor gap: no explanation of query language or wildcard support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds necessary parameter context: query required, project_key and repo_slug optional with constraint that repo_slug requires project_key, limit default and max. However, query syntax and expected format are not explained.
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?
Clearly states it searches code across repositories using Bitbucket Server code search. Differentiates from siblings like browse_files and find_file by specifying 'code search' but does not explicitly contrast with them.
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?
Provides prerequisite (Elasticsearch enabled) but no directives on when to use vs alternatives like find_file or browse_files. Usage is implied by the tool's unique function.
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?
Without annotations, the description carries the full burden of behavioral disclosure. It only mentions 'paginated', but does not state whether the operation is read-only, what permissions are required, or any rate limits. The read-only nature is implied but not confirmed.
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: a one-sentence summary followed by a structured parameter list. No superfluous information. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward paginated list tool, the description covers the basic purpose and pagination. However, it does not mention ordering, filtering, or the structure of returned comments (though output schema exists). Missing any behavioral context like read-only safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only provides trivial labels like 'The project key.' which adds minimal meaning beyond the schema's parameter names and types. It fails to explain the relationship between parameters or expected formats.
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 'List comments on a pull request (paginated)', which includes the verb (List), resource (comments on a pull request), and the key behavior (paginated). This effectively distinguishes it from siblings like get_pull_request_comment (single comment) or add_pull_request_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing comments, but provides no explicit when-to-use or when-not-to-use guidance relative to alternatives like get_pull_request_comment or add_pull_request_comment. The context is clear from the name, but explicit exclusions are 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 must fully disclose behavior. It indicates a state change but lacks details on side effects, required permissions, or error conditions. The optimistic locking hint for version is good, but overall the behavioral disclosure is thin.
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 short and to the point with two sentences. However, the parameter list repeats schema fields unnecessarily, slightly reducing conciseness efficiency.
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 existence of an output schema (not shown), return values are covered. However, the description lacks usage context, such as when to use this versus resolve or update, and fails to mention preconditions (e.g., the comment must be resolved). This leaves 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?
The description adds value by explaining the version parameter's purpose ('required for optimistic locking'). However, the other parameter descriptions (e.g., 'The project key') do little more than restate the schema field names. With 0% schema coverage, more effort to clarify parameters would be expected.
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 ('Reopen'), the resource ('comment thread'), and the context ('previously resolved on a pull request'), effectively distinguishing it from siblings like resolve_pull_request_comment and add_pull_request_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for reopening resolved comment threads but provides no explicit when-not-to-use or alternative tools. The version parameter is noted as required for optimistic locking, but no prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that text files return content and binary files return a size summary, adding behavioral context beyond the schema. Does not address authentication, rate limits, or potential side effects.
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?
Description is short with a clear main sentence, followed by a parameter list. The parameter list is somewhat redundant with the schema but aids quick reference. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers return values for text and binary files. It lacks details on errors or size limits, but for a simple download tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists each parameter with brief explanations (e.g., 'The project key'). These are minimal and somewhat tautological but provide some semantics beyond the schema's names and types.
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 'Download an attachment from a repository by its numeric ID', specifying the action and resource. It does not explicitly differentiate from sibling 'get_attachment_metadata', but the purpose is distinct enough.
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?
Provides context on behavior for text vs binary files, guiding expectations. However, no explicit guidance on when to use this vs alternatives like 'get_attachment_metadata', nor any when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral traits. It only states the action and lists parameters; it does not disclose read-only nature, authentication needs, rate limits, or return format. The mention of default and max for context_lines is minor behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a clear header and bullet-point arguments. Every line is informative with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and references the output schema indirectly, but lacks usage context relative to sibling tools. No guidance on when to prefer this over alternatives like 'get_commit_changes'. It is adequate for a straightforward tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose (project key, repo slug, commit id, context lines, src path) and includes defaults and maximum for context_lines. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the diff for a specific commit' with a specific verb and resource. It distinguishes itself from siblings like 'get_commit' and 'get_commit_changes' by focusing on the diff, and the argument list further clarifies what is needed.
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 such as 'get_commit_changes' or 'get_pull_request_diff'. The description does not mention prerequisites or situations where it is appropriate.
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 full burden. It discloses pagination behavior via 'paginated' and start/limit parameters. However, it does not mention side effects, required permissions, rate limits, or the format of returned data. The output schema exists but is not described.
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 concise, starting with a clear one-line purpose followed by a bullet-like list of arguments. It efficiently uses space, though the args list largely mirrors the schema with added defaults. No superfluous content.
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 complexity (5 params) and existence of an output schema, the description is adequate but not overly rich. It explains pagination and required parameters but does not clarify what information is returned for each changed file (e.g., path, change type) or how it differs from related tools. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds significant value by explaining all 5 parameters: project_key, repo_slug, commit_id, start (default 0), limit (default 25), and notes that commit_id should be the full hash. This goes beyond the schema which only provides types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of files changed in a commit (paginated)' clearly states the verb (get), resource (list of files changed in a commit), and key feature (paginated). This is distinct from siblings like 'get_commit_diff' which returns diffs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_commit_diff' (for actual diffs) or 'list_commits' (for commit metadata). The description implies usage for getting changed file lists but does not explicitly state exclusions or preferred contexts.
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?
Discloses version for optimistic locking and strategy examples, but does not explain side effects (e.g., PR closure, branch deletion) or required permissions. With no annotations, more detail is needed.
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?
Description is concise with one line and a bullet-like list. No unnecessary content, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information on preconditions (e.g., PR must be open, mergable) and error conditions. Has output schema, so return values need no explanation, but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema (0% coverage) by describing each parameter, including optimistic locking for version and example strategies. However, some descriptions are tautological (e.g., 'project_key: The project key').
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 'Merge a pull request.' which is a specific verb+resource, and it distinguishes from siblings like create, approve, decline, etc.
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 (e.g., can_merge_pull_request, create_pull_request). No mention of prerequisites like approval status or conflict resolution.
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 automatic prefix addition but does not disclose side effects, required permissions, or error conditions. The output schema exists but the description does not explain what is returned.
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 front-loaded with the main action and then structured as an Arg list. It is verbose but each sentence serves a purpose; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no annotations, the description covers parameter meanings but lacks information on return values, error handling, or prerequisite conditions. The presence of an output schema is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It provides clear explanations and examples for each parameter (e.g., source_branch example), adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new pull request.' It distinguishes from siblings by including branch naming guidance, and the title is directly aligned with the verb+resource structure.
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?
No explicit guidance on when to use this tool vs alternatives like create_draft_pull_request. The description provides branch naming rules but lacks context for when to use different PR creation options.
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 exist, so the description carries full burden. It only states the action and optional comment linking, but fails to disclose permissions, side effects, rate limits, or return behavior beyond the basic creation.
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 very concise: a single-sentence purpose followed by a structured Args list. Every sentence adds value with no 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?
While parameter descriptions are adequate, the tool lacks guidance on prerequisites (e.g., permissions, existence of PR) and does not leverage the existing output schema to describe return values. Somewhat incomplete for a tool with 5 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful parameter explanations (project_key, repo_slug, pr_id, text, optional comment_id). It clarifies each argument's role, compensating well for the schema's lack of detail.
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 'Create a task on a pull request' with an optional comment link. It distinguishes well from sibling tools like update_pull_request_task and list_pull_request_tasks.
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?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied by the description, but given many sibling tools, explicit context would help. No alternatives mentioned.
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?
The description discloses the key behavioral outcome (status reset to UNAPPROVED) but lacks details on prerequisites, side effects, or error conditions. No annotations are provided, so the description carries full burden; it is adequate but not comprehensive.
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 minimal and efficient: two sentences plus a parameter list. It is front-loaded with the primary action and immediate effect, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward tool, the description covers the core behavior and parameters. However, it does not differentiate from similar tools like 'unapprove_pull_request' or mention edge cases, leaving some gaps given the number of 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 0%, but the parameter names (project_key, repo_slug, pr_id) are self-explanatory. The description restates these names without adding extra meaning or constraints, so minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove your change request from a pull request') and details the effect ('Resets the user's participant status to UNAPPROVED'). This distinguishes it from sibling tools like 'request_changes_pull_request' and 'unapprove_pull_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want to remove your change request) but does not explicitly compare with alternatives or state when not to use. Given sibling tools like 'unapprove_pull_request', more guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the primary behavior (convert to draft) and mentions optimistic locking via version. However, it does not mention potential side effects, permission requirements, or state constraints (e.g., PR must be open).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose, a sentence for version guidance, and a clear bullet list for parameters. No superfluous information, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with 4 parameters and an output schema, the description covers the essential aspects: purpose, parameter semantics, and a cross-reference for obtaining the version. It lacks explicit statements about preconditions (e.g., PR must be open) but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining all four parameters. Particularly, it clarifies the version parameter's purpose (optimistic locking) and how to obtain it. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Convert an open pull request back to draft mode.' This is a specific verb-resource pair that distinguishes it from siblings like create_draft_pull_request (creates new draft) and publish_draft_pull_request (publishes draft to open).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives. It only provides guidance for the version parameter (obtain from get_pull_request) but lacks context on prerequisites or when conversion is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'raw content' but does not specify the format (binary, text), size limits, authentication requirements, or error handling. For a file retrieval tool, this leaves important 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 concise: one sentence for the purpose followed by a clear Args list. No extraneous information, and the structure front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 parameters, no annotations), the description is fairly complete, covering all parameters. However, it lacks details on the output format (though an output schema is present) and behavior for large files. The missing guidance on return format or limitations prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section explains each parameter: project_key, repo_slug, path, and at (optional). This adds semantic meaning beyond the input schema, which has 0% description coverage. The explanation of 'at' as 'Optional branch name, tag, or commit ID (defaults to default branch)' is particularly helpful.
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 purpose: 'Get the raw content of a file from a repository.' This uses a specific verb and resource, and it distinguishes the tool from siblings like browse_files, find_file, and list_files, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as browse_files for directory listing or search_code for searching. The usage context is implied by the parameter 'path' indicating a specific file, but no exclusions or alternative tool recommendations 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does not mention side effects, authorization needs, rate limits, or any constraints beyond the input parameter. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two lines and a clear docstring. The key information is front-loaded, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter nature and presence of an output schema, the description is largely complete. It could mention details like case sensitivity, but overall it provides sufficient context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds an example format ('e.g., 'PROJ'') for the project_key parameter. This clarifies the key format, providing meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get details' and the resource 'specific project' via its key, distinguishing it from list_projects and other project-related tools. The verb and resource are specific.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., list_projects) or when not to use it. The description is minimal, leaving usage context implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes pagination and filtering but does not explicitly state that the operation is read-only or disclose any behavioral traits like rate limits or authorization needs.
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, front-loading the purpose in one sentence, then listing parameters in a clean, easily scannable format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters and an output schema, the description adequately covers parameter semantics and pagination behavior. It does not explain the output format, but the output schema exists to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to all parameters: it specifies that filter_text is optional for filtering tag names, and start/limit control pagination. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List tags in a repository (paginated)', which clearly indicates the action and resource. This distinguishes it from sibling tools like list_branches or list_files.
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 (e.g., list_branches for branches). The description lacks context about when not to use or prerequisite conditions.
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?
Annotations are absent, so the description must handle transparency. It explains the 'version' parameter for optimistic locking, implying a state change. However, it does not disclose whether the action is reversible, what happens on failure, or any permission requirements, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose, followed by a clearly formatted list of arguments. Every word serves a purpose, and the structure prioritizes essential information upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 required parameters) and the presence of an output schema (not shown), the description covers the core action and the critical version parameter. It is sufficient for an agent to understand the basic operation, though it omits edge cases like version mismatch handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by listing all 5 required parameters with explanations. Notably, the 'version' parameter is described with its purpose (optimistic locking), adding value beyond the schema's titles. Other descriptions are minimal but adequate.
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: 'Resolve a comment thread on a pull request.' The verb 'resolve' and the resource 'comment thread' are specific, distinguishing it from sibling tools like 'add_pull_request_comment' or 'reopen_pull_request_comment'.
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 (e.g., 'reopen_pull_request_comment'). It does not mention prerequisites, such as the comment needing to be unresolved, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'update' but does not disclose behavioral traits like persistence, permissions, or side effects. More detail is needed 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 concise, front-loads the primary purpose, and lists parameters efficiently. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and moderate complexity, the description covers the basics of what the tool does and its parameters. It lacks behavioral context but is sufficient for a straightforward update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description includes an Args block explaining each parameter's purpose. It adds meaningful context beyond the raw schema, especially for text and state fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a task's content or state on a pull request. It uses a specific verb+resource and distinguishes itself from sibling tools like create_pull_request_task and get_pull_request_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to modify a task) but does not provide explicit guidance on when not to use it or alternatives. It lacks exclusions or context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions supported comment types and the effect of severity but does not disclose side effects, permissions, rate limits, or error conditions. The existence of an output schema partially mitigates this.
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?
Concise and well-structured: a one-line summary followed by a clear list of arguments. Front-loaded with purpose. Slightly verbose in the arg list but necessary given the parameter count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters with zero schema descriptions and a rich output schema, the description covers the essential semantics for all comment types. Lacks prerequisites and error handling, but overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description comprehensively explains all 10 parameters, including allowed values for severity, line_type, and file_type, and the purpose of parent_comment_id, file_path, line, etc. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool adds a comment to a pull request and describes three modes: general, inline, and reply. Distinguishes from siblings like get_pull_request_comment (read) and update_pull_request_comment (update).
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?
Provides a hint for creating blocker tasks via severity='BLOCKER', but lacks explicit guidance on when to use this tool versus alternatives like create_pull_request_task. No 'when not to use' or context about prerequisites.
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?
Annotations are absent, so the description carries the burden. It mentions pagination parameters (start, limit) but does not explicitly state the operation is read-only, nor does it discuss authentication, rate limits, or behavior for large PRs.
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: one sentence stating purpose followed by a bullet list of parameters. No wasted words, and the purpose is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown here) which likely covers return values, so the description need not explain them. Input parameters are adequately described. Missing usage context and behavioral details prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides a one-line explanation for each parameter (e.g., 'project_key: The project key.') which adds meaning beyond the schema's type-only definitions. However, it could be more detailed (e.g., format, constraints) for full compensation.
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 it retrieves the per-file change list for a pull request, specifying that it includes added, modified, deleted, and moved files. This verb+resource scope is specific and distinguishes it from sibling tools like get_pull_request_diff (which likely provides the full diff).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like get_pull_request_diff or get_pull_request_activities. The purpose is implied but lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses pagination behavior and default/max values, which is good but lacks details like ordering, read-only nature, or any side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-line description with structured argument list. No unnecessary words, front-loaded with purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the tool's simplicity, the description sufficiently covers input parameters and pagination. Missing return value explanation is acceptable due to output schema. Could mention that it's read-only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has properties with titles but no descriptions (0% coverage). Description adds default values for start and limit, plus max for limit, which is valuable guidance. However, it doesn't explain the meaning of 'page start index' further.
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 'List all projects visible to the current user (paginated),' specifying the verb 'list' and resource 'projects' with scope. It distinguishes from siblings like list_repositories and list_pull_requests, which operate on different resources.
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?
No explicit guidance on when to use or avoid this tool, nor alternatives. However, the simple nature of listing projects makes usage context obvious. Could have mentioned that this returns only visible projects vs. other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions pagination but lacks details on permissions, error handling (e.g., if repo doesn't exist), rate limits, or data freshness. This is a significant gap for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise one-line summary followed by a detailed Args block. It is appropriately sized for 11 parameters, with no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not detail return values. It covers all input parameters adequately. However, it could mention pagination behavior beyond start/limit defaults (e.g., total count indication) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all 11 parameters. It provides defaults, allowed values (e.g., state: 'OPEN', 'DECLINED', 'MERGED', 'ALL'), and functional meaning (e.g., 'optional target branch ref filter'). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists pull requests in a repository with pagination. This distinguishes it from sibling tools like 'get_pull_request' (single PR) and 'list_dashboard_pull_requests' (dashboard scope).
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 implicitly defines the use case by specifying repository-scoped listing with pagination and filters. However, it does not explicitly mention when not to use it or suggest alternatives, though sibling context provides clarity.
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?
The description mentions optimistic locking via the version parameter, which is a key behavioral detail. However, with no annotations provided, it lacks other behavioral context such as reversibility, required permissions, or side effects like triggering CI. It adequately covers the locking mechanism but not full safety profile.
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 concise with a clear opening sentence followed by a parameter list. It is front-loaded and well-structured, though the Args section could be slightly redundant given the schema; however, due to zero schema coverage, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description does not need to detail return values. However, it lacks explicit preconditions (e.g., PR must be in draft state) and error conditions (e.g., incorrect version). The parameter dependency on get_pull_request is helpful, but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing all four parameters and adding context, especially for 'version' ('current version required for optimistic locking'). This adds meaning beyond the bare schema, though constraints like source for project_key/repo_slug are implied.
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: 'Publish a draft pull request, making it ready for review.' It uses specific verbs and resource, distinguishing it from siblings like 'create_draft_pull_request' and 'convert_to_draft'.
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 a prerequisite: the version parameter must be obtained from get_pull_request for optimistic locking. It implies usage on draft PRs, but does not explicitly state when not to use or compare with siblings like 'merge_pull_request'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It notes that the tool uses code search and supports wildcards, and mentions result limits. However, it does not explicitly state that it is read-only, or address permissions or side effects.
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 brief and front-loaded: a purpose sentence, a wildcard support note, and a structured list of parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no annotations, output schema exists), the description covers the main purpose, parameter usage, and constraints like max results. It lacks mention of error handling or authentication, but the output schema likely compensates for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section that explains each parameter: query (pattern), project_key (optional scope), repo_slug (requires project_key), and limit (default 25, max 1000). This adds significant meaning beyond the schema's bare names and types.
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 'Find files by name or path pattern using Bitbucket Server's code search,' which is a specific verb and resource. It also mentions Lucene wildcards, distinguishing it from siblings like list_files or browse_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pattern matching via wildcards but does not explicitly contrast with other file listing tools (e.g., list_files, browse_files). No when-not to use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly mentions pagination and explains the start and limit parameters, which are key behavioral aspects. It does not mention any side effects, which is appropriate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences and a parameter list. It front-loads the purpose. The parameter list adds clarity but could be slightly more compact; overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 simple parameters, no nested objects, output schema present), the description covers the purpose and parameters well. It does not discuss error conditions or prerequisites, but for a list operation this is acceptable. A mention of pagination details is already included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides explanations for all five parameters, including defaults for start and limit, and the role of filter_text. This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (branches), and explicitly notes pagination. It distinguishes from siblings like create_branch (different action) and list_tags (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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as list_commits or browse_files. Usage context is implied through the action and parameters, but no when-not or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool lists participants (a read operation) but does not explicitly state it is non-destructive or describe any side effects. The description is adequate but could be more transparent about the operation's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary followed by a bullet-like argument list. Every sentence serves a purpose with no waste. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately omits return value details, but it does mention that roles and approval statuses are included. It covers all 5 parameters with clear explanations. The description is nearly complete for a simple list tool; a minor gap is that it does not mention the response format or pagination metadata, but these are likely handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document parameters. It does so effectively, explaining each parameter (project_key, repo_slug, pr_id, start, limit) and noting that start and limit are for pagination with defaults. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), the resource (participants/reviewers of a pull request), and the output (roles and approval statuses). It distinguishes from sibling tools like list_pull_request_comments or list_pull_request_commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It provides implied usage through its name and description, but lacks explicit when-not or alternative references. The pagination parameters (start, limit) are documented, which helps, but no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains that draft mode means not ready for review and that 'refs/heads/' prefix is added automatically. However, it does not mention permissions, error conditions, or what happens if branches do not exist.
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?
Concise with a clear structure: summary line, usage explanation, then parameter list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown but indicated), so return value details are not needed. Covers main purpose, usage guidance, and all parameters. Could mention that draft status requires explicit publishing, which it does, making it fairly complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description lists all 7 parameters with brief explanations. It clarifies branch naming convention and that description is optional. Adds meaning beyond schema types and titles, though lacks examples.
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 it creates a new pull request in draft mode. It distinguishes from sibling tools like 'create_pull_request' and 'publish_draft_pull_request', making the purpose precise and differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says draft PRs are not ready for review and directs to 'publish_draft_pull_request' for publishing. Also provides branch naming convention assistance. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior with start and limit parameters, but does not mention authentication requirements, rate limits, or side effects. As a read/search operation, idempotency is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement followed by parameter definitions. No superfluous information. The structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal), the description does not need to explain return values. It covers the search and pagination behavior adequately. However, it could mention default sorting or behavior on empty results, but overall it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description provides detailed docstrings for all three parameters: filter (search text), start (page start index, default 0), and limit (results per page, default 25). This compensates for the schema's lack of descriptions and adds meaning beyond type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches for users by partial name, username, or email address. This specific verb+resource combination distinguishes it from sibling tools like search_code or find_file, as it targets user entities.
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 mentions that it returns user details including the slug needed for reviewer fields, which hints at its use case. However, it does not explicitly state when to use or avoid this tool relative to others like list_dashboard_pull_requests, but the context is clear enough for a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return type (flat list of paths) and pagination. No annotations exist, so the description carries the full burden. It lacks details on error handling, permissions, or what happens when a path doesn't exist, but it adequately describes the core 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 efficient: a clear one-line summary, a sentence distinguishing from a sibling, and a well-structured Args list. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) which likely covers return structure, so description needn't repeat. It explains all parameters, pagination, and default branch. Could mention rate limits or error conditions, but overall sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing clear, concise explanations for all six parameters in the Args section, including defaults and semantics beyond their titles.
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 'List file paths in a repository directory (paginated)' and explicitly differentiates from sibling 'browse_files', which returns structured entries. This provides a specific verb and resource with clear distinction.
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 contrasts with browse_files, giving clear guidance on when to use this tool for flat file paths vs structured entries. However, it does not address other siblings like find_file or list branches, which could be similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions pagination and parameter defaults, but does not disclose return format, authentication needs, or any side effects.
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 one line of purpose followed by a clear parameter list, with no extraneous content. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple listing tool with pagination and an output schema, the description covers purpose, required parameter, pagination behavior, and defaults. It is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates fully by explaining each parameter (project_key, start, limit) with defaults and max value, beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all repositories in a project (paginated)', specifying the verb and resource. It distinguishes from sibling tools like list_projects and list_branches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when listing repositories in a project, but does not explicitly state when to use this tool vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the optimistic locking behavior via the version parameter and explains that leaving fields empty or None means keep current. It does not mention potential side effects like notifications or draft status implications, but for a straightforward update tool the transparency is adequate.
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 well-structured: a brief introductory sentence followed by a clear parameter list. With 9 parameters, the list is necessary but not overly verbose. It is front-loaded with the purpose. Minor room for improvement: could combine the parameter list into a more compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: what the tool does, the required version parameter, and the behavior of optional parameters. It does not need to describe the output schema. It could mention that project_key, repo_slug, and pr_id identify the repository and pull request, but the schema already provides those as required fields. Overall, it is fairly complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage with no parameter descriptions. The description compensates by listing all arguments and explaining each one's meaning and behavior (e.g., 'Current version of the PR (required for optimistic locking)', 'New description (None to keep current, empty string to clear)'). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a pull request's title, description, reviewers, target branch, or draft status.' It specifies the verb 'Update' and the resource 'pull request', and lists the specific attributes that can be modified. This distinguishes it from sibling tools like update_pull_request_comment and update_pull_request_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when updating any of the listed PR fields. It also explains the requirement for the version parameter for optimistic locking and advises to get it from get_pull_request. However, it does not explicitly state when not to use it or contrast with alternatives like approve or merge PR tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions pagination but does not disclose read-only nature, permissions, rate limits, or response format. The output schema exists but description does not add behavioral context beyond basic listing.
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 very concise: a single sentence summarizing the tool's purpose, followed by a clean parameter list. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which documents return values), the description covers all necessary aspects: purpose, parameters, pagination, and filtering. It is complete for a list-like tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by providing one-line explanations for each parameter (e.g., 'Optional branch, tag, or commit'). This adds meaning beyond schema types and defaults, though could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List) and resource (commits in a repository), specifies pagination, and optional filters. It distinguishes from sibling tools like get_commit which retrieves a single commit.
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 indicates when to use the tool (to list commits with optional filters) but does not explicitly exclude alternatives or provide when-not-to-use guidance. However, the name and context make it clear it's for listing, while siblings are for single commits or diffs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description accurately describes pagination, filtering by state and role, and the scope across all repos. It does not mention rate limits or auth, but for a read-only list tool, the behavioral coverage is good.
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 begins with a clear one-line summary, then provides concise parameter documentation in a structured format. No extraneous information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, list operation), the output schema exists, so return values need no explanation. The description covers all input parameters and pagination, making it complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 0%, the description adds full meaning to all 6 parameters, including possible values for state and role, default values, and the format for closed_since. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists pull requests visible to the authenticated user across all repositories, distinguishing it from repo-specific list functions. The verb 'list' and resource 'dashboard pull requests' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a dashboard view across all repos but does not explicitly differentiate from sibling tools like list_pull_requests or list_inbox_pull_requests. No when-not-to-use guidance is provided.
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?
Description discloses that it returns PRs needing review, explaining the inbox concept. It does not detail ordering or edge cases, but as a read-only list operation with no annotations, it sufficiently informs 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?
Description is concise and well-structured: front-loaded purpose, then inbox explanation, then parameter details. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description adequately explains what the tool returns (list of PRs needing review). It is complete enough given the tool's simplicity and the context signals (3 params, no required params).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes an Args section explaining each parameter (role, start, limit) and their defaults, adding value beyond the schema's bare definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists pull requests in the authenticated user's inbox that need review action. It explains what the inbox contains (PRs where user is reviewer and not yet completed review), distinguishing it from general PR listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies the context: PRs needing review action, implying when to use (to see pending reviews). It does not explicitly mention alternatives or when not to use, but the sibling tools (list_pull_requests, list_dashboard_pull_requests) provide differentiation.
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-server-mcp MCP server](https://glama.ai/mcp/servers/ManpreetShuann/bitbucket-server-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ManpreetShuann/bitbucket-server-mcp)

Score Badge

Copy to your README.md:

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

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