Agent Workstation
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_WORKSTATION_HTTP_TOKEN | No | Bearer token for the optional loopback HTTP listener. Supply a random 32+ character secret through your process supervisor/secret manager. Required when using --transport http; startup refuses an absent or short token. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| server_infoA | Return server, workspace, project-context, auth, policy, and fixed-tool metadata. |
| check_exec_environmentA | Return lightweight exec_command sandbox and environment status known to the server. |
| read_fileB | Read a UTF-8 text file slice inside the configured workspace. |
| list_dirC | List directory entries inside the configured workspace. |
| list_filesC | List workspace files using glob filters. |
| search_textC | Search UTF-8 workspace files for text or regex matches. |
| apply_patchA | Stage, validate, and atomically apply a V4A patch envelope. Each hunk locates itself by its context, so the context must be unique in the file; when it is not, add a scope header (@@ def my_function) naming the enclosing block, or add '*** End of File' to anchor the hunk at the end. A blank context line may be written as "" or as a single space. Matching is graded exact, then ignoring trailing whitespace, then ignoring indentation width, and the grade actually used comes back as match_quality. Success returns each file's revision, total_lines, and changed_ranges. Several updates to one path in one envelope chain in order. Full format reference: docs/tools-and-schemas.md. Example: *** Begin Patch *** Update File: app.py @@ -old +new *** End Patch |
| apply_changesA | Apply line-addressed file changes atomically. Prefer this over apply_patch when you know the line numbers: nothing has to match. Each change names an action (create, write, edit, delete, move, copy), and a path. write is an upsert: it needs the revision read_file reported when the path exists, but may omit it when creating a missing path. edit, delete, move, and copy always need that revision; create rejects it and asserts absence. edit takes line operations (replace, delete, insert_after, insert_before) whose numbers all refer to the file as read, not to the result of earlier edits in the same call. content is whole lines: "" is zero lines and a trailing newline adds a blank line. One path per call; use apply_patch to chain several edits onto one file. Example: {"changes":[{"action":"edit","path":"app.py","revision":"","edits":[{"op":"replace","start_line":10,"end_line":12,"content":"new line"}]}]} |
| exec_commandA | Run a bounded command under runtime policy. Pass workdir explicitly for reconnect-safe paths. yield_time_ms is only how long this call waits (default 10s); timeout_ms is the total process lifetime (default 300s). A command still running when the call returns keeps running under its command_id; poll it with write_stdin or read_output. Example: {"cmd":"pytest -q","workdir":".","yield_time_ms":30000}. Retained output is bounded per stream; for very large output redirect to a file (cmd > out.log 2>&1) and page it with read_file or search_text. |
| write_stdinB | Poll or interact with a running command by command_id. Empty chars wait for output; non-empty chars writes to stdin. Example: {"command_id":"abc","chars":"","yield_time_ms":10000}. |
| kill_commandC | Terminate a server-managed command by command_id. Example: {"command_id":"abc","signal":"KILL"}. |
| read_outputA | Read retained command output using an output_ref returned by exec_command/write_stdin. Each stream retains the earliest output (head) plus the most recent output (rolling tail); bytes between them may be evicted and are reported via evicted_gap_bytes. Example: {"output_ref":"command:abc:stdout","offset":0,"limit":4096}. |
| git_statusB | Return git working tree status for the workspace. |
| git_diffB | Return unified git diff for workspace changes. Untracked files are included as additions by default, so a newly created file is verifiable here. |
| git_logC | Return recent git commits with bounded structured metadata. |
| git_showC | Return bounded git show output for a revision. |
| git_blameC | Return bounded git blame metadata for a workspace file. |
| view_imageC | Return a workspace image as MCP image content. |
| workspace_guideA | Find applicable repository instructions and skill metadata for a target path. Read the selected full files before acting; no execution or permission grant. |
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 19 tools
Most tools have clearly distinct resource+action purposes, such as file reading/listing/searching versus command execution and Git inspection. The main overlap is between apply_patch and apply_changes, which both modify files and could require an agent to read descriptions carefully before choosing one.
Tool names consistently use snake_case and mostly follow predictable prefixes such as read_, list_, search_, apply_, git_, and exec_. Minor deviations exist (server_info and workspace_guide are noun-based rather than verb_noun), but the naming remains readable and coherent.
The 19 tools fit a broad workspace-agent scope covering file operations, patching, command execution, process management, Git inspection, image viewing, and guidance. It is slightly on the heavy side relative to a typical 3-15 tool server, but each cluster addresses a real capability.
The surface covers core workspace lifecycle operations: read/list/search, create/write/edit/delete via apply_changes, patching via apply_patch, command execution and management, and key Git read operations. Minor gaps such as dedicated Git commit/stage tools or simple directory metadata operations can be handled through exec_command, so the set is largely complete for its purpose.