Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CROSS_AGENT_PROJECTNoUnder Codex, the project the server serves. Set to the project path when starting Codex, e.g. CROSS_AGENT_PROJECT="$PWD" codex.

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
describe_modeA

The active mode's loop text, its roles with their workspace, sandbox default and prompt, its git policy, and projectRoot, the root of the project this server serves. Call this first: it is how a launcher learns the loop, which is served rather than copied. review carries the loop's two settings, limits.planReviewRounds and review.afterResolver.

list_rolesC

The roles the active mode has: each one's workspace and the sandbox profile it will run under, with the engine, model and effort .cross-agent/config.json binds it to — or binding: null where it binds none, which is the engine a delegate call must name itself. A role bound to a list is answered as seats, each with its own engine, model, effort and sandbox.

delegateC

Launch a specialist for a role on a brief in a working directory, returning its task id. Validates the role, the workspace, its reservation, duplicates and the resume binding first. A role with no binding takes its engine in the call; worktree: true gives a role that works at the project root a writable task worktree of its own instead. A role bound to a list of bindings is delegated by seat, 1-based.

waitB

Wait for a task to settle, for its engine to go quiet for the configured stall threshold, or for the timeout, and answer with the call to make next. A lead may wait only on a task it delegated.

checkC

The status of a task, how long it has been running, and the last lines of its engine's own event stream. Reconciles nothing, and records the stall or the revival its clock reads.

resultB

The final message of a settled task in full, with the engine session it ran under. A task still running answers with its status.

cancelA

Terminate a task and every task it delegated, leaves first, returning one outcome per task. A lead may cancel only its own.

list_tasksC

Every task of this project after a reconciliation pass, newest first, with the records no reader could judge.

verify_worktreeC

Verify a linked worktree and its exact branch, returning canonical Git and worktree paths or a refusal reason.

git_mutateB

Run one git subcommand in a verified worktree, under the project's locks and journaled. The only path that writes a worktree's git metadata; the workspace and branch default to the mode's own git policy.

git_rootA

Run one whitelisted git verb at the project root, under the project's git lock and, for a verb that changes the repository, the repository's own lock, and journal the step it completes. A merge --ff-only refuses a head without a tested step (unless testCommand is none), and for a team task in a gating mode, without every seat's clean review or a waiver. The verbs are worktree add -b, worktree remove, branch -d, merge --ff-only, rebase --abort, and the read-only status, log, rev-parse, rev-parse --abbrev-ref HEAD, merge-base, branch --list and worktree list; a verb that journals a step names the slug whose journal it belongs to.

run_commandA

Run this project's configured test or setup command — by selector, never as a command string — at the project root or for a verified worktree, returning the exit code and the last 64 KB of its output. Worktree tests run in a detached checkout of the branch head under .cross-agent/gate/ and journal tested on success. A passing test run at the root after the merge journals the slug's tests-passed step.

waive_reviewB

Record the waiver of the merge's review guard for a task's branch head, as a review-waived step in its journal: git_root merge then takes that head without every seat's clean review. The commit must name the branch head as it stands. The operator's, and a lead's only under review.afterResolver lead-decides once every seat has finished its review of that head.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.1/5.0

Scored across 13 tools

Disambiguation4/5

Most tools target distinct resource+action pairs, but the task-inspection cluster (wait, check, result, list_tasks) has some conceptual overlap, and git_mutate vs git_root differ mainly by scope rather than action. Descriptions do clarify the boundaries (wait = block until settle, check = status snapshot, result = full final message), so an agent can generally choose correctly.

Naming Consistency3/5

The set mixes compound verb_noun names (list_roles, list_tasks, verify_worktree, git_mutate, run_command, waive_review) with bare verbs/nouns (delegate, wait, check, cancel, result) and a describe_mode outlier. It remains readable, but there is no single predictable pattern.

Tool Count4/5

13 tools is a reasonable scope for an orchestration server covering mode/role discovery, task lifecycle, git, worktree, and review concerns. Each tool earns its place, though the inspection tools are slightly numerous for their overlap.

Completeness4/5

Coverage is strong: role/mode discovery, full task lifecycle (delegate, wait, check, result, cancel, list_tasks), worktree verification, git mutation at both root and worktree, test execution, and review waiver. Gaps are minor, e.g. no obvious tool for reading or replying within a running task's stream beyond check.

Maintenance

ActivityMaintained
ResponsivenessNo issues