mcp-secret-sentinel

Overview Schema Source Related Servers Discussions Admin

scan_git_staged

Read-onlyIdempotent

Scan git staged changes for exposed secrets before committing, reporting redacted findings with file and line locations.

Instructions

Scan ONLY the lines currently staged for commit (git diff --cached).

This is the pre-commit checkpoint: it inspects exactly the content the next commit would publish, and reports the file and post-commit line number of every added secret. Local diff settings (external diff tools, textconv filters, prefixes, path quoting) are overridden, and git runs no configured programs.

Args: repo_path: Absolute path to a git repository (or any path inside one). max_findings: List at most this many findings, most severe first (default 200, 0 = no limit).

Returns: The standard redacted findings report. If nothing is staged the result is clean with an explanatory summary.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo_path": "<repo_path>"
    },
    "name": "scan_git_staged"
  }
}

Input Schema

Name	Required	Description	Default
`repo_path`	Yes
`max_findings`	No

Output Schema

Name	Required	Description	Default
`clean`	Yes
`summary`	Yes
`findings`	Yes
`baselined`	No
`top_files`	No
`truncated`	No
`suppressed`	No
`files_scanned`	Yes
`total_findings`	No
`counts_by_pattern`	No
`counts_by_severity`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Oct 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "FileCount": {
+      "properties": {
+        "file": {
+          "title": "File",
+          "type": "string"
+        },
+        "findings": {
+          "title": "Findings",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "file",
+        "findings"
+      ],
+      "title": "FileCount",
+      "type": "object"
+    },
+    "Finding": {
+      "properties": {
+        "advice": {
+          "title": "Advice",
+          "type": "string"
+        },
+        "commit": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "title": "Commit"
+        },
+        "file": {
+          "title": "File",
+          "type": "string"
+        },
+        "line": {
+          "title": "Line",
+          "type": "integer"
+        },
+        "pattern": {
+          "title": "Pattern",
+          "type": "string"
+        },
+        "redacted": {
+          "title": "Redacted",
+          "type": "string"
+        },
+        "severity": {
+          "enum": [
+            "critical",
+            "high",
+            "medium"
+          ],
+          "title": "Severity",
+          "type": "string"
+        }
+      },
+      "required": [
+        "file",
+        "line",
+        "pattern",
+        "severity",
+        "redacted",
+        "advice"
+      ],
+      "title": "Finding",
+      "type": "object"
+    }
+  },
+  "properties": {
+    "baselined": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Baselined"
+    },
+    "clean": {
+      "title": "Clean",
+      "type": "boolean"
+    },
+    "counts_by_pattern": {
+      "anyOf": [
+        {
+          "additionalProperties": {
+            "type": "integer"
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Counts By Pattern"
+    },
+    "counts_by_severity": {
+      "anyOf": [
+        {
+          "additionalProperties": {
+            "type": "integer"
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Counts By Severity"
+    },
+    "files_scanned": {
+      "title": "Files Scanned",
+      "type": "integer"
+    },
+    "findings": {
+      "items": {
+        "$ref": "#/$defs/Finding"
+      },
+      "title": "Findings",
+      "type": "array"
+    },
+    "summary": {
+      "title": "Summary",
+      "type": "string"
+    },
+    "suppressed": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Suppressed"
+    },
+    "top_files": {
+      "anyOf": [
+        {
+          "items": {
+            "$ref": "#/$defs/FileCount"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Top Files"
+    },
+    "total_findings": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Total Findings"
+    },
+    "truncated": {
+      "anyOf": [
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Truncated"
+    }
+  },
+  "required": [
+    "clean",
+    "findings",
+    "files_scanned",
+    "summary"
+  ],
+  "title": "ScanReport",
+  "type": "object"
+}

First observedv0.2.0Sep 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), it discloses that local diff settings — external diff tools, textconv filters, prefixes, path quoting — are overridden and that git runs no configured programs, which is meaningful safety context for a scanner executing inside a repo. It also explains the empty-staging behavior (clean result with explanatory summary), which annotations cannot 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-loaded with the single most important constraint ('Scan ONLY the lines currently staged'), then structured Args/Returns sections. Slightly verbose in the diff-override sentence, but every clause adds real behavioral information given the empty schema descriptions.

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?

For a 2-parameter read-only scanner with an output schema, everything needed is present: scope, path semantics, result capping, edge-case behavior, and the internal git invocation guarantees. No gap an agent would need to guess at.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the load — and it does: repo_path is defined as an absolute path to a repo or any path inside one, and max_findings is explained as severity-ordered truncation with default 200 and the non-obvious semantics that 0 means no limit (a detail absent from the schema).

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 (scan) and a precisely bounded resource: only lines currently staged, i.e. git diff --cached. The scope clause plus the explicit 'post-commit line number' detail makes it distinguishable from siblings like scan_git_history, scan_git_range, and scan_file.

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?

Frames the tool as 'the pre-commit checkpoint' and states that it inspects exactly what the next commit would publish, which gives an agent a clear when-to-use condition. It does not explicitly name the alternative tools (e.g. scan_git_range for unpushed commits) or state when not to use it, so it falls short of a 5.

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

Deploy Server