Reads local memory database health and configuration, including schema version, record counts, full-text and vector search status, Ollama reachability, and the active project.
READ. DB path, schema version, counts per kind, FTS health, vector search state (sqlite-vec, embeddings), Ollama reachability and the current project.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden itself, and it does disclose the read-only nature ('READ.') and the full set of things inspected. It does not disclose that the Ollama reachability and vector-search checks may involve network/embedding work and therefore carry latency, nor whether any of these checks can fail or degrade the call — a meaningful omission for a probe tool that touches an external service.
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?
A single compact sentence front-loads the mode ('READ.') then lists the returned dimensions in order of specificity. Every clause names a distinct piece of information; nothing is redundant or padded.
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?
An output schema exists and the parameter set is empty, so return-value detail is already covered and the description needn't repeat it. Given that low complexity, the field enumeration plus read-only marker is close to sufficient; the only real gap is the absent cue on when this beats the neighbouring status/session tools.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument, whole-system snapshot rather than a targeted query.
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?
The description enumerates exactly what the tool surfaces — DB path, schema version, per-kind counts, FTS health, vector state, Ollama reachability, current project — which unambiguously reads as a system diagnostics/status report. The leading 'READ.' verb-plus-field-list makes the resource clear, though it never explicitly names itself relative to siblings like session_state or investigation_status.
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?
There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. An agent must infer from the field list that this is the health/diagnostics probe, with no guidance on whether to reach for it before or instead of session_state or investigation_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.