mcp-automem

Check Database Health

check_database_health

Read-onlyIdempotent

Check AutoMem service health and connected FalkorDB/Qdrant databases before sessions, after memory failures, or to review storage statistics.

Instructions

Check the health status of the AutoMem service and its connected databases (FalkorDB graph + Qdrant vectors).

When to use:

Before a session to verify the memory service is available
When memory operations are failing unexpectedly
To check storage statistics

Example:

check_database_health({})

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_database_health"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`error`	No	Set when status is error
`status`	Yes	degraded: reachable, but a backend or sync check needs attention.
`backend`	Yes
`statistics`	No	Memory/vector counts, sync_status, vector_dimensions and enrichment state, when provided.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.14.4Nov 5, 2026

removedOutput schema / properties / backend / description
```
Removed value: -"Backend type (automem)"
```

changedOutput schema / properties / error / description

Previous value: -"Error message if status is error"New value: +"Set when status is error"

changedOutput schema / properties / statistics / description

Previous value: -"Database statistics and diagnostics, including memory/vector counts, sync_status, vector_dimensions, and enrichment state when provided."New value: +"Memory/vector counts, sync_status, vector_dimensions and enrichment state, when provided."

changedOutput schema / properties / status / description

Previous value: -"Overall health status. degraded means the service is reachable but a backend or sync check needs attention."New value: +"degraded: reachable, but a backend or sync check needs attention."

Changed3 schema fields changedv0.14.1Jun 28, 2026

changedOutput schema / properties / statistics / description

Previous value: -"Database statistics (memory counts, etc.)"New value: +"Database statistics and diagnostics, including memory/vector counts, sync_status, vector_dimensions, and enrichment state when provided."

changedOutput schema / properties / status / description

Previous value: -"Overall health status"New value: +"Overall health status. degraded means the service is reachable but a backend or sync check needs attention."

changedOutput schema / properties / status / enum

Previous value: -[
-  "healthy",
-  "error"
-]New value: +[
+  "healthy",
+  "degraded",
+  "error"
+]

First observedv0.14.0May 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds useful context beyond that: the check spans two specific datastores and can surface storage statistics, which tells the agent what kind of signal to expect.

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

Conciseness4/5

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

The definition is short, front-loaded with the purpose sentence, and organized with labeled sections. The example call adds little for a zero-argument tool, but it costs only one line and reinforces the empty-argument invocation.

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

Completeness5/5

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

With no parameters, full annotation coverage, and an output schema handling return values, the description does everything required of it. Nothing an agent needs to select or invoke this tool is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; the empty schema and the example call with an empty object make the no-argument invocation explicit. Nothing further is needed.

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

Purpose5/5

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

The description gives a specific verb+resource ('Check the health status of the AutoMem service') and names the concrete backends involved (FalkorDB graph, Qdrant vectors). That is enough to distinguish it from every sibling, which are all memory read/write operations.

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

Usage Guidelines4/5

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

Three explicit when-to-use bullets cover pre-session verification, debugging failing memory ops, and checking storage stats. There are no when-not-to-use notes or named alternatives, but given the siblings perform memory CRUD rather than diagnostics, no real ambiguity remains.

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

Deploy Server