chamber
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHAMBER_PYTHON | No | Path to a Python interpreter with onnxruntime, used for the embedder. | |
| CHAMBER_API_KEY | No | API 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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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_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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The four tools split cleanly along generation (chamber_ask), self-authored claim checking (chamber_check), stored-belief drift detection (chamber_verify), and index inspection (chamber_corpus), and the descriptions explicitly cross-reference each other to steer selection. The near-synonym pair check/verify still invites a first-glance mix-up, though the read-only-vs-write and claim-vs-belief distinctions resolve it.
All four names share the chamber_ prefix and a single lowercase word, giving a predictable namespace. The pattern is verb-based for three tools (verify, check, ask) but noun-based for corpus, a minor deviation that stays readable.
Four tools is a tight, well-scoped surface for a citation-verification server, and each maps to a genuinely different operation rather than a variant of another. Nothing feels padded or redundant.
The surface covers verification, generation, and index inspection, but there is no tool to enumerate stored beliefs, retract a recorded belief, or resolve open citation debt — operations the descriptions imply exist behind the commit gate. Agents can read and verify but cannot manage or clean up the belief store they populate, which is a notable dead end.