Allows exposing the local Git server to the internet via Cloudflare Tunnel (cloudflared).
Allows exposing the local Git server to the internet through ngrok tunnels for remote access.
LGH (LocalGitHub) is a lightweight local Git hosting service. It wraps git http-backend to provide GitHub-like HTTP access, running entirely on localhost - turning your local directory into a Git server.
🚀 Lightweight - Single binary, no external dependencies
🔧 Easy to Use - Intuitive CLI commands, one-click repository setup
🌐 HTTP Access - Standard Git HTTP protocol, compatible with all Git clients
🔒 Authentication - Built-in Basic Auth with salted password hashing
🛡️ Read-Only Mode - Optional read-only mode to protect repositories
📡 mDNS Discovery - Automatic LAN discovery for team collaboration
🌍 Tunnel Support - One-click expose to internet (ngrok, cloudflared)
⚡ Smart Archival (v1.2.0) - lgh up / lgh save commands with auto .gitignore
🤖 MCP Server (v1.2.0) - AI Agent integration (Cursor, Claude Desktop)
Related MCP server: my-local-mcp
Download the pre-built binary for your system — these links always point to the latest release:
OS | Architecture | Download |
macOS | Apple Silicon (M1/M2/M3) | |
macOS | Intel | |
Linux | x86_64 | |
Linux | ARM64 | |
Windows | x86_64 |
# Install after download (macOS ARM64 example)
chmod +x lgh-darwin-arm64
sudo mv lgh-darwin-arm64 /usr/local/bin/lghDownload lgh-windows-amd64.exe
Rename to lgh.exe
Move to a folder in your %PATH% (e.g., C:\Program Files\lgh\)
Run in PowerShell or Command Prompt
# Install
curl -sSL https://raw.githubusercontent.com/JoeGlenn1213/lgh/main/install.sh | bash
# Uninstall
curl -sSL https://raw.githubusercontent.com/JoeGlenn1213/lgh/main/uninstall.sh | bash# Add tap
brew tap JoeGlenn1213/tap
# Install
brew install lgh
# Uninstall
brew uninstall lghgit clone https://github.com/JoeGlenn1213/lgh.git
cd lgh
make build
sudo make install
# Or manually
go build -o lgh ./cmd/lgh/
sudo mv lgh /usr/local/bin/go install github.com/JoeGlenn1213/lgh/cmd/lgh@latestlgh initThis creates the necessary directories and config files in ~/.localgithub/.
# Start in foreground
lgh serve
# Start in background (daemon mode)
lgh serve -d
# Check server status
lgh status
# Stop the server
lgh stopServer listens on http://127.0.0.1:9418 by default.
The fastest way to host a local project:
cd your-project
lgh add . --pushThis single command will:
Initialize a Git repo (if not already one).
Auto-Commit all files (if the repo is empty).
Register it with LGH.
Auto-Push to the server immediately.
If you prefer manual control:
lgh add .
# Then push manually later
git push -u lgh mainThe fastest way to backup and sync your code:
# One-click: auto .gitignore + add + commit + push
lgh up "commit message"
# Local save only (no push)
lgh save "WIP: work in progress"Smart Ignore automatically:
Detects project type (Python, Go, Node, Java, Rust, AI/ML)
Generates appropriate .gitignore file
Blocks large files (>50MB) and sensitive files (.env, *.key)
(v1.2.3+) When used via MCP, returns exact triggered_job_ids: [...] array, allowing AI to track pipeline status with zero blind spots
After adding, you can use standard Git commands:
git push lgh main
# or
git pushgit clone http://127.0.0.1:9418/your-project.gitCommand | Description | Example |
| Initialize LGH environment |
|
| Start HTTP server |
|
| Stop running server |
|
| Add repository to LGH |
|
| List all repositories (detailed) |
|
| View server status and repo list |
|
| Remove repository (use status/list first) |
|
| Expose to internet |
|
| Manage authentication |
|
| Show version |
|
| Check system health |
|
| Check repo connection state |
|
| Switch active remote |
|
| Simple clone from LGH |
|
| View/watch system event logs |
|
| One-click commit and push (MCP returns ActionD triggered_job_ids) |
|
| Local save (no push) |
|
| View server logs |
|
| Start MCP server for AI |
|
LGH provides tools to manage your local repository state without complex git commands.
See exactly which remote you are pushing to:
lgh repo statusEasily switch between LGH and origin (e.g., GitHub):
lgh remote use lgh # Switch upstream to LGH
lgh remote use origin # Switch upstream to Origin# Clone easily (no full URL needed)
lgh clone my-project
# Inspect bare repo details (HEAD, branches)
lgh repo inspect my-project
# Set default branch for bare repo
lgh repo set-default my-project main
# Check system health
lgh doctorTrack system activity and repository changes in real-time.
# View recent events
lgh events
# Watch for new events (like 'tail -f')
lgh events --watch
```bash
# Filter by type
lgh events --type git.pushLGH is designed to be the "source of truth" for AI Agents.
1. Real-time Subscription (Socket)
Connect to the Unix Domain Socket at ~/.localgithub/lgh.sock to receive a real-time stream of JSON events for every action (repo added, git push, etc.).
Protocol: Unix Socket, JSON Lines.
Security: Read-Only. Only the local user can connect.
2. Event Replay (Simulation) Inject past events back into the system to test your Agents without performing real Git actions.
# Replay last 10 events to all connected agents
lgh events replay --last 10
# Replay specific event types
lgh events replay --type git.pushNote: Replayed events include “_replayed”: true in their payload.
# Daemon mode (background)
lgh serve -d
# Read-only mode (disable push)
lgh serve --read-only
# Custom port
lgh serve --port 8080
# Enable mDNS for LAN discovery
lgh serve --mdns
# Bind to all interfaces (LAN access)
lgh serve --bind 0.0.0.0Want to connect LGH to Cursor or Claude Desktop?
Simply update your AI editor's config file (e.g., ~/.cursor/mcp.json) with:
{
"mcpServers": {
"lgh": {
"command": "lgh",
"args": ["mcp"]
}
}
}Run this single command to install the latest binary:
curl -sSL https://raw.githubusercontent.com/JoeGlenn1213/lgh/main/install.sh | bashOnce installed, follow the "Scenario 1" step. We designed LGH as a single binary, so you don't need a separate "MCP Plugin". The lgh binary IS the MCP server!
Ask your AI Agent:
"Check LGH status" If it calls
lgh_statusand responds, you're all set!
# Custom name
lgh add . --name custom-name
# Don't auto-add remote
lgh add . --no-remoteEnable authentication when sharing repositories over the network:
# Interactive setup (hidden password input)
lgh auth setup
# View auth status
lgh auth status
# Generate password hash (for manual config)
lgh auth hash
# Disable auth
lgh auth disable# Method 1: URL embedded credentials
git clone http://username:password@192.168.1.100:9418/repo.git
# Method 2: Use Git credential helper
git config credential.helper store
git clone http://192.168.1.100:9418/repo.git
# Enter username/password on first accessScenario | Recommended Config |
Local development | Default config (127.0.0.1) |
LAN sharing |
|
Internet exposure | Reverse proxy (Caddy/Nginx) + TLS + Auth |
⚠️ Security Note: Password must be at least 8 characters. Config file stores salted hash, not plaintext.
See docs/SECURITY.md for detailed security guidelines.
~/.localgithub/
├── config.yaml # Global config
├── mappings.yaml # Repository mappings
├── lgh.pid # Server PID file
└── repos/ # Bare repository storage
├── MyApp.git/
└── ProjectB.git/~/.localgithub/config.yaml:
port: 9418
bind_address: "127.0.0.1"
repos_dir: "/Users/you/.localgithub/repos"
read_only: false
mdns_enabled: false
# Authentication (optional)
auth_enabled: true
auth_user: "git-user"
auth_password_hash: "salt:hash..."LGH supports multiple ways to expose your local service to the internet:
# Show all available tunnel methods
lgh tunnel
# Use ngrok
lgh tunnel --method ngrok
# Use Cloudflare Tunnel
lgh tunnel --method cloudflared
# SSH reverse proxy
lgh tunnel --method ssh⚠️ Security Note: Always enable authentication (
lgh auth setup) or use a reverse proxy before exposing to the internet.
# 1. Setup auth
lgh auth setup
# 2. Bind to all interfaces with read-only mode
lgh serve --bind 0.0.0.0 --read-only --mdns
# 3. Access from other devices (requires auth)
git clone http://username:password@your-hostname.local:9418/repo.git# 1. LGH listens on localhost only
lgh serve
# 2. Use Caddy reverse proxy + auto HTTPS
# Caddyfile:
# git.example.com {
# basicauth * {
# user $2a$14$...
# }
# reverse_proxy localhost:9418
# }# Temporarily expose for GitHub Actions
lgh auth setup
lgh tunnel --method ngrok &
# Use ngrok URL + credentialsFeature | LGH | GitLab | Gitea | git daemon | File Sharing |
Setup Complexity | ⭐ Single binary | ❌ Needs database | ⚠️ Needs config | ⭐ Simple | ⭐ No install |
HTTP Protocol | ✅ | ✅ | ✅ | ❌ | ❌ |
Authentication | ✅ Optional | ✅ Required | ✅ Required | ❌ | ❌ |
Web UI | ❌ | ✅ | ✅ | ❌ | ❌ |
Resource Usage | ⭐ <10MB | ❌ >1GB | ⚠️ ~100MB | ⭐ <5MB | ⭐ None |
Startup Time | ⭐ <1s | ❌ >30s | ⚠️ ~10s | ⭐ <1s | ⭐ Instant |
LAN Discovery | ✅ mDNS | ❌ | ❌ | ❌ | ✅ |
Use Case | Local/Temp | Enterprise | Team | Simple share | File transfer |
LGH's Position: Fills the gap between "simple file sharing" and "full Git platform".
# Run all tests
go test ./... -v
# Run integration tests
go test ./test/... -v
# Skip long-running tests
go test ./... -v -shortGo 1.23+ (for building)
Git (runtime)
macOS, Linux, or Windows
Contributions are welcome! See CONTRIBUTING.md for details.
Fork the repository
Create feature branch (git checkout -b feature/amazing-feature)
Commit changes (git commit -m 'Add amazing feature')
Push to branch (git push origin feature/amazing-feature)
Create Pull Request
This project is licensed under the MIT License - see LICENSE file.
spf13/cobra - CLI framework
spf13/viper - Configuration management
fatih/color - Terminal coloring
hashicorp/mdns - mDNS support
Register a local Git repository with LGH local server. This creates a bare repo on LGH and adds 'lgh' remote to the source repo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional custom name for the repository on LGH | |
| path | Yes | Absolute path to the LOCAL working directory containing the Git repository |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses side effects: 'creates a bare repo on LGH and adds 'lgh' remote to the source repo.' This is transparent about the modifications performed, and the destructiveHint annotation aligns with changing the repository configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences—with the verb 'Register' front-loaded. It conveys the essential functionality without unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling list and the explicit side-effect explanation, the description is complete for an agent to understand what lgh_add does and when to use it. No output schema is needed for this command-like tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both 'path' and 'name', achieving 100% coverage. The tool description adds no extra parameter context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Register a local Git repository with LGH local server.' It explains the specific actions and differentiates from siblings like lgh_remove and lgh_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (when you want to add a repository) but does not explicitly mention alternatives or contrast with other tools. No 'use this instead of' guidance is provided, but the purpose is clear enough for basic inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show uncommitted changes in a Git repository. Returns a diff summary and full diff content.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the LOCAL working directory (defaults to current directory) | |
| staged | No | Show only staged (cached) changes (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only diff operation, but the annotations declare readOnlyHint=false and destructiveHint=true, which directly contradicts the non-destructive nature of showing a diff. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short sentences with no redundant content. It states the action and the expected result without extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a reasonable summary of the output by mentioning both a diff summary and full diff content. It is complete enough for an agent to understand the typical result, though it does not specify exact exit codes or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover both parameters (path and staged) with sufficient detail. The tool description adds no further parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing uncommitted changes in a Git repository and returning a diff summary and full diff content. This distinguishes it from sibling tools like status, log, and add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as lgh_status or lgh_log. It does not mention situations like reviewing changes before staging or comparing staged vs unstaged content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all repositories registered with LGH local server. Returns source_path (local working dir) and clone_url (LGH server URL).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional substring filter applied to repository name or source path (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says 'List', implying a read-only operation, but the annotations claim readOnlyHint=false and destructiveHint=true. This directly contradicts the description and is a serious behavioral transparency issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured, using one sentence for behavior and one for output fields with no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and return fields, but lacks output structure details (e.g., array vs object) and possible error/pagination behavior. Given the low complexity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single filter parameter is fully described in the schema, including its optional nature, the fields it applies to, and case-insensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists all repositories registered with the LGH local server and specifies the returned fields (source_path and clone_url), distinguishing it from sibling tools like add/remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear operation but does not explicitly state when to choose this over alternatives such as lgh_status or lgh_log. The purpose is inferable, but explicit usage guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View LGH server runtime logs (errors, warnings, info)
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Filter by log level (DEBUG, INFO, WARN, ERROR) | |
| limit | No | Number of log entries to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'View' logs, implying a read-only operation, but the annotations set readOnlyHint to false and destructiveHint to true. This is a direct contradiction and does not disclose any side effects or destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple log-viewing tool the description is minimal but adequate in basic intent. However, the contradictory annotations and lack of output format or ordering details leave important context missing for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both 'level' and 'limit'. The description adds no additional parameter semantics beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool views LGH server runtime logs and mentions the log types (errors, warnings, info). It is distinct from sibling tools like lgh_status or lgh_up, but does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool for viewing logs, but provides no guidance on when not to use it or how it compares to sibling tools. There is no explicit alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a repository from LGH
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the repository to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive, non-idempotent behavior, and the description matches that. However, the description adds no extra detail about whether the removal is permanent, affects local files, or requires confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations cover destructiveness, but there is no output schema and no description of what happens after removal or whether it can be undone. Some context is missing for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the required 'name' parameter, but the description and parameter description provide no additional meaning beyond the obvious property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('a repository from LGH'), making it easy to distinguish from List or Add. It is terse but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 tool versus siblings like lgh_rollback or lgh_up, nor any mention of prerequisites or alternatives. The description only states the basic removal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rollback the repository to a previous commit. This performs a git reset --hard and optionally force pushes to LGH.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the LOCAL working directory (defaults to current directory) | |
| push | No | Force push to LGH after rollback (default: false) | |
| steps | No | Number of commits to roll back (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly reveals the destructive behavior: 'git reset --hard' and 'optionally force pushes' to LGH. This goes beyond the annotations by specifying the exact Git operations and their consequences, providing clear transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with exactly two sentences, front-loading the core purpose and then detailing the optional push behavior. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description sufficiently explains the operation's inputs and effects. It covers the destructive nature and optional push, though it assumes familiarity with 'LGH' as a target. This is adequate for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (path, push, steps) have descriptive explanations that clarify their meaning and defaults, such as 'absolute path to local working directory' and 'force push to LGH' with default values. The schema coverage is 100%, and the descriptions add practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rollback via git reset --hard) and the optional force push to LGH. It distinguishes itself from sibling tools like lgh_up or lgh_status by explicitly mentioning the destructive nature of a hard reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use rollback versus other operations like lgh_up or lgh_up_dryrun. The description focuses on what it does, not on appropriate usage contexts or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local save only: git add + git commit WITHOUT push. Changes stay in local working directory, not synced to LGH server.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the LOCAL working directory (defaults to current directory) | |
| message | Yes | Git commit message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. The description adds valuable context about the nature of the operation (git add + git commit) and clarifies that changes are not synced to the remote, going beyond the annotation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences—and front-loads the most critical information (local save, no remote sync). Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple git command wrapper, the description provides enough context for correct invocation (e.g., requiring a message, optional path). It does not cover edge cases like needing a git repository, but that is likely obvious from the tool's purpose and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters (path and message) with reasonable descriptions. The tool description adds no additional meaning or constraints beyond what is already in the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (local save via git add + commit), the scope (local working directory), and explicitly contrasts with syncing to the LGH server, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests when to use it (when you want to commit locally without pushing), but it does not explicitly explain when to prefer this over sibling tools like lgh_up or lgh_up_dryrun. The guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the LGH HTTP server in background
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port to listen on (default: 9418) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions background execution, but does not explain consequences such as whether the command returns immediately, how to check status, or what happens if the server is already running. The destructiveHint and idempotent false annotations are not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It states the essential action and mode clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple start command, but lacks helpful context such as how to verify successful startup or how to stop the server. Given the sibling tools, some cross-reference would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, port, is fully documented by the schema with a default value. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (start), the resource (LGH HTTP server), and the mode (in background). It is easily distinguished from the sibling tool lgh_serve_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as lgh_up or lgh_serve_stop. It does not mention prerequisites like checking if the server is already running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the LGH HTTP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action without adding context about side effects (e.g., does it terminate all active connections, is it graceful?). The destructiveHint annotation already covers the destructive nature, but no additional behavioral detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop operation with no parameters and no output, the description is sufficient. It lacks only deeper behavioral context, but that is not critical for the tool's basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so the schema is trivially complete. Baseline of 4 is appropriate because there is nothing to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Stop') and the target ('the LGH HTTP server'). It is unambiguous and easily distinguished from the sibling lgh_serve_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., lgh_serve_start or lgh_status). The intended usage is implied by the name but not explicitly described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get unified health status for LGH and ActionD. Returns running state, PID, address, repo count, and ActionD daemon status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Get' implying a read-only operation, but the annotations declare readOnlyHint=false and destructiveHint=true, which directly contradicts the description. Additionally, idempotentHint=false conflicts with the expected idempotency of a status query. The description also fails to disclose any side effects or security requirements beyond what annotations claim (which are themselves contradictory). This is a serious annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource, then lists the return fields concisely. No fluff or repetition; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does list what is returned, which is helpful. However, the contradiction with annotations (destructiveHint=true, readOnlyHint=false) leaves the agent uncertain about side effects. The description should warn that this operation may be destructive or explain the conflict, but it does not. For a health-status tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description does not need to explain parameters, and it correctly adds nothing. Baseline for 0 params is 4, and the description adds no irrelevant param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'unified health status for LGH and ActionD' and lists the returned fields (running state, PID, address, repo count, ActionD daemon status). This clearly distinguishes it from sibling tools that perform actions (add, remove, save, etc.). No other tool appears to be a status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 tool versus alternatives. It does not mention prerequisites, when to prefer a different tool, or any exclusions. The only implied usage is 'when you need health status,' but this is not explicit and there is no contrast with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-click backup: auto .gitignore + git add + git commit + git push to LGH local server. NOT GitHub/GitLab - this pushes to localhost LGH. If ActionD is running, it will automatically return the list of triggered job IDs (triggered_job_ids) that were spawned by this push.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the LOCAL working directory (defaults to current directory) | |
| force | No | Skip trash detection (large files, .env) and force push | |
| message | Yes | Git commit message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main side effects: auto gitignore, add, commit, and push to localhost, and the possibility of triggering ActionD jobs. This aligns with the destructiveHint and readOnlyHint annotations, though it could further emphasize that it modifies local git history and remote state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, covering the action, target, key exclusions, and conditional output in just a few sentences without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for invoking the tool, including the local LGH target, the one-click workflow, and the conditional return of triggered job IDs. It lacks an explicit output schema but still communicates the expected result well enough for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters (path, force, message) with 100% coverage. The description does not add significant extra meaning beyond what the parameter descriptions already provide, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: one-click backup via git add, commit, and push to a local LGH server, and explicitly distinguishes it from GitHub/GitLab. It also mentions the optional returned job IDs, making the tool's scope easy to understand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool (for one-click backup and push to the local LGH server) and what not to expect (not GitHub/GitLab), but it does not explicitly compare it with sibling tools like lgh_add, lgh_diff, or lgh_up_dryrun, so alternative selection guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dry-run preview of lgh_up: shows pending changed files, trash detection results, and whether the repo is registered with LGH. No files are committed or pushed.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute path to the LOCAL working directory (defaults to current directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'No files are committed or pushed' indicating a non-destructive operation, but the annotation destructiveHint is true. This is a direct contradiction, making the tool's safety profile unclear and misleading to an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose and listing the key outputs. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists what the dry-run shows, but the contradiction between its non-destructive claim and destructiveHint=true undermines trust. It also does not explain how the results should be interpreted or what the 'trash detection results' mean. Given the tool has no output schema, more behavioral detail was needed to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'path' parameter with a clear description, achieving 100% coverage. The tool description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a dry-run preview of lgh_up, listing exactly what it shows: pending changed files, trash detection results, and repo registration status. This distinguishes it from the sibling lgh_up and other lgh tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a preview to run before lgh_up, but it does not explicitly state when to use it versus alternatives or when not to use it. It says 'No files are committed or pushed' which hints at safe usage, but there is no direct guidance like 'use before lgh_up to review changes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0lgh_addlgh_difflgh_listlgh_loglgh_removelgh_rollbacklgh_savelgh_serve_startlgh_serve_stoplgh_statuslgh_uplgh_up_dryrunTools are largely distinct, each covering a specific operation (add/list/remove repos, diff/log/status, save/rollback/up/dryrun, server start/stop). Minor ambiguity: lgh_log could be mistaken for git commit history, but the description clarifies it as server runtime logs.
All tool names follow a consistent lgh_ prefix and snake_case verb pattern (add, diff, list, log, remove, rollback, save, serve_start, serve_stop, status, up, up_dryrun). No mixed conventions or irregular naming.
With 12 tools, the set is well-scoped for a local Git server utility. It covers repository management, commit/push operations, rollback, server control, status, logs, diff, and a dry-run variant without unnecessary redundancy.
The surface covers the core workflow: register, commit, push, rollback, inspect, and manage the server. Minor gaps such as explicit fetch/pull or clone-from-LGH operations are absent, but the toolset appears complete for its intended backup/server use case.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Git-backed platform for skills, tools, and context for AI agents
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoeGlenn1213/lgh'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
