Skip to main content
Glama
Sign In
n8n-guard

n8n-guard

by flow-84
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Git drift

git_drift

Compares live n8n workflows against git-exported JSON to surface unexported changes, deleted exports, and drifted content.

Instructions

Diffs the workflows in the running instance against the JSON exports in a git checkout: live but unexported, exported but deleted, and content that has drifted apart.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations supplied, the description must carry the full behavioral burden. It helpfully discloses the three result classes (live but unexported, exported but deleted, content drifted), which signals this is a read-only comparison. It does not state that it is non-mutating, nor how the git checkout is located given the tool takes zero parameters — a real gap for an agent that must decide whether it can call this safely.

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

Conciseness5/5

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

A single sentence that front-loads the action and the two compared data sources, then lists the outcome categories. No filler, no restatement of the title.

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?

For a zero-argument comparison tool with no output schema and no annotations, the description covers what is compared and the shape of the findings, which is most of what an agent needs. It stops short of explaining how the checkout is resolved or the result format, but no output schema exists to lean on.

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 and there is nothing for the description to disambiguate. The only semantic question — which git checkout is used — is left unaddressed, though that is an operational configuration detail rather than a parameter.

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?

Uses a specific verb ('Diffs') and names both compared resources precisely: live workflows in the running instance versus JSON exports in a git checkout. It even enumerates the three drift categories. It does not name a sibling to contrast with, but no sibling in the provided list (db_health, instance_info, retention_report) overlaps in purpose, so the distinction is implicit.

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?

The intended scenario — reconciling live state against version-controlled exports — is strongly implied by the comparison described. However, there is no explicit when-to-use statement, no prerequisites (e.g., that a git checkout must exist and be configured), and no guidance on what to do instead if the checkout is unavailable.

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