Skip to main content
Glama
zix-chen
by zix-chen

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AGENT_WORKSTATION_HTTP_TOKENNoBearer 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

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 19 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues