Skip to main content
Glama
Fistacho

ha-nexus-agent

by Fistacho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Hard-reset config to a commit

git_git_rollback_to_commit
DestructiveIdempotent

Hard-reset the entire Home Assistant config directory to a known commit, discarding all later commits and uncommitted changes. Requires confirm=True to prevent accidental data loss.

Instructions

Hard-reset the entire HA config directory to a previous commit.

Without confirm=True returns a safety prompt naming the current head commit; with confirm=True calls repo.git.reset('--hard', sha), which discards every commit and uncommitted change made after sha.

Use when: reverting /config entirely after a bad batch of changes, and the target commit is already known. Not for: restoring a single file — use git_git_rollback_file. Returns: dict {"status": "reset", "to": sha} on success. Errors: returns {"error": "confirmation_required", "message": ..., "action": ...} when confirm is not True; raises RuntimeError (from _repo()) when no git repo exists. Limits: requires confirm=True. WARNING: every commit and uncommitted change made after sha is permanently and irreversibly lost.

Input Schema

NameRequiredDescriptionDefault
shaYesCommit SHA or ref to hard-reset the entire config directory to.
confirmNoMust be True to actually perform the reset. False (default) returns a safety prompt naming the current HEAD instead of touching anything.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.25.1
    • addedInput schema / properties / confirm / description
      Added value: +"Must be True to actually perform the reset. False (default) returns a safety prompt naming the current HEAD instead of touching anything."
    • addedInput schema / properties / sha / description
      Added value: +"Commit SHA or ref to hard-reset the entire config directory to."
  2. Changed1 schema field changedv0.18.1
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  3. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds substantial context: the confirmation gate, the exact reset command semantics, the irreversibility warning ('every commit and uncommitted change made after sha is permanently lost'), error keys, and the RuntimeError raised when no repo exists. This is far beyond what the structured fields convey.

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?

Front-loads the action in the first sentence and uses labeled sections (Use when / Not for / Returns / Errors / Limits) so an agent can scan. Some redundancy between the prose warning and the Limits section, but every part is substantive.

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?

Despite an output schema existing, the description still documents success and error returns and the confirmation failure mode, so an agent has everything needed to call this destructive operation safely. No material gap remains.

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?

Schema coverage is 100% and the schema already documents both sha and confirm in similar terms. The description nonetheless clarifies the two-step workflow semantics of confirm (call without it to receive a HEAD-naming prompt, then re-call with True to act), which adds procedural meaning beyond the schema's field-level text.

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?

States a specific verb and resource ('Hard-reset the entire HA config directory to a previous commit') with precise scope. It immediately distinguishes itself from the sibling git_git_rollback_file by naming it as the wrong tool for single-file restoration.

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

Usage Guidelines5/5

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

Explicit 'Use when' (reverting /config after a bad batch, target commit known) and 'Not for' (single file — route to git_git_rollback_file). Both the trigger condition and the alternative are named, leaving nothing to inference.

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