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