Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
GMI_API_KEYYesYour GMI Inference API key. Read only from the environment variable, never from a file, a log, or a tool result.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Security triage tools backed by GMI Inference. Triage one semgrep finding, scan a repo, check a lockfile against OSV, explain a CVE from its advisory, verify a finding with a deterministic oracle, list and update stored findings, list the custom rules, or draft a private disclosure. No model is pre-selected.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
triage_semgrep_findingB

Triage one semgrep or scanner finding with GMI Inference.

Returns one validated finding as JSON: verdict, severity, confidence, reason, fix, stage used, latency, tokens, cost, and the estimate made before the call. An unparsed reply returns verdict null and unparsed true. It never returns clean. The verdict is stored in the findings store (per-user ~/.gmi-security-mcp/findings.db by default) and the result carries finding_id. An explicit db_path is allowed, with a warning that the caller is responsible for not committing it.

estimate_costA

Estimate the cost of a run with no API call and no spend.

Returns typical and maximum cost in USD, the prompt token estimate, and the per-token pricing used. An unpriced model returns priced false and null costs.

repo_scanA

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.

check_osv_advisoryA

Check one lockfile against OSV with the local osv-scanner.

Parses the lockfile locally, then runs osv-scanner on it and returns advisories as facts: id, package, installed version, fixed version, severity, summary, and link. Packages with only a version range and no exact version are reported unresolved, never given a verdict. No GMI call is made.

explain_cveA

Explain a CVE, GHSA, or OSV id from its advisory, with citations.

Fetches the advisory from OSV by exact id. When no advisory with that id exists, returns found false and invents nothing. When a model is named, GMI writes one plain-language paragraph from the retrieved advisory only. When no model is named, the explanation is the advisory summary itself.

draft_private_disclosureA

Draft a private disclosure from a confirmed real finding.

Uses the GitHub Security Lab report template, with the ssh-mcp-server host-key draft as the worked example of the format. Refuses when the verdict is not real, or when confidence is below 0.8 without explicit confirmation. When finding_id is given, the finding must be in the store with status confirmed, or triaged with verdict real and confidence at or above 0.8; otherwise the draft is refused and the result says why. Returns the draft as Markdown and writes it only when write_path is given. It is never sent, never opened as a PR, never forked, never pushed, never emailed. sent is always false. Writing the draft to write_path needs --allow-apply on the server command line; without it the call is refused. When --require-scope is set, the write target must sit inside a repo with scope enabled.

verify_findingA

Verify one finding with a deterministic oracle, PoV-is-truth.

A finding stays a candidate until an oracle reproduces it. GMI only writes the PoC, when poc is null; the local oracle decides. code is the audited code and harness description sent with the finding when a PoC is generated. A generated PoC is returned for review and only runs when run_poc is true AND confirm_generated_poc is true: run_poc alone never runs model-generated code on the host in the same call that generated it. A caller-supplied PoC runs when run_poc is true, with no extra flag, because the caller already reviewed it. A false_positive finding is refused unless regression_check is true, and then the result is labelled regression, not confirmation. Categories without an oracle return skipped with "no oracle for this category". test_command runs a PoC file already in the repo, or the written PoC when it names {poc}, for example pytest {poc} -k host_key. The PoC runs on the host by default, with a warning; pass executor docker for a disposable container when Docker is available. verify_finding never applies a fix; a fix_candidate is run through patch validation and then restored. A fix_candidate needs --allow-apply on the server command line; without it the call is refused.

list_findingsA

List stored finding summaries, newest first.

Filters: status, check, severity, repo_path. limit defaults to 20 and is capped at 100. cursor pages through results. Summaries only: no code in list output, only in get_finding.

get_findingB

Get one stored finding in full: code, evidence, verdict history, pipeline events, verification results, business impact, and matching triage memories.

update_findingA

Update a stored finding. reason is required.

business_impact changes business impact only, never technical severity, verification, review gates, or patch permissions. status moves one step at a time and is refused when it skips a state, for example new to confirmed without a reproduced verification. Suppressing a critical/high finding with business impact Urgent/High is refused unless force is true with a reason, and is then recorded with that reason and actor.

mark_fpA

Mark a stored finding false_positive. reason is required.

Creates a triage memory with the given scope (global, package, or target, default target). The memory is a hint only: it never auto-rejects a future finding, and the agent must still triage it. Memories are created only by this human call.

mark_confirmedA

Mark a stored finding confirmed. reason is required.

Only when a verification result with status reproduced exists for the finding. Otherwise the call is refused, and an LLM verdict alone cannot set confirmation.

list_rulesA

List the custom semgrep rules pack. No GMI call, no spend.

Returns each rule with id, name, category, severity, description, and whether it is enabled by default. category filters to one of the 7 known checks. The pack ships in src/gmi_security_mcp/rules/; set GMI_SECURITY_MCP_RULES_DIR when it is elsewhere.

scope_enableA

Enable scope for one repo from a scope file.

A scope file alone never activates checks; only this call does. Returns the in-scope and out-of-scope lists and a warning that scope is a destination policy, not authorisation to test, and not an OS sandbox.

scope_disableB

Disable scope for one repo.

Returns disabled with a warning that tools will now refuse if --require-scope is set, because there is no scope policy for the repo.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 15 tools

Disambiguation4/5

Most tools have a clearly distinct resource+action (scan vs. triage single vs. verify vs. mark vs. disclose). The only mild overlaps are triage_semgrep_finding vs. repo_scan (single finding vs. bulk pipeline) and check_osv_advisory vs. repo_scan's OSV section / explain_cve, but the descriptions make the boundaries explicit.

Naming Consistency4/5

All names are snake_case and readable, and the majority follow verb_noun (triage_*, verify_*, list_*, get_*, update_*, mark_*, estimate_*, explain_*, check_*, draft_*). Three deviate into noun_verb (repo_scan, scope_enable, scope_disable), a minor but noticeable inconsistency.

Tool Count4/5

15 tools is at the top of the well-scoped range but each maps to a real stage of the scan→triage→verify→confirm/disclose lifecycle. Nothing is clearly redundant, though the set is on the heavy side for a single MCP server.

Completeness4/5

The core lifecycle is well covered: scan, single/bulk triage, verify, list/get/update findings, mark_fp/mark_confirmed, disclosure, scope policy, rules listing, cost estimation, and CVE explanation. Minor gaps exist: no way to retrieve past scan reports by scan_id, no listing/deletion of triage memories created by mark_fp, and no delete_finding operation.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues