Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
cwdNoWorking directory for child agents when no workspace root is provided

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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
cs_agent_capabilitiesA

Call first when considering delegation or heterogeneous execution. Lists configured local agent names, optional live availability probes, facade tools, and execution limits so you can decide whether and how to delegate.

cs_agent_createA

Create a managed child agent for a self-contained subtask that benefits from parallel work, a different agent runtime, specialization, or independent review. Call cs_agent_capabilities before choosing an agent; do not delegate trivial or tightly coupled work.

cs_agent_listA

Inspect managed agents in the caller's delegation subtree before creating duplicates or when coordinating parallel work. Supports filtering and cursor pagination; it cannot reveal sibling or ancestor subtrees.

cs_agent_statusA

Inspect one managed agent's lifecycle, queue, pending permission, last error, and runtime state. Use it to diagnose a delegated task before deciding to wait, respond to permission, cancel, or retry.

cs_agent_eventsA

Read or briefly wait for structured delegation events after an opaque cursor. Use for progress monitoring across agents or turns when a reply-oriented cs_agent_wait_message call is not sufficient.

cs_agent_sendA

Assign a self-contained task to a managed descendant agent. Include the objective, scope, constraints, expected deliverable, and verification criteria; the idempotency key makes retries safe. For parallel work, send all independent turns before waiting with cs_agent_wait_many.

cs_agent_get_messageA

Read one immutable delegated request or reply message when you already have its id. Use cs_agent_wait_message instead when waiting for an unfinished task.

cs_agent_wait_messageA

Preferred blocking wait after cs_agent_send for one turn. For multiple turns, send all independent turns first and use cs_agent_wait_many. Returns a terminal reply, a permission request requiring cs_agent_respond_permission, a terminal turn without a reply, or a bounded timeout.

cs_agent_wait_manyA

Wait for multiple turns after you send all independent turns first. Mode any returns all currently ready items; mode all waits until every turn is terminal but returns early for permissions or timeout. Accumulate ready items by turnId and continue with pendingTurnIds after an interrupted all wait.

cs_agent_get_turnA

Read one immutable-point-in-time turn snapshot by id. Use it for detailed state, revision, error, and permission diagnostics without waiting.

cs_agent_wait_turnA

Wait for a turn revision, permission request, or terminal state. Use this instead of cs_agent_wait_message when state transitions matter more than reply content.

cs_agent_respond_permissionA

Resolve a pending permission request surfaced by wait or status. Apply least privilege: prefer one-time approval unless repeated access is explicitly intended; rejection or cancel can stop delegated work.

cs_agent_cancelA

Cancel obsolete, unsafe, or no-longer-needed queued or active work, including unfinished descendant turns. This is a destructive control action; inspect status first when the outcome is uncertain.

cs_agent_destroyA

Destroy a managed agent after its work is complete or abandoned, optionally cascading through descendants and discarding its session. This releases the managed lifecycle and is destructive.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 14 tools

Disambiguation4/5

Tools have clearly distinct roles with detailed descriptions, but the multiple wait/read variants (wait_message, wait_turn, get_message, get_turn, events) create some overlapping surface that could cause misselection without careful reading.

Naming Consistency4/5

All tools share the cs_agent_ prefix and use consistent lowercase_with_underscores, but the verb pattern is mixed: some are bare verbs (create, list, send, cancel, destroy) while others are verb_noun (get_message, wait_turn). This is still predictable and readable.

Tool Count5/5

14 tools is well within the optimal range and each tool serves a distinct need in the delegation lifecycle: capabilities, creation, messaging, waiting, permissions, cancellation, and destruction. The count feels appropriate for the domain.

Completeness4/5

The lifecycle is well covered: create, list, status, send, wait, cancel, destroy, plus capability discovery and permission handling. Minor gaps exist such as no explicit update_agent or non-turn messaging tool, but these are likely out of scope and core workflows are fully supported.

Maintenance

ActivitySlowing
ResponsivenessNo issues