List pull requests in a Bitbucket repository, optionally filtered by state (open, merged, declined, superseded).
List pull requests in a repository, optionally filtered by state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| maxItems | No | ||
| repoSlug | Yes | Repository slug, e.g. 'my-repo' | |
| workspace | No | Omit to use the configured default workspace |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates a read-only listing action, which the readOnlyHint and idempotentHint already communicate. It adds no extra context about pagination behavior, default filtering, return contents, or other effects, so the annotation's safety profile is the main source of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of one sentence with only 12 words and fronts the essential action and scope. It contains no padding or redundant material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description communicates the primary task, but it does not explain the default state behavior, maximum result count, or return shape in the absence of an output schema. The annotations handle safety, yet a bit more context about pagination or defaults would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds meaning to 'state' by calling it an optional filter, which the schema expresses only through an enum. However, maxItems is not explained and workspace is only described in the schema, so the description does not fully compensate for the missing parameter-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('List'), resource ('pull requests'), and scope ('in a repository') and notes the optional state filter. It is clear and distinguishes from single-PR tools like bitbucket_pull_request_get, though it does not explicitly contrast with bitbucket_pull_request_list_by_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but gives no guidance on when to choose it over alternatives such as bitbucket_pull_request_get or bitbucket_pull_request_list_by_user. It does not state any conditions, prerequisites, or exclusion rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.