gmi-security-mcp

Overview Schema Source Related Servers Discussions Admin

repo_scan

Scan repositories with Semgrep and OSV-Scanner, then triage findings through two-stage GMI models to produce cost-aware JSON verdicts and stored finding IDs.

Instructions

Scan a repo with semgrep and osv-scanner, then two-stage triage.

Returns a JSON report: per-finding verdicts with stage and cost, totals, skipped findings with reasons, the OSV section, and the estimate versus actual cost. A dry run runs the scanners and estimates the cost with no GMI calls. Files over max_file_kb are skipped unless the caller raises the cap. Every triaged finding is stored in the findings store (per-user ~/.gmi-security-mcp/findings.db by default) and the report carries scan_id, with one finding_id per finding. The custom rules pack runs in addition to the default semgrep config, and its findings carry source custom-rule. A clean repo_scan does NOT mean flawless. Writing the report to write_report needs --allow-apply on the server command line; without it the scan still runs but the write is refused.

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>",
      "stage1_model": "<stage1_model>",
      "stage2_model": "<stage2_model>"
    },
    "name": "repo_scan"
  }
}

Input Schema

Name	Required	Description	Default
`db_path`	No
`dry_run`	No
`max_files`	No
`repo_path`	Yes
`rules_dir`	No
`threshold`	No
`max_tokens`	No
`max_file_kb`	No
`max_total_kb`	No
`stage1_model`	Yes
`stage2_model`	Yes
`write_report`	No
`include_tests`	No
`spend_cap_usd`	No
`semgrep_config`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.11Nov 12, 2026

addedInput schema / properties / db_path

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Db Path"
+}

addedInput schema / properties / rules_dir

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Rules Dir"
+}

First observedv0.3.0Nov 10, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses persistence to a per-user findings.db, scan_id/finding_id identity, file-size skipping and the cap override, the custom-rules source tag, and a server-side permission gate (--allow-apply) that can silently refuse writes. It stops short of explaining spend_cap_usd enforcement, behavior on scanner failure, or re-scan/idempotency semantics.

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 core action and the report shape, then progressively adds operational caveats; nearly every sentence carries information. Some sentences are long and pack multiple clauses (e.g., the findings-store sentence), which slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is optional, yet the description still spends words on it while leaving ten of fifteen inputs unexplained. For a 15-parameter, cost-incurring, state-writing pipeline, the parameter omissions are the main completeness gap.

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

Parameters2/5

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

Schema description coverage is 0% across 15 parameters, and the description only touches max_file_kb, write_report, and dry_run. The required stage1_model/stage2_model, plus max_files, max_tokens, max_total_kb, threshold, spend_cap_usd, include_tests, semgrep_config, and rules_dir have no meaning attached anywhere, leaving the agent to guess.

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?

The opening sentence names the specific verbs and resources: semgrep and osv-scanner scanning plus two-stage triage, and the rest of the description makes clear this is the orchestrating pipeline rather than a single-finding tool like triage_semgrep_finding or check_osv_advisory. The required stage1_model/stage2_model params and the report contents confirm the scope.

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?

Implied usage is present (dry_run for cost-only runs, write_report for persisting the report) and the caveat that a clean scan is not proof of flawlessness is a useful warning. But there is no explicit statement of when to use this composite scan versus the sibling tools that triage or check a single finding, and no prerequisites (e.g., needing a repo path, expected runtime) are spelled out.

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

Deploy Server