Jev Review
Continuous, structured software-quality scoring for AI coding agents.
Per-dimension scores and reasoning
The product exposes one focused MCP tool, processes only caller-supplied context, does not automatically read the repository, and leaves code changes to the primary agent. The README clearly describes the API-key and review-context flow to Jev, while a test verifies that the key is placed only in the direct request's Authorization header. Secret-handling cautions, no-storage/no-telemetry claims, and a small dependency set are strong. Deductions apply because there is no per-request interactive confirmation or configurable approval gate; versions are pinned but no lockfile, vulnerability scan, or dependency-update policy is supplied; the stateless design minimizes rollback needs but cancellation and post-request recovery are not documented; and Jev, TypeSafe, and MIT attribution are clear while the maintainer is identified only generically and publisher identity remains unverified.
The README, package configuration, and tests agree on the Node requirement, endpoint, model, input boundary, and local handling of previous evaluations. Tests cover a missing key, upstream token limits, and bounded retry of a transient failure. Deductions apply because operation depends on the external Jev API, a valid key, and direct GitHub installation without an offline fallback; demonstrated failure messaging covers only a small set of cases and does not show handling for timeouts, disconnections, non-JSON responses, authentication failures, or every MCP boundary error.
The documentation explicitly supports Claude Code, Codex, Cursor, and OpenCode, with common review scenarios, manual configurations, and a macOS GUI environment-variable caveat. Boundaries are unusually clear: the tool scores rather than diagnoses, does not edit code or discover files, and marks unsupported conditional metrics inapplicable. Trigger precision loses a point because the README describes checkpoints and stopping rules, but the actual SKILL.md was not supplied, so the agent-facing trigger behavior cannot be fully verified.
The README has strong navigation, architecture, client-specific sections, development commands, and security guidance. Installation covers plugin and manual MCP paths, naming is stable across the materials, and the MIT text matches package metadata. Limitations are explicit, including remote transfer, uncertain token ceilings, and the fact that the service does not replace security tooling. Deductions apply because there is no substantive FAQ and response examples remain conceptual; version 0.1.1 is present without a changelog, release history, or compatibility evolution notes; and maintenance ownership, support channels, and a security-reporting path are unclear.
Per-metric scores, confidence, inapplicability markers, prioritized weaknesses, and before/after deltas are directly usable in an iterative coding workflow, while avoiding a misleading aggregate score. Deductions apply because no real evaluation sample, benchmark, or case study demonstrates incremental value over tests and static analysis, and no latency, API-price, quota, or large-context cost data supports a thorough cost-benefit judgment.
Tests and README claims corroborate important security and input behaviors, while package metadata supports runtime, dependency, license, and version statements. The approximate 32,768-token observation is properly distinguished from published fact and labeled changeable. Deductions apply because the core src implementation, lockfile, complete test suite, and real response samples are absent, leaving claims such as no key logging, no telemetry, complete response validation, and the full external-effects boundary only partially traceable from the supplied evidence.
- Every review sends explicitly supplied tasks, diffs, file contents, or repository context to TypeSafe's Jev API; do not include credentials, unrelated proprietary code, or other sensitive material.
- There is no demonstrated per-request confirmation gate for remote submission; constrain automatic invocation through client permissions or workflow rules before enabling it broadly.
- Operation depends on an external API, a valid JEV_API_KEY, and a changeable upstream token ceiling; plan for network, authentication, quota, and availability failures.
- The supplied evidence omits the core src implementation, dependency lockfile, and complete test suite, so claims about no telemetry, no logging, and comprehensive input/output validation cannot be fully verified statically.
- Treat Jev scores as advisory signals rather than substitutes for tests, human review, or dedicated security scanning.
What does this agent do, and when should you use it?
Jev Review is a locally executed MCP server that supplies continuous software-quality evaluations to Claude Code, Codex, Cursor, and OpenCode. It runs the bundled dist/server.js over stdio and exposes one MCP tool, jev_review. The caller explicitly provides a task, focused diff, file contents, or repository context; the server does not discover repository files on its own. It sends the supplied current context directly to the Jev API and converts Jev's typed decisions into per-dimension 1–10 scores, confidence values, rubric hints, and comparisons with earlier evaluations. Diagnosis, code changes, and validation remain the responsibility of the primary coding agent, while the project itself operates without an author-hosted backend, database, or telemetry service.
A coding agent calls jev_review with at least one of task, diff, files, or repositoryContext, and may include previousEvaluation for an iterative comparison. Jev Review validates that input, submits the current code context directly to https://api.typesafe.ai/v1/systemone over TLS, and converts Jev Score, Choice, and Noul decisions into independent metric scores, 0–1 confidence values, applicability flags, prioritized weaknesses, and predefined rubric hints. When previousEvaluation is supplied, it calculates per-metric deltas, improvements, regressions, and unresolved weaknesses locally; that prior evaluation is not included in the current code context sent to Jev. Its dimensions cover correctness, complexity, readability, modularity, coupling, changeability, API design, tests, reliability, security, and related qualities, with performance, scalability, compatibility, and observability evaluated when relevant evidence exists. It does not infer root causes, read files automatically, or edit code; the primary coding agent must interpret the signals and make the changes.
- A developer implementing a nontrivial feature with Claude Code or Codex can submit a focused diff after a coherent implementation slice to establish a quality baseline.
- A team managing refactoring risk can supply
previousEvaluationto identify regressions or gains in readability, coupling, changeability, and other dimensions. - A Cursor user can install the plugin and invoke the bundled
jev-reviewskill explicitly or leave it available under Agent Decides. - An OpenCode user can register the same local stdio server manually and add structured review checkpoints to an existing coding workflow.
- A user who does not want an author-operated credential proxy can run the MCP process locally and send authenticated requests directly to Jev.
- A developer preparing a change for handoff can run a final evaluation after tests pass and inspect unresolved high-priority quality weaknesses.
What are this agent's strengths and limitations?
- The MCP process runs locally without an author-hosted backend, database, or telemetry proxy, and the API key is used only for direct Jev access.
- The same bundled dist/server.js supports documented workflows for Claude Code, Codex, Cursor, and OpenCode.
- It reports independent quality dimensions and confidence values instead of collapsing unlike concerns into a synthetic overall percentage.
- The
previousEvaluationinput makes iterative improvements, regressions, and unresolved weaknesses explicit. - It never discovers or uploads repository files automatically; callers control the submitted scope through
task,diff,files, andrepositoryContext.
- Adoption requires Node.js 20 or newer, a Jev API key, network access, and continued availability of TypeSafe's remote Jev service.
- Submitted review context leaves the machine for the Jev API, so secrets and unrelated proprietary material must be excluded.
- Jev provides scalar signals and coarse hints rather than prose root-cause analysis, and it does not implement fixes.
- There is no npm publication; distribution is from the GitHub repository, and OpenCode requires manual setup.
- The observed roughly 32,768-token Jev limit is not published in the API documentation and may change, requiring large reviews to be trimmed or divided.
- The review loop complements but does not replace dedicated security tooling.
How do you install or deploy this agent?
Install Node.js 20 or newer and obtain a Jev API key from the TypeSafe console. Set it with export JEV_API_KEY="your-key", then run npx plugins add NiazMorshed2007/jev-review, choose Claude Code, Codex, or Cursor when prompted, and restart the client. A target can be selected directly with npx plugins add NiazMorshed2007/jev-review --target codex, --target claude-code, or --target cursor. In Codex or Claude Code, run /mcp to confirm the connection; in Cursor, check Settings → MCP. For OpenCode, run git clone https://github.com/NiazMorshed2007/jev-review.git, enter the repository, execute opencode mcp add jev-review --global -- node "$PWD/dist/server.js", and verify it with opencode mcp list.
How do you use this agent?
After implementing a coherent change and running the relevant checks, ask the coding agent to call jev_review. The first request must include at least one current-context field; a typical request supplies the task and a focused diff, conceptually { "task": "implement the requested change", "diff": "relevant patch" }, with complete files or repositoryContext added only when needed to understand the implementation. The coding agent should inspect the actual code behind important weak scores, form a hypothesis, and make the smallest justified improvement. On the next call, pass the first result as previousEvaluation and review its improvements, regressions, deltas, and unresolved weaknesses. Requirements and working checks take priority over score optimization. If Jev returns max_tokens_exceeded, remove unrelated context or split the work into coherent review slices.
FAQ
Does it scan the repository automatically?
task, diff, files, and repositoryContext supplied explicitly by the caller, and each request needs at least one current-context field.Where do the code context and API key go?
JEV_API_KEY is used only in the TLS Authorization header sent directly to https://api.typesafe.ai/v1/systemone; the project says it does not store or log the key. Explicitly submitted current review context is sent to the Jev API.Does using an evaluation cost money?
What happens when the submitted context is too large?
jev-latest behavior suggests a ceiling of roughly 32,768 tokens for the submitted state. On max_tokens_exceeded, remove unrelated context or split the change into coherent review slices.