LocalForge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_contextB | Return high-signal project structure, Git state, docs, and current work handoff. |
| list_directoryB | List a bounded absolute local directory. |
| read_fileB | Read an allowed text file or line range. |
| search_codeC | Search text or symbols below an absolute project directory. |
| apply_patchB | Create, update, or delete multiple project files with conflict-aware preflight. |
| shellC | Run a non-interactive local command; cwd must be an absolute local path when provided. |
| process_statusB | Read status of a LocalForge background child process. |
| process_stopB | Stop a LocalForge background child process. |
| run_pythonB | Run Python automation in dev mode or restricted analysis in safe mode. |
| git_statusA | Return structured branch, HEAD-related dirty, staged, and untracked Git state. |
| git_diffB | Inspect working-tree/staged changes or compare two revisions. |
| git_logC | Return bounded recent commit history. |
| git_showB | Show one Git revision with bounded patch output. |
| work_statusB | Read current TASK/RESULT handoff files and status summary. |
| work_updateC | Update the local ignored handoff with task, result, or checkpoint content. |
| validateC | Run explicit commands and a reliable baseline-to-post-command scope check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools have clearly distinct resource/action targets, but shell, run_python, and validate all execute commands and can be confused; project_context also partially overlaps git_status by returning Git state. The descriptions do help separate their intended uses, so ambiguity is limited.
Nearly all tools use snake_case with clear domain prefixes such as git_, process_, and work_, making the set predictable. Minor deviations include noun-first forms like git_status/work_update and the lone validate, but naming remains readable and consistent overall.
At 16 tools, the server is slightly above the ideal 3-15 range but still well-scoped for a local development/code-agent environment. File, execution, process, Git, handoff, and validation capabilities each justify their place without obvious filler.
The surface covers file listing/reading/searching/editing, command execution, process status/stopping, Git inspection, work handoff, and validation. Minor gaps exist around Git write operations (commit/push) and explicit process start/list, but most workflows can be completed through shell or apply_patch.