Skip to main content
Glama

sandbox_git_branch

List, create, or switch git branches in an E2B sandbox repository to manage development workflows.

Instructions

Manage git branches: list, create, or switch branches in a sandbox repository.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sandboxIdYesThe sandbox ID.
repoPathYesPath to the git repository.
actionYes"list" to show branches, "create" to make a new branch, "checkout" to switch branches.
branchNameNoBranch name (required for "create" and "checkout" actions).
Behavior3/5

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

No annotations are provided, so the description must convey behavior. It does state the three actions and that branchName is required for create/checkout, but doesn't disclose side effects like whether switching branches causes file changes, or if listing shows remote/ local branches.

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 verb 'Manage'. Every word contributes, though it could be improved by removing 'in a sandbox repository' since that's implied by the tool name.

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 tool with 4 parameters, no output schema, and no annotations, the description covers the actions but lacks details on return values (e.g., a list of branches), error cases, or behavior when branchName is omitted incorrectly.

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% and description adds value by clarifying the action enum and branchName dependency. The branchName requirement for specific actions is well 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?

The description specifies the tool manages git branches with three actions (list, create, checkout), clearly indicating what it does. However, it doesn't differentiate from sibling git tools like sandbox_git_clone or sandbox_git_push, which operate on branches too but with different verbs.

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 vs other git tools. No mention of prerequisites (e.g., sandbox must exist, repo must be initialized) or alternatives.

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/asif-nvc/e2b-sandbox-mcp'

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