gmi-security-mcp

Overview Schema Source Related Servers Discussions Admin

verify_finding

Verify security findings by reproducing candidates with a deterministic oracle before confirmation; run caller-reviewed or explicitly approved PoCs and validate proposed fixes without applying them.

Instructions

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.

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_finding"
  }
}

Input Schema

Name	Required	Default
`poc`	No
`code`	No
`db_path`	No
`finding`	No
`run_poc`	No
`executor`	No	host
`repo_path`	No
`finding_id`	No
`max_tokens`	No
`stage1_model`	No
`test_command`	No
`fix_candidate`	No
`spend_cap_usd`	No
`harness_module`	No
`regression_check`	No
`confirm_generated_poc`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.11Nov 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With zero annotations, the description carries the full burden and does so thoroughly: generated PoCs are returned for review and gated behind run_poc AND confirm_generated_poc, caller-supplied PoCs need only run_poc, host execution emits a warning while executor=docker gives a disposable container, false_positive is refused without regression_check and relabels the result as regression, categories lacking an oracle return 'skipped', and fix_candidate is refused unless the server runs with --allow-apply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Nearly every clause carries a real rule, but the delivery is an undifferentiated block of run-on sentences with awkward mid-sentence line breaks and no grouping of the PoC-execution, regression, and patch-validation rules. 'GMI only writes the PoC, when poc is null; the local oracle decides' is grammatically tangled and slows comprehension of a critical gating rule.

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 16-parameter tool with no annotations, the safety, refusal, and execution-isolation behaviors are well covered, and the output schema means return values needn't be explained. Gaps remain around cost/model controls (spend_cap_usd, max_tokens, stage1_model) and the finding/finding_id/db_path lookup trio, which an agent must guess at.

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 description coverage is 0% across 16 parameters, so the description must compensate, and it does for roughly half of them (poc, code, run_poc, confirm_generated_poc, test_command with its {poc} placeholder syntax, executor, regression_check, fix_candidate), including their interactions and defaults. The remainder (finding, finding_id, db_path, repo_path, max_tokens, stage1_model, spend_cap_usd, harness_module) are left entirely opaque, so the compensation is only partial.

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 and resource ('Verify one finding') plus the verification mechanism ('deterministic oracle, PoV-is-truth') and the state transition it governs ('A finding stays a candidate until an oracle reproduces it'). This is unmistakably distinct from sibling mutation tools like mark_confirmed or update_finding.

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?

Gives clear contextual guidance: candidate findings come here to be reproduced, fix_candidate is routed to patch validation instead of being applied, and false_positive requires regression_check to be processed at all. It stops short of naming a sibling alternative (e.g. mark_confirmed vs oracle-backed confirmation) or stating when to skip verification entirely.

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

Deploy Server