Skip to main content
Glama
Sign In
Bitbucket MCP Server

Bitbucket MCP Server

by pdogra1299
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

manage_comment

DestructiveIdempotent

Edit, delete, resolve, or reopen Bitbucket PR comments and tasks, or convert between them. Supply a version to make writes conditional and prevent overwrites.

Instructions

Edit/delete/resolve/reopen a PR comment or task, or convert between comment and task (to_task/to_comment are Server-only). Pass version (from get_pull_request output) to save a fetch (Server).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>",
      "repository": "<repository>",
      "pull_request_id": "<pull_request_id>",
      "comment_id": "<comment_id>",
      "action": "<action>"
    },
    "name": "manage_comment"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoNew text (edit only)
actionYes
versionNoEntity version from a prior read; supplying it saves a fetch AND makes the write conditional — it fails on concurrent modification instead of overwriting. Omit to write against the latest state (auto-retried once).
workspaceYesProject key (e.g., PROJ)
comment_idYes
repositoryYesRepository slug
pull_request_idYesPull request ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.1

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows delete is irreversible and repeats are safe. The description adds that version enables a conditional write that saves a fetch, but the detailed concurrency behavior (fails on concurrent modification, auto-retry when omitted) lives in the schema, not the description. The parenthetical '(Server)' is unexplained jargon that adds ambiguity rather than clarity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the operation list front-loaded, so the agent gets the core capability immediately. The trailing '(Server)' qualifier is compressed to the point of being cryptic and slightly undercuts the otherwise clean structure.

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 7-parameter destructive mutation tool with no output schema, the description covers operations and the version/optimistic-concurrency angle but omits consequences: whether delete is permanent, whether task conversion alters linked entities, and what a successful call returns. The recurring, unexplained '(Server)' tag leaves an unresolved ambiguity an agent cannot act on.

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 71%, and the description compensates by mapping each enum value to a concrete operation (edit/delete/resolve/reopen/to_task/to_comment), which the schema does not do since enum values carry no per-value descriptions. It also explains that version should come from get_pull_request output, adding provenance the schema lacks; text and comment_id remain undocumented in the description but are covered by 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 opens with a specific set of verbs (edit/delete/resolve/reopen/convert) applied to a clear resource (PR comment or task), which is far more precise than the tool name alone. It implicitly distinguishes itself from add_comment by framing all operations as mutations of an existing comment, though it never names that sibling 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?

Usage is implied through the action enumeration, and the note that to_task/to_comment are Server-only is a genuine usage restriction. However, there is no explicit guidance on when to reach for this tool versus add_comment or set_review_status, and no preconditions (permissions, comment ownership) are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools