Skip to main content
Glama
Knuckles-Team

Repository Manager

Commit Code

rm_git_commit_code

Commit code changes to Git repositories, running pre-commit hooks and supporting bulk operations across multiple projects.

Instructions

Commit code (rm_git). Typed bulk Git operations; arbitrary host commands are prohibited.

Input Schema

NameRequiredDescriptionDefault
pathNoPath to execute in.
phaseNoStarting phase number for 'phased_push'. Default 1.
job_idNoBackground rm_git job id; required for action='status' or 'cancel'.
commandNoThe Git command to execute for 'raw' action (e.g., 'git status')
messageNoCommit message for 'commit' / 'commit_code' actions.
summaryNoFor action='status': return compact progress by default; false includes full detail.
threadsNoParallel workers for bulk operations.
projectsNoOptional comma-separated list of repository URLs to clone or directory names/paths to pull/push/add/commit.
auto_startNoFor 'phased_push': begin at the lowest phase with unpushed work instead of always 'phase', skipping the inter-phase waits of unchanged upstream phases. Default True; set False to start at 'phase'. Ignored when 'target_project' is set.
run_precommitNoFor 'commit_code': run pre-commit hooks before committing. Default True.
target_projectNoOptional specific project to push for 'phased_push'.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description adds only the bulk scope and a prohibition on host commands, saying nothing about what state is created or lost, whether a commit message is mandatory, how pre-commit hooks affect the outcome (run_precommit defaults true), or how failures across multiple repositories are handled.

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 short sentences, front-loaded with the operation name and immediately followed by the scope constraint. No padding or repetition, though the second clause is more of a namespace-level policy statement than tool-specific guidance.

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

Completeness2/5

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

This is an 11-parameter, multi-repo mutation tool with no required parameters and no output-schema-excused gaps in behavior. The description never explains the bulk commit flow, the relationship to background jobs (job_id), or which parameters govern a commit call, leaving an agent to reverse-engineer intent from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 11 parameters, so the schema carries full parameter documentation. The description adds nothing about parameters, which matches the baseline 3 for a fully-covered schema, but it does not help disambiguate the many parameters that appear redundant for a commit operation (path, projects, message, run_precommit).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Commit code (rm_git)" essentially restates the tool name rm_git_commit_code and the title "Commit Code." The only additive signal is "typed bulk Git operations," which hints at multi-repo scope but does not say what the tool commits, against what, or how it differs from siblings like rm_git_commit or repository_manager_commit_code_project.

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?

No when-to-use guidance is given. The statement that "arbitrary host commands are prohibited" implies raw command execution belongs elsewhere (i.e., rm_git_raw), but no alternative is named and no condition for choosing this tool over rm_git_commit, rm_git_pre_commit, or the repository_manager_commit_* variants is stated. The schema even references action values ('commit', 'commit_code', 'status', 'cancel') that the description never routes the agent through.

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