Skip to main content
Glama
Sign In
n8n-guard

n8n-guard

by flow-84
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Database health

db_health

Measures n8n datastore size, per-table growth and headroom, and estimates when the critical threshold is reached. Works on SQLite and Postgres; covers a gap the n8n Public API leaves open.

Instructions

Size, per-table breakdown and growth rate of the n8n datastore, plus an estimate of when it hits the critical threshold. Works on SQLite and Postgres. The n8n Public API has no endpoint for this.

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": "db_health"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the supported backends (SQLite and Postgres) and that the data is unavailable through the official API, which implies a direct datastore read. It does not state that the operation is read-only, whether it is expensive on large instances, or how thresholds are configured or estimated.

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?

Three tight sentences with no filler, and the substantive capability list comes first. The final sentence about the Public API is well-placed supporting context. Only the missing leading verb slightly weakens the opening.

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

Completeness4/5

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

With no output schema, the description must convey return content, and it does: size, per-table breakdown, growth rate, and a threshold projection. For a zero-parameter read tool that is nearly sufficient; only the exact response format and any cost/performance caveats are left unstated.

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 there is nothing for the description to disambiguate; the baseline of 4 applies. The description appropriately spends no words on inputs and instead covers the output shape, which is the only thing an agent needs to reason about here.

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

Purpose4/5

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

The description names a concrete resource (the n8n datastore) and enumerates exactly what it reports: size, per-table breakdown, growth rate, and a threshold-hit estimate. An agent can distinguish it from sibling reporting tools like retention_report. It lacks an explicit leading verb ('Reports...'), so the intent is inferred from the noun list rather than stated outright.

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

Usage Guidelines3/5

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

Usage is only implied by the content — you'd call it when you need storage growth or capacity forecasting. It never states when to prefer this over retention_report, nor whether it is cheap enough to call routinely or is a heavier diagnostic sweep. The note that the Public API has no such endpoint justifies the tool's existence but is not routing guidance.

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

Deploy Server

Other Tools