Skip to main content
Glama
Sign In
guardvibe

guardvibe

by goklab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

verify_remediation

Confirm every audit section was remediated by comparing a fresh scan against the before snapshot, flagging skipped sections, and withholding complete status until all are addressed.

Instructions

Compare before/after audit results to verify ALL sections were addressed. MUST be called after completing remediation to confirm success. Runs a fresh audit and compares against the before snapshot. Explicitly flags skipped sections and refuses to return 'complete' status unless every section is addressed. Pass the before audit hash or let it re-run. Example: verify_remediation({path: '.', before_hash: 'abc123'})

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

Input Schema

NameRequiredDescriptionDefault
pathNoProject root directory.
formatNoOutput formatjson
before_hashNoResult hash from the initial full_audit (for tracking)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.66.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv3.0.42

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it discloses that a fresh audit is executed (a non-trivial side effect), that a before-snapshot is compared, that skipped sections are flagged, and that 'complete' is withheld unless everything is addressed. It omits cost/runtime and whether the tool writes anything to disk, which keeps it below 5.

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-loaded with the purpose and the mandatory-call rule before the mechanics, and almost every sentence adds information. The trailing example is somewhat redundant given 100% schema coverage and three short parameters, costing a bit of tightness.

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?

No output schema exists, and the description partially compensates by describing what the result conveys (skipped-section flags, refusal of 'complete' status). It does not sketch the actual return shape or the format parameter's effect, leaving a small gap for a verification tool.

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%, so baseline is 3, but the description adds real meaning: it explains that before_hash may be supplied 'or let it re-run', clarifying the consequence of omitting an optional parameter beyond the schema's terse 'for tracking' note. The example call reinforces which keys matter.

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?

States a specific verb and resource: 'Compare before/after audit results to verify ALL sections were addressed', which is clearly distinct from full_audit and remediation_plan. It does not, however, differentiate itself from the close sibling verify_fix, which an agent could easily confuse with this tool.

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?

'MUST be called after completing remediation to confirm success' gives an unambiguous trigger condition, and 'Pass the before audit hash or let it re-run' resolves the optionality decision. It stops short of naming when-not-to-use cases or pointing at verify_fix/explain_remediation as alternatives.

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