PatchLoop
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bashA | Run a shell command in the repository root (/workspace) inside an isolated sandbox with no network. Each call starts a fresh shell: |
| view_fileA | Show a file with line numbers, at most 200 lines per call. Use start_line/end_line to page through longer files; the header tells you the total number of lines. Paths are relative to the repository root. Errors if the file does not exist or the path leaves the repository. |
| searchA | Search file contents with a regular expression (ripgrep syntax) and return up to 50 matches as path:line:text. Use it to find where a function is defined or used before opening files. Optionally restrict to a sub-directory (path) or a file glob such as '*.py'. |
| str_replaceA | Edit a file by replacing one exact occurrence of old_str with new_str. old_str must match the file exactly (including indentation and whitespace) and must occur exactly once; otherwise the tool returns an error with the number of matches, and you should include more surrounding lines to make it unique. On success it shows the edited region. Test files are read-only and cannot be edited. |
| run_testsA | Run the repository's test suite (or a subset) and return a pass/fail summary plus the failure output, truncated. selector is passed to pytest, e.g. 'tests/test_x.py::test_name' or '-k median'. Run this to reproduce the bug first and again after every edit. |
| diffA | Show the current git diff of the sandboxed repository (your changes so far). |
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 6 tools
Each tool has a clear primary role in the edit-test loop, and the descriptions distinguish dedicated tools from the general-purpose bash escape hatch. Some overlap remains because bash can also search, read, and run tests, but the guidance to use the specialized tools first keeps confusion limited.
All names use lowercase snake_case and are readable. The set is mostly consistent, though it mixes action-style names like search, run_tests, and view_file with command/noun-style names like diff and bash.
Six tools is well scoped for a sandboxed code-repair workflow: find, read, edit, test, inspect, and shell. Each tool has a clear purpose and none feels redundant or excessive.
The surface covers the full core lifecycle for bug fixing: searching code, viewing files, editing, running tests, checking diffs, and falling back to shell commands. Missing edge operations like file creation or deletion are handled through bash, so there are no dead ends.