Skip to main content
Glama
Knuckles-Team

Repository Manager

Git action

repository_manager_git_action

Run a Git command in a chosen repository directory; descriptor-pinned helpers validate the operation before any subprocess starts.

Instructions

Execute a Git command in the specified directory.

The operation is admitted through descriptor-pinned helpers before any subprocess is started.

Input Schema

NameRequiredDescriptionDefault
envNo
pathNo
quietNo
commandYes
timeoutNo
raw_outputNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds a validation-gate note ('admitted through descriptor-pinned helpers before any subprocess is started'), which is useful context but vague jargon that doesn't explain consequences, permitted commands, or failure behavior.

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

Conciseness3/5

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

Purpose is front-loaded in the first sentence, which is good. The second sentence, while short, is opaque jargon ('descriptor-pinned helpers') that doesn't clearly earn its place for an agent deciding how to call the tool.

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?

For a 6-parameter arbitrary-git-execution tool with no output schema and 0% parameter coverage, the description is too sparse. It omits what commands are permitted, return/error behavior, and safety boundaries an agent needs before invoking an open-world mutation tool.

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

Parameters2/5

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

Schema coverage is 0% across 6 params (env, path, quiet, command, timeout, raw_output). The description only vaguely implies 'path' via 'in the specified directory' and says nothing about env, quiet, timeout, or raw_output, so it fails to compensate for the documentation gap.

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?

States a clear verb+resource ('Execute a Git command in the specified directory'), so the operation is unambiguous. However, it offers no differentiation from the numerous sibling git tools (rm_git_raw, rm_git_commit, rm_git_status, rm_git_push, etc.), leaving the agent to guess which git tool to pick.

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?

There is no guidance on when to use this general git executor versus the many specialized siblings like rm_git_raw or rm_git_commit. No prerequisites, exclusions, or alternative routing are given.

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