Skip to main content
Glama
jiawei686

jev-review-mcp

by jiawei686
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

jev-review-mcp

πŸ‡¨πŸ‡³ δΈ­ζ–‡ζ–‡ζ‘£

Code-review gate as a single-purpose MCP tool, powered by Jev (TypeSafe's System One decision model). One MCP, one job.

Real-world cost on OpenRouter β€” 4.9M tokens Β· $0.19 over 7 days:

Turns a git diff into a typed decision β€” no prose, no Jev API knowledge needed from the host agent.

What it does

review_patch(diff, context?) returns a structured verdict instead of free-form text:

Field

Type

Meaning

verdict

approve | request_changes | needs_discussion

Overall call on the patch

safe_prob

number (0–1)

P(safe to merge without human review)

severity_score

number (0–4)

Index into the severity scale

severity_label

trivial | minor | moderate | major | critical

Human-readable severity

confidence

number (0–1)

Model's calibrated certainty on the verdict

action

auto_merge | human_review

What the agent should do next

recommended

boolean

Convenience flag = (action === "auto_merge")

Decision gate: action is auto_merge only when verdict === "approve" and safe_prob > 0.8 and confidence >= 0.6. Every other case is human_review.

⚠️ Only execute auto_merge on high confidence. A high safe_prob alone is never permission to merge β€” gate on confidence.

Related MCP server: secret-scanner

Install & build

npm install
npm run build

The compiled server is at dist/index.js.

Add to your MCP client

{
  "mcpServers": {
    "jev-review": {
      "command": "node",
      "args": ["/absolute/path/jev-review-mcp/dist/index.js"],
      "env": { "TYPESAFE_API_KEY": "ts_xxx" }
    }
  }
}

No key? It still runs in mock mode (JEV_MCP_MOCK=1, or simply no TYPESAFE_API_KEY) so you can try it offline.

Example call

{
  "diff": "diff --git a/src/app.ts b/src/app.ts\n- const x = secret\n+ const x = process.env.SECRET",
  "context": "Move hardcoded secret to an env var"
}

returns something like:

{
  "verdict": "request_changes",
  "safe_prob": 0.2,
  "severity_score": 4,
  "severity_label": "critical",
  "confidence": 0.7,
  "action": "human_review",
  "recommended": false
}

Model endpoint

Works with any Jev-compatible endpoint. Default is the TypeSafe API (https://api.typesafe.ai/v1/systemone); override with JEV_BASE_URL (e.g. an OpenRouter-compatible route) and set TYPESAFE_API_KEY to your provider key.

Environment variables

Variable

Default

Description

TYPESAFE_API_KEY

β€”

TypeSafe Jev key. Absent β‡’ mock mode

JEV_MCP_MOCK

0

Set 1 to force the deterministic offline mock

JEV_MODEL

jev-latest

Model id sent to the endpoint

JEV_BASE_URL

https://api.typesafe.ai/v1/systemone

API base URL

JEV_MCP_TIMEOUT_MS

30000

Per-call timeout (ms)

Mock mode

With no key (or JEV_MCP_MOCK=1) the server answers deterministically from keyword heuristics β€” useful for demos, tests, and offline development. A single derived risk signal drives every field, so the mock stays internally consistent (risky diff β†’ low safe_prob, high severity, human_review).

Diagnostics

node dist/index.js doctor          # human-readable
node dist/index.js doctor --json   # machine-readable

Prints mock/live mode, key presence, model, and base URL.

Test

npm test

Runs a smoke test against the compiled output in deterministic mock mode.

Notes

  • Jev is a decision model: pure text in β†’ typed decision out. It does not read images or generate prose.

  • Diffs are truncated at 60k characters to stay within Jev's ~64k-token budget.

  • Keep the human in the loop: route anything that is not a high-confidence auto_merge to a person.

License

MIT

Available Tools

1 tool
review_patchA

Code-review gate powered by Jev (System One decision model). Given a git diff and optional context, returns a verdict (approve / request_changes / needs_discussion), a safety probability, a severity score, a calibrated confidence, and an action (auto_merge / human_review). Only execute auto_merge on high confidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
diffYesThe git diff or patch to review.
contextNoOptional surrounding context (file purpose, PR description).

TDQS

A4.3/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 discloses that this is an AI decision gate returning a verdict, safety probability, severity, confidence, and action. The caution 'Only execute auto_merge on high confidence' implies the tool itself does not execute the merge and warns about the risk, adding behavioral context beyond annotations.

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?

The description is compact and front-loaded with the core purpose. Every sentence contributes: the first defines the tool, the second lists inputs and outputs, and the third gives a critical safety instruction. There is no filler.

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?

Because there is no output schema, the description correctly explains all return values (verdict, safety probability, severity score, calibrated confidence, action). It also covers the required and optional inputs and the action condition, making the tool fully invocable by an agent.

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?

Schema description coverage is 100%, so the baseline is 3. The description rephrases the inputs ('git diff and optional context') but adds no new detail beyond the schema's own parameter descriptions, so it does not elevate the score.

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 opens with 'Code-review gate powered by Jev (System One decision model)', which immediately states the tool's purpose with a specific verb and resource. It then enumerates the exact inputs and outputs, clearly distinguishing this from the sibling screen_content, which is unrelated.

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?

The description clearly indicates when to use the tool (given a git diff and optional context) and gives an explicit instruction on how to act on its result: 'Only execute auto_merge on high confidence.' It does not name alternative tools or exclusions, but the only sibling is screen_content, so no routing conflict exists.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedreview_patch
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusion or overlap. The purpose of review_patch is clearly distinct and self-contained.

Naming Consistency5/5

The sole tool name follows the verb_noun pattern (review_patch), which is clear and predictable. Consistency is trivially maintained with one tool.

Tool Count3/5

A single tool is minimal for a server, though it is focused on one specific gate action. This feels slightly thin but not unreasonable for a narrow purpose.

Completeness4/5

The domain is a code-review gate, and review_patch covers the core workflow of evaluating a patch and returning a verdict. Missing features like configuration or review history are minor gaps that agents could work around.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • secret-scanner

    Baneado98
    A
    license
    A
    quality
    B
    maintenance
    Enables scanning diffs or code blobs for leaked secrets, returning a verdict with severity and masked findings, all processed locally with no data sent externally.
    1
    MIT

  • PR Guardian MCP

    maiv3n
    A
    license
    A
    quality
    D
    maintenance
    Analyzes GitHub Pull Request diffs for security vulnerabilities and data leaks, using a deterministic filter to skip trivial changes and an AI-powered analysis for logic changes.
    1
    MIT