Skip to main content
Glama
Sign In
guardvibe

guardvibe

by goklab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scan_changed_files

Scans only files changed since a Git ref and reports diff-aware security findings for PR checks, pre-push hooks, and incremental CI.

Instructions

Scan only files that have changed since a given git ref (branch, commit, or HEAD~N). Ideal for PR checks, pre-push hooks, and incremental CI. Diff-aware by default: returns only findings on newly-added lines (set diff_aware:false for whole changed files).

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

Input Schema

NameRequiredDescriptionDefault
baseNoGit ref to diff against (e.g. 'main', 'HEAD~3', commit SHA)HEAD~1
pathNoRepository root path.
formatNoOutput formatmarkdown
diff_awareNoReport only newly-introduced findings on added lines (true, default) vs. all findings in changed files (false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.66.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv3.35.1
  3. Removedv3.30.0
  4. Changed1 schema field changedv3.21.0
    • addedInput schema / properties / diff_aware
      Added value: +{
+  "default": true,
+  "description": "Report only newly-introduced findings on added lines (true, default) vs. all findings in changed files (false)",
+  "type": "boolean"
+}
  5. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does explain the key behavioral trait: diff-aware mode is on by default and reports only findings on newly-added lines, with instructions to set diff_aware:false for whole-file scanning. It does not state the read-only/non-destructive nature of the scan or any prerequisites such as needing a git repository, which is a minor gap for an unannotated tool.

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?

Three short sentences, each doing distinct work: scope, use cases, then default behavior with the opt-out. The scoping constraint is front-loaded and nothing is redundant.

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 four-parameter scan tool with no output schema and no annotations, the description covers purpose, usage context, default behavior, and roughly what is returned. It lacks any safety/read-only statement and repository prerequisite, which would complete the picture given the annotation gap.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already documented. The description adds a few examples for 'base' (branch, commit, HEAD~N) and clarifies the diff_aware default, but mostly restates what the schema provides; baseline 3 applies.

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 states a specific verb ('scan') applied to a well-scoped resource ('only files that have changed since a given git ref'), so the purpose is unambiguous. However, it never names or contrasts with the closest sibling, scan_staged, which also targets uncommitted changes, leaving the boundary to be inferred.

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?

It supplies concrete use cases ('PR checks, pre-push hooks, and incremental CI'), giving the agent clear when-to-use context. It gives no explicit when-not-to-use or 'use X instead' alternatives, so it falls short of full 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