chamber_check

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well past the annotations: it states the check is deterministic and model-free, lists all five verdicts, and explains that `record` commits through Chamber's gate, may run the local embedder, pins sources for chamber_verify drift detection, and never records unsupported claims. That is substantial behavioral disclosure, and readOnlyHint=false is consistent with the opt-in write path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the middle sentence about SUPPORTED ('a negated or reversed sentence built from the note's own words still passes') is a dense run-on that is hard to parse, and the whole description is an unstructured block for a two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so via the enumerated verdicts. The record-mode consequences are covered in depth; what is missing is any indication of the response shape (per-claim verdict mapping) and a clearer statement of the SUPPORTED matching rule.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description still adds meaning: it disambiguates what each `sources` entry means in practice (absolute path = file on disk, `file.md#pN` = indexed passage) and elaborates the downstream consequences of `record` beyond the schema's one-line note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb, resource and timing: 'Check your own claims against the user's notes before you state them.' It also implicitly separates itself from siblings by describing the ref formats that come from chamber_ask and the drift reporting that chamber_verify performs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'before you state them' framing gives clear when-to-use context, and the record paragraph explains when the write path engages. It never explicitly states when to prefer chamber_verify or chamber_corpus instead, so the routing is implied rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.