Skip to main content
Glama
openl-tablets

OpenL MCP Server

Official

Delete Project Branch

openl_delete_project_branch
Destructive

Deletes a project branch from its repository after mandatory safety checks: confirms exact branch name, rejects base or protected branches, and requires explicit acknowledgment of potential data loss.

Instructions

Delete a branch from the repository hosting a project. The tool first reads project-aware branch metadata: a base branch is always rejected, and a protected branch requires force=true plus confirmForce=true (and eligible Studio permissions). It then performs a safe-delete preflight against the repository base branch when the target is the project's current branch. A branch with commits absent from base, unsaved changes, or no authoritative divergence check is rejected unless confirmDataLoss=true explicitly acknowledges the reported risk. confirmBranchName must exactly equal branch. If the project is open on the deleted branch, Studio closes it first. Branch names containing '/' are supported.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoBypass protected-branch restrictions for eligible managers. Default false.
branchYesExact branch name from openl_list_project_branches(). The repository base branch cannot be deleted.
projectIdYesProject ID returned by backend. Use the exact 'projectId' value from openl_list_projects() response without modification or reformatting.
confirmForceNoMust be true when force=true, confirming the protected-branch bypass.
confirmDataLossNoExplicitly allow deletion after the tool reports that the branch has commits absent from the base branch, has unsaved working-copy changes, or its divergence from base cannot be verified (for example, the base is unknown, the merge check fails or checks different branches, or the target is not current). Omit for the initial safe-delete attempt.
response_formatNoResponse format: 'json' for structured, round-trippable data (default), 'markdown' for human-readable output, 'markdown_concise' for a brief summary (1-2 paragraphs), or 'markdown_detailed' for full details with contextjson
confirmBranchNameYesRequired safety confirmation; must exactly equal branch.
Behavior5/5

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

Annotations already flag destructiveHint and openWorldHint, and the description goes well beyond them by disclosing the internal preflight, the exact confirmation gates, the side effect of closing the project if open, and support for slash-containing branch names. No hidden destructive behavior is omitted.

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 dense but each sentence covers a distinct, necessary fact for safely invoking a destructive operation. The purpose is front-loaded, and the safety conditions are ordered logically from metadata check to preflight to confirmations and side effects.

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 destructive seven-parameter tool with no output schema, the description thoroughly covers preconditions, guards, confirmations, and side effects. The only minor gap is that it does not describe what payload or status the tool returns after deletion, which would be useful since no output schema exists.

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 100%, so the baseline is 3, but the description adds relational meaning: force and confirmForce must appear together for protected branches, confirmBranchName must equal branch exactly, and confirmDataLoss acknowledges a reported risk. These relationships are not all explicit in the individual 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 opening sentence names a clear verb and resource ('Delete a branch from the repository hosting a project') and the rest of the description disambiguates this from create/list branch operations by detailing deletion-specific protections. It is unambiguous and distinct from sibling branch 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?

The description gives clear context for when deletion is permitted: base branches are always rejected, protected branches require force plus confirmForce, and unsafe data-loss cases require confirmDataLoss. It does not explicitly name alternative tools, but there is no dedicated alternative deletion sibling, and the conditions effectively state when-not.

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

Install Server

Other Tools

Latest Blog Posts

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/openl-tablets/openl-mcp'

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