Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CHAMBER_PYTHONNoPath to a Python interpreter with onnxruntime, used for the embedder.
CHAMBER_API_KEYNoAPI key for external OpenAI-compatible endpoints when model.base is not a loopback address.

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
chamber_checkA

Check your own claims against the user's notes before you state them. For each claim, give the note(s) it came from — the absolute path you read, a file.md#p3 ref from chamber_ask, or a passage id. Chamber confirms the note is indexed and unchanged on disk since indexing, then checks that every number, capitalised name, domain, file name and count in the claim occurs in that note. Verdicts: SUPPORTED, TERMS_ABSENT (names the missing terms), NO_TERMS (nothing specific to check), STALE (the note changed since indexing — not judged), NOT_FOUND, NO_SOURCE. The check uses no model and is deterministic. It does not check meaning — a negated claim built from the note's own words passes. Read-only unless record is true, which commits SUPPORTED claims through Chamber's gate (which may run the local embedder to compare against open citation debt), pinned to the passages that hold their terms, so chamber_verify reports them if a pinned passage changes once the note is re-ingested; unsupported claims are never recorded.

chamber_askA

Have Chamber's own configured model answer a question from the user's notes, with every claim judged against its own citations. To check an answer you wrote yourself, use chamber_check instead. Each claim comes back ALLOWED (its cited passages verified against their stored hashes) or UNSUPPORTED (no verified source — recorded, not load-bearing). Cited sources are returned as file#passage references you can open. Answers only from the indexed corpus; says so when nothing matches. NOTE: this WRITES, exactly as chamber ask does — each claim goes through the commit gate, so a claim with verified citations is recorded as a belief with its pins (which is what chamber_verify later checks for drift), an unsourced assertion mints citation debt, and spend is recorded. It cannot bypass that gate, activate a skill, or approve a pending write.

chamber_verifyA

Re-check every stored belief's pinned sources against the corpus as it stands now, and report the ones whose evidence moved: a source that no longer exists (not_found) or whose text changed under the pin (hash_mismatch). This is drift detection — the conclusion did not change, the ground under it did. Read-only.

chamber_corpusA

Report what is actually in the index: passage and file counts, source kinds and which of them are citable, the top contributing folders, and any file far above the median passage count (the signature of an export rather than a note). Use this before trusting a 'nothing matches' answer. Read-only.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 4 tools

Disambiguation4/5

The four tools are largely distinct: ask generates answers, check validates the agent's own claims, verify detects drift on stored beliefs, and corpus reports index contents. The ask/check boundary and check/verify boundary could be momentarily confused since all involve citation judgment, but descriptions explicitly cross-reference each other and clarify intent.

Naming Consistency5/5

All four tools use the same chamber_<verb> prefix pattern (chamber_ask, chamber_verify, chamber_check, chamber_corpus). Fully predictable and consistent.

Tool Count4/5

Four tools is a tight, well-scoped set for a citation-grounded Q&A/verification system, with each tool covering a distinct operation. It is on the lean side but nothing feels redundant or missing at the count level.

Completeness3/5

Core workflows (ask, self-check, drift verify, corpus introspection) are covered, but there is no tool to ingest/re-index notes despite check and verify depending on re-ingestion, and no way to inspect stored beliefs or citation debt directly. These are notable gaps an agent would hit when trying to manage the corpus lifecycle.

Maintenance

ActivityActive
ResponsivenessNo issues