Skip to main content
Glama
Sign In
JevGuard MCP Server

JevGuard MCP Server

by seb4ez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_code_patch

Assess a code diff or patch for security regressions, broken syntax, and critical system impact. Choose strict, balanced, or permissive risk tolerance to determine acceptance.

Instructions

Evaluates whether a code diff or patch introduces security regressions, broken syntax, or critical system impact under a configurable risk tolerance (strict, balanced, permissive).

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": {
      "patch_content": "<patch_content>",
      "target_file": "<target_file>"
    },
    "name": "verify_code_patch"
  }
}

Input Schema

NameRequiredDescriptionDefault
timeoutNoHTTP request timeout in seconds (default: 30.0).
target_fileYesPath of the target file being modified.
bypass_cacheNoBypass deterministic cache lookup.
patch_contentYesDiff or patch content to verify.
risk_toleranceNoRisk tolerance threshold for acceptance (strict, balanced, permissive; default: balanced).balanced

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does convey that the tool is evaluative and configurable, which implies a non-mutating verification rather than a system change. However, it does not disclose whether the check performs network calls, writes cache state, or returns a simple verdict versus a detailed report, leaving a meaningful transparency gap.

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?

A single sentence front-loads the operative verb, the object under evaluation, the three risk categories, and the configurable risk tolerance. There is no filler, redundancy, or burying of key information.

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?

The description and full schema are enough for an agent to provide the required inputs and understand the tool's evaluation scope. However, there is no output schema and no statement of return behavior, so it is unclear whether the tool returns a boolean verdict, a list of findings, or a full report; operational details such as side effects are also absent.

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?

The input schema already documents all five parameters with 100% coverage, so the description need not compensate for missing schema details. It adds contextual color about the risk categories being assessed and the risk-tolerance modes, but it does not provide per-parameter meaning beyond what the schema already offers.

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 description names a specific action ('Evaluates whether...') and a specific resource ('a code diff or patch'), and enumerates concrete risk categories: security regressions, broken syntax, and critical system impact. This clearly distinguishes it from sibling tools such as evaluate_command_safety, which target command safety rather than patch content.

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?

The intended use is implied: call this when a code diff or patch needs pre-merge verification under a chosen risk tolerance. However, the description never explicitly contrasts this tool with evaluate_command_safety or the other siblings, nor does it state when not to use it, so an agent must infer the selection from the name and schema.

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