# Jev agent tools (npm · jev-agent-tools)

Evidence-oriented code questions, diff review and test selection via a Jev endpoint.

- Trust score: 88/100 (high trust)
- Change this week: +1
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `jev-agent-tools`: 88/100 (this document), [markdown](https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools.md), [page](https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools)

## Channel facts

- Registry: `npm`
- Package: `jev-agent-tools`
- Version: `0.4.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 99/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 13 of 35 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to NomenAK/jev-tools).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 28 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 50/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 7715 tokens (~1285/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 6 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Jev agent tools MCP server?

Jev agent tools runs locally as an npm package, launched with npx -y jev-agent-tools. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add nomenak-jev-agent-tools -- npx -y jev-agent-tools
```

### Cursor

```json
{
  "mcpServers": {
    "nomenak-jev-agent-tools": {
      "command": "npx",
      "args": [
        "-y",
        "jev-agent-tools"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "nomenak-jev-agent-tools": {
      "command": "npx",
      "args": [
        "-y",
        "jev-agent-tools"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add nomenak-jev-agent-tools -- npx -y jev-agent-tools
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nomenak-jev-agent-tools": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "jev-agent-tools"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add nomenak-jev-agent-tools --command npx --arg -y --arg jev-agent-tools
```

### Hermes

```yaml
mcp_servers:
  nomenak-jev-agent-tools:
    command: "npx"
    args: ["-y", "jev-agent-tools"]
```

### Netclaw

```json
{
  "McpServers": {
    "nomenak-jev-agent-tools": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "jev-agent-tools"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add nomenak-jev-agent-tools -t stdio -c npx -a -y jev-agent-tools
```

### Other

```json
{
  "mcpServers": {
    "nomenak-jev-agent-tools": {
      "command": "npx",
      "args": [
        "-y",
        "jev-agent-tools"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-02 (score 88, 0)

- [security] Stability: 0.97 → pass

### 2026-11-01 (score 88, +1)

No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 87, +1)

No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 86, +1)

No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 85, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 84, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-21 (score 83, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-19 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (6)

### `jev_ask` (~1976 tokens)

Jev ask

Ask typed questions about one situation (note, files, command output); the same questions over many files → jev_ask_files.
Use for: one judgment that combines things (is this test failure a bug, a wrong test or the environment; does this test cover the function changed in that file; is the user's request clear enough to plan).
Not for: the same questions over many files, one answer each → jev_ask_files. Output or code you need to read or quote → bash or read. Exact matches → your text search tool.

How Jev sees the situation: at a glance, like a developer skimming what you assembled. It does not count, compute or chain inferences, and it does not notice what the state lacks: a missing piece looks like "no". What you put in the state outweighs what you tell it, so pass the evidence, not your argument, and do not explain roles ("this is a test"). Give both sides of a comparison: the failing test and the code it calls, the file before and after.

Give at least one of state, paths, command; code builds one situation and performs bounded judgments and controls, and you get only the answers back.
state: your note, short: the request, your plan or hypothesis, what you know that the files do not show. Not for pasting file contents or output. Appears as `state`.
paths: up to 20 files for code to read. Appear as `files["<path>"]`.
base: a git ref. Each path is also given as it was at that ref, as `files_before["<path>"]` (null if it did not exist), so you can ask what changed. When the question is about what you changed, pass base (HEAD if uncommitted) so Jev sees the file before and after. Counts against the state budget.
command: run with bash -c in the repo root, CI=1, same permissions and approval as bash. Appears as `output` with `command`, `exit_code`, `timed_out`, `stdout`, `stderr`. Repetitive lines are collapsed; if still too long, Jev keeps the passages that show a failure and the output is marked `truncated`.
asks: array of intents, each {"intent", "about"?, …}. `…

Input parameters:

- `asks` (required)
- `base` (string)
- `command` (string)
- `max_calls` (integer)
- `paths` (array)
- `root` (string)
- `state` (string)
- `timeout_s` (number)

Output parameters:

- `result`

### `jev_ask_files` (~1294 tokens)

Jev ask files

Triage many files by asking typed questions without reading them; exact strings → your text search tool, the code itself → read.
Use for: triaging or classifying files by what they do or contain before deciding which to read (which layer is it, does it validate tokens, how risky is a change here), when you would otherwise open them one by one. It can focus inspection when independent file judgments can change the next action.
Not for: the code itself, to edit or quote it → read. Exact strings, regexes, symbols, counts, line numbers → your text search tool. Files by name → your file-name search tool. No paths yet → jev_find_files. Where inside one big file → jev_locate_in_file. One judgment that crosses several files or a command's output → jev_ask.

How Jev sees a file: at a glance, like a developer skimming it for a second. It does not count, compute or compare files, and it never sees other files: a "no" means the file does not show it, not that it is false. Every file is judged alone; batching and controls determine request count, so an answer about a file that depends on another file (a value read from elsewhere) can be wrong and confident; pass such questions to jev_ask with both files. Wrong or truncated text is caught by code and lowers the answers.

paths: files, directories (walked recursively) or globs, repo-relative. Build output, binaries, lockfiles and files over 80 KB are skipped and listed. At most 255 files.
asks: array of intents; every ask is made of every admitted file. You declare what you want to know; the code writes the Jev questions, adds "other", fixes option order and reads the answers. The file's text is `content`.
  verify   {"intent":"verify","claims":{"c1":"`content` validates authentication tokens","c2":"`content` writes to the database"}}   → per claim per file: holds | contradicted | not addressed | cannot tell, 3 questions per claim per file in the first round — the choice, its order-reversed twin, and an exact-statement check — pl…

Input parameters:

- `asks` (required)
- `max_calls` (integer)
- `paths` (array, required)
- `root` (string)

Output parameters:

- `result`

### `jev_find_files` (~782 tokens)

Jev find files

Find the files for a goal you describe in plain words, ranked; known names → your file-name search tool, known strings → your text search tool.
Use for: starting a task in unfamiliar code ("where is proration computed", "what handles webhook retries") when you do not know file names or exact identifiers.
Not for: known strings, regexes or symbols → your text search tool. Files by name → your file-name search tool. Questions about files you already have → jev_ask_files.

How Jev sees it: names first, then a short passage of the best candidates — never whole files. Write the goal as one behavior sentence of at least 5 words (shorter goals are capped at unsure); prefer a full sentence of behavior over a few keywords. Put identifiers you already know in keywords, where they steer the pre-filter and the passage Jev reads. Jev cannot count or grep.

goal: what you are trying to do or find, as one sentence of at least 5 words. Describe behavior, not a guessed identifier: in our tests a full sentence found the right file in 49 of 51 cases, two or three keywords alone in 16 of 21.
keywords: identifiers or terms you already know that should appear in the code; [] if none. They steer the pre-filter and the passage Jev reads.
scope: directories to search instead of the whole repo. An empty scope produces no judgment; a judged "none" means no supplied candidate fit, not proof about unseen files.
exclude: globs to skip. Excluding tests keeps the entry point but drops the tests and docs from the list.
effort: quick searches fewer candidates for a first look, default, thorough searches more (wider net, slower).
max_calls: cap on Jev calls; beyond it the search stops at the best-ranked files so far and says so.

Result: the primary entry decision names the file to open with its actual probability and fresh/cache provenance; auxiliary rankings, controls and native read actions remain distinct. Unsure means two files are plausible, the answer depends on candidate order or the goal is…

Input parameters:

- `effort`
- `exclude` (array)
- `goal` (string, required)
- `keywords` (array)
- `max_calls` (integer)
- `root` (string)
- `scope`

Output parameters:

- `result`

### `jev_locate_in_file` (~595 tokens)

Jev locate in file

Find which line range of ONE big file (over 19 KB) serves a goal, instead of reading it whole; known string or symbol -> your text search tool.
Use for: a file too big to read whole (over 19 KB) when you know what you need from it ("where are retries scheduled", "the part that parses flags") and finding a range can focus the next inspection.
Not for: an exact string or symbol → your text search tool. Files under 19 KB → read them directly. Several files → jev_ask_files or jev_find_files.

How Jev sees it: the file cut into declarations or sections, all glanced at once. Neighboring sections can share an answer (a getter and its setter), splitting the mass into unsure even when both are right: that still points at the right neighborhood. It reads what is written, not what a function does at run time.

path: one repo-relative file.
goal: what you need from the file, as a sentence.

Result: the range as path:start-end with its label and probability, the runners-up, and a `read:` list naming the range to open. A leading probability at or above 0.7 is a verdict: read that range. Otherwise the line is unsure (`two sections share the mass`): read both ranges — usually neighbors, not the next section of the file. A `none` (`no section fits`) means the goal is probably not in this file: search elsewhere. Missing required answers or controls remain unjudged, without an invented probability. Typed diagnostics name parsing/window limits and native actions; primary and control provenance remain distinct. Marks are defined once in the reading guide.

The decision to call is discretionary: Use Jev for a bounded semantic judgment when its answer could change an open decision or focus the next inspection, and the relevant evidence is available. Use decisive reading, search or authorized execution directly when it settles the question. Exact lookup, counting and runtime causality belong to native tools. A Jev call is not a prerequisite for a conclusion, a review or task completion; n…

Input parameters:

- `goal` (string, required)
- `path` (string, required)
- `root` (string)

Output parameters:

- `result`

### `jev_check_diff` (~912 tokens)

Jev check diff

jev_check_diff: Review a stable diff for semantic risks, stale documentation or specification drift when that review can inform an open decision. Read the diff natively when you need its contents. Choose risk, docs or spec for the question at hand; neither risk followed by docs nor a Jev review before done is required. Findings are leads within the inspected scope, not proof of global safety or completeness.
Use for: a semantic review of a stable diff when risks, existing documentation or specification obligations remain an open decision.
Not for: reading the diff -> bash git diff. Choosing tests to run -> jev_select_tests. Work in progress: verdicts on a half-written diff are noise.

How Jev sees it: the diff cut into changed units (a function, a slice of a big one, a declaration, a config file), each shown before and after, with tests kept aside as evidence, never as units. The questions are fixed and reviewed; you write none, and Jev runs nothing.
For replaced member accesses, risk also checks the statically resolved local callers (found by literal name, aliases included) in separate calls. This is source text, not an execution: coordinated edits count, unknown providers, cut pieces, and metaprogramming stay unchecked, and a clean shown caller does not clear the unseen ones. Dynamic access that names no literal is not covered.

check: risk names units with correctness, security, compatibility or reliability risk and grades severity. docs checks up to 40 tracked Markdown sections mentioning changed code or source importing it, naming an existing sentence that may no longer match the change. It is not an exhaustive detector of missing documentation (independent measurement: 2/45 docs obligations found on 180 partial got/zod commits). spec checks each ### REQ-… requirement and names changed behavior absent from the specification.
base: a git ref to compare against (as for a pull request); default is HEAD plus untracked files.
spec_path: required for spec; a reposit…

Input parameters:

- `base` (string)
- `check` (required)
- `dimensions` (object)
- `max_calls` (integer)
- `only` (array)
- `root` (string)
- `spec_path` (string)
- `witnesses`

Output parameters:

- `result`

### `jev_select_tests` (~524 tokens)

Jev select tests

Select existing tests affected by a diff and return runner commands; this tool never runs or collects tests. Use when selecting existing affected tests can usefully change the execution plan; use native read/grep/bash for exact names and execution. base defaults to HEAD; paths are candidate test files or globs, not diff paths. Static discovery reads tracked files, literal project configuration and imports, without evaluating third-party config. Touched tests are selected for free; import closure includes unchanged intermediates and applicable pytest conftest fixtures. Remaining scenarios receive a changed-unit pointer; selected when 1-p(none) >= 0.5. Missing answers are selected; unavailable Jev falls back to all. Residual exported-unit checks report changed, run by no discovered test only within the discovered inventory, never global coverage or an obligation to add a scenario. Unsupported, unknown, calculated or unresolved runners keep that conclusion unsure and name the next manual action. Runtime and type tests are separate. Commands remain separate by cwd, config, project and framework; project options are preserved. At least 80% selected, uncertain names or unknown counts run the entire file. max_calls bounds Jev calls; unjudged tests remain selected. witnesses controls residual coverage checks (auto by default); pointers have no witnesses. This does not detect that a new test scenario is required.

Use Jev for a bounded semantic judgment when its answer could change an open decision or focus the next inspection, and the relevant evidence is available. Use decisive reading, search or authorized execution directly when it settles the question. Exact lookup, counting and runtime causality belong to native tools. A Jev call is not a prerequisite for a conclusion, a review or task completion; no explanation is needed for choosing native tools.

After an unavailable, refused or out-of-scope result, continue natively within the existing permissions; do not widen sh…

Input parameters:

- `base` (string)
- `max_calls` (integer)
- `paths` (array)
- `root` (string)
- `witnesses`

Output parameters:

- `result`

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools#diagnostics

## Score history

- 2026-11-05: 88
- 2026-11-04: 88
- 2026-11-03: 88
- 2026-11-02: 88
- 2026-11-01: 88
- 2026-10-31: 87
- 2026-10-30: 87
- 2026-10-29: 87
- 2026-10-28: 86
- 2026-10-27: 86
- 2026-10-26: 85
- 2026-10-25: 85
- 2026-10-24: 84
- 2026-10-23: 84
- 2026-10-22: 83
- 2026-10-21: 83
- 2026-10-20: 82
- 2026-10-19: 82
- 2026-10-18: 81
- 2026-10-17: 81
- 2026-10-16: 80
- 2026-10-15: 80
- 2026-10-14: 50
- 2026-10-13: 50
- 2026-10-12: 50
- 2026-10-11: 49
- 2026-10-04: 75
- 2026-10-03: 60

## Common questions

### What is the Jev agent tools MCP server?

Jev agent tools is an MCP server listed in the public MCP registry as io.github.NomenAK/jev-agent-tools. Evidence-oriented code questions, diff review and test selection via a Jev endpoint. This page covers its npm package (jev-agent-tools).

### Is the Jev agent tools MCP server safe to use?

Jev agent tools scores 88 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Jev agent tools MCP server expose?

Jev agent tools exposes 6 tools: jev_ask, jev_ask_files, jev_find_files, jev_locate_in_file, jev_check_diff, jev_select_tests. Their descriptions and schemas cost roughly 6,083 tokens of context every time the server is loaded.

### Is the Jev agent tools MCP server still maintained?

Jev agent tools is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Jev agent tools MCP server under?

Jev agent tools declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

### What did VerifyMCP test on the Jev agent tools MCP server?

VerifyMCP ran 16 checks on Jev agent tools, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- npm package: https://www.npmjs.com/package/jev-agent-tools
- Socket report: https://socket.dev/npm/package/jev-agent-tools
- Repository: https://github.com/NomenAK/jev-tools
- Website: https://github.com/NomenAK/jev-tools/blob/main/docs/mcp.md
- Changelog RSS feed: https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools.xml
- Changelog JSON feed: https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools.json
- HTML version of this page: https://verifymcp.io/servers/nomenak-jev-agent-tools/jev-agent-tools