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

Tools

Functions exposed to the LLM to take actions

NameDescription
consult_startA

Start one consultant (target) or several (targets); returns job_id or group_id immediately. Available (name: CLI, model): (none -- no consultant CLI is installed) Pass the user's name/CLI/vendor/model wording; target_ambiguous lists candidates, target_unavailable lists available ones. targets: ["all"] asks every available consultant, including your CLI (marked same lineage). Each gets an identical brief; one concurrency seat each. Model and limits are operator-owned. followup_to: completed job_id or group_id; only question is also needed. Inherits the prior inputs; explicit fields, even empty, replace them. Files are recopied in their current state; add expose_paths or set expose_from_parent: false. retry_of: failed job_id alone replays saved inputs in a new chain, with current files and a link to the failure. Use successful group answers first; retry only failed members after fixing auth/quota causes. No other request fields. mode defaults from context: facts = explore, proposal = review, proposal + counterpoints = debate. For code: expose_diff: { repo, base? } for changes, expose_paths: [absolute paths] for relevant callers, tests and config. Files are copied read-only, secrets masked; symlinks/protected paths skipped. Caps: 20 entries, 500 files, 5 MB. Inspect files_exposed and the manifest; missing premises stay unknown. Other context: facts, artifacts (logs/test output). network: on/off controls web access, not model submission or local reads; boundary states CLI-specific enforcement. caller/caller_model identify you; initiator: user only when asked. Optional prediction: { expected, worry } stays local.

consult_getA

Wait for job_id or group_id (default 45000 ms; wait_ms: 0 polls). Repeat while running; progress is sent every 15 s. completed has advice; failed has failure.kind and no advice. A group includes statuses and comparison.by_target: actual model, stance, points/grounds and truncation markers. Read grounds already present. For missing/shortened deciding points use job_id + ids: ["f2", "u1"]; job_id alone gets one whole answer. detail: full adds the brief/question. Check deciding claims, batch checked entries in consult_record, then report; unchecked points stay unverified.

consult_cancelA

Stop a running consultation (job_id) or fan-out (group_id). Other severally servers receive a stop request. The process tree is signalled where the platform permits; on Windows descendants may survive if the CLI already exited.

consult_recordA

Save checks against point IDs from consult_get: f1 (finding), u1 (unknown), c1 (next check). verdict = confirmed/not_applicable/unverifiable/unverified; effect = decision impact; note = checked evidence. Confirmed is not adoption. Record only checked points; same ID replaces its entry. Use records: [{ job_id, entries, reflection? }, ...] for one fan-out batch. Invalid jobs/IDs prevent every write; write failures appear per job in results. Saved history survives restart; only verdict/effect go to follow-ups. Optional reflection describes what the answer added over your prediction.

consult_exportA

Render one consultation (chain_id) or fan-out (group_id) as Markdown: the brief as sent, each answer as it came back, and verdicts on each point. Starts with verified points/effects/evidence and unverified count; no inferred adoption or scoring. The text is returned, not written: put it beside the code the decision is about. Reads the history, so an earlier session's consultation can be exported.

consult_listA

Recent consultations, earlier sessions' too (this_session is false), newest first, with their ids, status, summary, verdicts, latest_completed_job_id and rounds_remaining. Optional target, question (case-insensitive substring), chain_id filters apply before limit. usage_totals is the tokens/cost reported this session, retries included. A figure a CLI does not report is named under not_reported, not counted as zero.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation4/5

Each tool maps to a distinct phase of the consultation lifecycle (start, poll, cancel, annotate, export, list), and descriptions make the boundaries largely clear. The only mild overlap is between consult_get (retrieve answers/points) and consult_export (render the full consultation as Markdown), which both return consultation content and could be momentarily confused.

Naming Consistency5/5

All six tools follow the identical consult_<verb> pattern (start, get, cancel, record, export, list) with no deviation in case or style. The verbs also accurately reflect each tool's action.

Tool Count5/5

Six tools is well-scoped for a consultation-orchestration server: initiation, polling, cancellation, annotation, export, and listing. Each earns its place with no redundant or filler tools.

Completeness4/5

The surface covers the full lifecycle: create jobs, wait/poll, cancel, record verdicts, export, and list history, with retry/follow-up folded into consult_start. Minor gaps remain—there is no dedicated tool to discover available consultant CLIs (only reported through consult_start error fields) and no way to delete or prune saved consultation history.

Maintenance

ActivityMaintained
ResponsivenessNo issues