Skip to main content
Glama
Sign In
codebugs

codebugs

by faxik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mark_branch_only

Flag a code item as branch-only to track work not yet integrated. Specify the item reference and Git branch to record its status.

Instructions

Flag an item as living on a feature branch (not yet integrated). Called by worktree-setup.sh when a branch is created.

Args:

  • item_ref: The item id (e.g. CB-5).

  • branch_name: Git branch holding the work.

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": {
      "item_ref": "<item_ref>",
      "branch_name": "<branch_name>"
    },
    "name": "mark_branch_only"
  }
}

Input Schema

NameRequiredDescriptionDefault
item_refYes
branch_nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of disclosure. It explains the semantic effect (marking an item as unintegrated branch-only work), but does not mention idempotency, overwrite behavior, preconditions, or whether the flag can be reversed by mark_integrated.

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

Conciseness5/5

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

The description is compact and front-loaded: purpose in the first sentence, trigger in the second, then a short args list. Every sentence contributes information without repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-required-parameter flagging tool with an output schema, the description covers purpose, trigger, and both arguments. It lacks only minor context about edge cases like re-marking an already flagged item or the inverse operation, which are useful but not essential.

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 explain parameters, and it does: item_ref is an item id with an example (CB-5) and branch_name is the Git branch holding the work. It adds real meaning beyond the bare schema property names, though branch_name formatting/constraints are not 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 opening sentence uses a specific verb ('Flag') and resource ('an item') and adds the state 'living on a feature branch (not yet integrated)', which clearly distinguishes it from the sibling mark_integrated. The operation is unambiguous even before reading the args.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names a concrete trigger: 'Called by worktree-setup.sh when a branch is created.' This gives clear context for when the tool is relevant, though it does not explicitly list when not to use it or name mark_integrated as the inverse alternative.

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