Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tasks
{
  "list": {},
  "cancel": {},
  "requests": {
    "tools": {
      "call": {}
    },
    "prompts": {
      "get": {}
    },
    "resources": {
      "read": {}
    }
  }
}
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{
  "claude/channel": {},
  "codex/sandbox-state-meta": {}
}

Tools

Functions exposed to the LLM to take actions

NameDescription
tandem_workA

Maintain one durable shared task and its role-bound checklist.

To create, send action="create", expected_revision=0, a unique operation_id, and plan; omit work_id. The plan must have one final integration step that depends directly or transitively on every other step, including investigations. For later mutations, get the card first and use its current revision as expected_revision. Use a new operation_id for a new or corrected request; reuse an ID only for an exact retry. list/get/history need no operation_id. Plan agreement, worker submission and independent acceptance are separate. Waiting observes committed changes, not permission to start an agent. Autonomous grants and uncertain-attempt reconciliation are operator CLI actions.

tandem_scopeA

Inspect the immutable project boundary and available computation profile defaults.

Separate launch folders have separate data even with one user-wide MCP registration. Additional client-granted directories permit working there, not reading their MCP history. This is data isolation, not an OS filesystem sandbox. execution_profiles describes defaults, not effective/actual settings after overrides; deep means more time, not higher thinking.

tandem_startA

Start a task with exactly one of prompt or structured contract. Returns immediately.

Base constraints/owned files stay fixed; each follow-up has a new goal and criteria. project_context_id pins product rules/decisions. Only the coordinator sets question timeout. Think: collaboration; analyze: read/search; work: edits/shell, NOT sandboxed.

tandem_continueA

Start a NEW current goal after completion; supply exactly one of prompt or turn contract.

History/base policy/mode/cwd persist, but old goals/acceptance do not. The product snapshot stays pinned unless explicitly changed to another revision of the same project. Question timeout is inherited unless explicitly set here. For waiting_input use tandem_reply.

tandem_resultA

Get the actual answer, work outcome and next_action. Questions return immediately.

wait_seconds: 0..25. completed is turn completion, not proof of success. answer holds the requested text; summary only describes the work. When answer_truncated, read answer_artifact_id. details=true includes the full answer/report/contract/diagnostics.

tandem_replyA

Answer exactly the pending clarification, resuming the same worker. Expired/stale IDs fail.

Duplicate identical answers are idempotent; different second answers are rejected.

tandem_cancelA

Stop a task, including while it waits for clarification. Does not undo edits.

tandem_listA

List recent task/conversation IDs, statuses, outcomes and next actions without large bodies.

tandem_publish_artifactA

Publish immutable shared context; each same-name publication creates a new version.

Return artifact_id to the partner in a follow-up or contract.artifact_ids. Content max 4MiB UTF8. Logical names are not filesystem paths; no file is read or modified by this tool.

tandem_read_artifactA

Read an immutable artifact version shared by the coordinator and OMP; page using next_offset.

Offsets count Unicode characters; limit 1..50000. IDs never resolve arbitrary local files.

tandem_waitA

Wait for ANY selected task to finish or ask a question, not 25s per task.

Returns ready IDs/questions, not full answers. Read ready terminal results with tandem_result and remove them from later wait sets; reply directly to a returned question. Does not acknowledge terminal events or rerun work. Await events only with a live independent watchdog.

tandem_project_contextA

Coordinator-only product knowledge: source-backed rules, examples and settled decisions.

publish creates an immutable snapshot; updating a project requires its current expected_revision. get uses an exact context_id; list optionally filters project_id. Pass context_id to tandem_start/continue explicitly. Publishing never changes active tasks. Workers may propose changes in their answer but do not get this publishing tool. Do not approve invented rules.

tandem_export_contextA

Explicitly offer this project's selected rules and referenced evidence to one recipient.

Use only when the user intends cross-project sharing. No tasks/history are shared. The returned transfer_id is a private capability, not a public link. The recipient must separately call tandem_import_context in its own coordinator session. This grants no permissions.

tandem_import_contextA

Explicitly accept a product snapshot offered to this launch project.

Only recipient-bound exports can be imported; no foreign database is browsed. Creates fresh local context/evidence IDs, preserving source provenance, not granting approval. Existing product revisions require expected_revision. Retrying one transfer is idempotent.

tandem_channelA

Manage optional Claude Code Channels push delivery; ordinary polling always remains available.

probe sends a receipt challenge only through the channel; ack with its probe_token confirms delivery. watchdog_token acknowledges an actual independent hook wake, never a tool-response assertion. ack with event_id acknowledges a webhook. pending lists unacknowledged events (include_previous explicitly includes earlier sessions). recover replays one event_id or a completed task_id; never changes task outcomes or reruns work. Token-file contents are secret.

tandem_reviewA

Capture or read an immutable review bundle, or compare it with current selected files.

request.source selects base-to-worktree (default) or base-to-staged Git index material. Staged captures exclude unstaged/untracked content; source also governs applicability checks. Capture includes requirements, supplied checks and boundaries without executing tests. Bind review_id to a think task for snapshot-only review. Author rationale is withheld unless explicitly revealed in a comparison turn. Read pages by next_offset, not the live working directory. assess reports applicability at observation time, not whole-system correctness.

tandem_review_runA

Run one read-only review scenario without manually coordinating its native turns.

start: supply ReviewRequest and a stable request_key for this logical request. Reusing the key returns the same run; a different payload conflicts. Code captures the snapshot, runs independent think review, then at most one comparison if author material was supplied and the independent report succeeded. Total budget defaults to 600 seconds, including startup, both stages and questions. It never edits files or runs supplied test commands. status/reply/cancel: use the returned run_id, never start again to wait. Replies require the current question_id. Full stage answers, findings, applicability and peer-only usage are assembled by code. Claims are not automatically accepted or applied. Missing context needs an explicit new capture (context_paths), not hidden live reads.

tandem_findingsA

Track version-bound review findings without rewriting their history.

Validity and resolution are separate. A claimed fix is not verified; verify_fixed needs evidence and a completed verification task for its snapshot. Update requires the current expected_revision. Get by stable finding_id or conversation_id plus human number.

tandem_diagnoseA

Diagnose this client session's project, OMP execution, actual model and delivery.

live=true starts one short provider request and may incur a charge: use only for a user-requested live check. Default checks local state without contacting a provider. If still running, inspect the returned task_id instead of starting another check. A separate CLI process cannot certify this session's push receipt.

tandem_receiptB

Gate result processing separately from reading/acknowledging notification events.

Claim before applying a terminal result; only an authorized fresh claim may proceed. Complete with its token after handling. Duplicate reads do not authorize repeated effects. A stranded claim is uncertain, never automatically released: reconcile external state. Claims grant no filesystem/external permissions. External effects still need their own idempotency/transaction boundary.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 20 tools

Disambiguation3/5

Several tools have genuinely overlapping territory: tandem_start vs tandem_continue (both begin task/goal execution), tandem_review vs tandem_review_run (both produce review bundles/runs), and tandem_result vs tandem_reply vs tandem_wait (all mediate interacting with a running task). The very detailed descriptions help an agent differentiate them, but the boundaries are subtle enough that misselection is plausible.

Naming Consistency5/5

Every tool uses the same tandem_ prefix with snake_case verb_noun or noun forms (tandem_start, tandem_result, tandem_reply, tandem_cancel, tandem_list). Minor noun-only names like tandem_channel or tandem_scope remain fully readable and predictable within the established convention.

Tool Count3/5

Twenty tools is on the heavy side for the rubric's 16-25 'borderline heavy' band. The domain is genuinely complex (task orchestration, review lifecycle, context sharing, channels, diagnostics), so most tools earn a place, but the surface is larger than an agent can comfortably hold.

Completeness4/5

The lifecycle is well covered: starting, continuing, waiting, reading results, replying, cancelling, listing, plus review, findings, artifacts, context publication/export/import, channels, receipts, and diagnosis. Few obvious dead ends exist, though some operations (e.g. task mutation nuances) lean on one large multi-action tool rather than dedicated endpoints.

Maintenance

ActivityMaintained
ResponsivenessNo issues