Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Vinv

NPM · VINV-MCP

Vinv runs, tests, and finds issues in your services — with zero code changes.

Available components

0 this week 85 Trust /100

Last scanned (7 hours ago)

Scores higher than 87% of npm servers

Category Testing and QA

Trust breakdown (7 categories)

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. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (Apache-2.0).Pass
  • Actively maintained (last published 74 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability78
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 2069 tokens (~129/item across 16 items; 16 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage98
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 94% of tool parameters carry a description.Partial
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 16 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
What we tested

Checks we ran (16)

  • Malware scan
  • Known CVEs
  • Install scripts
  • Dependency health
  • Source repository
  • Provenance
  • License
  • Maintenance
  • Security disclosure
  • Schema quality
  • Stability
  • Tool coverage
  • Injection markers
  • Destructive annotations
  • Judged manipulation
  • MCP protocol

Does not apply to this package (2)

  • Endpoint SecurityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
  • Transport & ReachabilityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.

The score does not measure everything. What the score does not measure →

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 1 Nov 26 0
    • Stability: 0.97 → pass security
  • 31 Oct 26 0
    • Security disclosure: unverified → pass ▲ functional
    • Stability: pass → 0.97 functional
  • 30 Oct 26 0
    • Security disclosure: pass → unverified ▼ functional
  • 28 Oct 26 0
    • Security disclosure: unverified → pass ▲ functional
  • 27 Oct 26 0
    • Security disclosure: pass → unverified ▼ functional
  • 19 Oct 26 0
    • Stability: 0.97 → pass security
  • 17 Oct 26 +1

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

  • 15 Oct 26 +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.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Analysed npm/vinv-mcp@0.0.5

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem npm

Background: How many MCP packages publish verified provenance →

Dependencies 0 packages
Packages resolved 0
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 16 exposed · ~2,069 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
blast_radius ~86

Transitive callers (upstream) and callees (downstream) of a symbol in the observed call graph. Answers "if this is wrong, what could be implicated or affected".

NameTypeReqDescription
directionstring–up = callers only, down = callees only, both (default).
symbolstringyesSymbol to inspect: a dotted qualname or a unique short name.

No output schema declared.

No examples provided.

callers_of ~48

The observed direct callers of a symbol, with call counts. Answers "who calls this at runtime".

NameTypeReqDescription
symbolstringyesSymbol to inspect: a dotted qualname or a unique short name.

No output schema declared.

No examples provided.

coverage_of ~59

Execution coverage: with a symbol, its call count / ok-error / timing; without one, every executed symbol ranked by call volume. Answers "what ran and how much".

NameTypeReqDescription
symbolstring–Optional symbol; omit for a whole-run overview.

No output schema declared.

No examples provided.

rank_suspects ~85

Call FIRST when investigating a bug, error, or failing request/test: ranks symbols by fault suspiciousness (Ochiai SBFL) over the pass/fail spectra of all captured requests. Answers "which functions should I look at first for this failure" — cheaper and more targeted than reading source files.

NameTypeReqDescription
limitnumber–Max suspects to return (default 20).

No output schema declared.

No examples provided.

relevant_to ~193

Rank the codebase by graph relevance to one or more symbols you name — the SAME typed-edge personalized-PageRank walk that composed your context pack, re-anchored on your choice. Use when you have found symbols that matter and want what surrounds them, ranked: it answers "what else is relevant to THESE", which semantic search (vinv_query) and plain traversal (blast_radius) cannot. Returns walk mass per symbol so the ranking is auditable, and reports how many symbols it reached versus returned.

NameTypeReqDescription
budgetnumber–Max symbols to return (default 40, ceiling 200).
max_hopsnumber–Optional admission bound: only symbols within this many hops of an anchor may enter. Ranking is by walk mass regardless. Omit for unbounded.
symbolsarrayyesAnchor symbols — a bare name, a dotted qualname, or file:name to disambiguate.

No output schema declared.

No examples provided.

slice ~82

Backward dynamic slice to a symbol: the caller chain from the request root down to it, annotated with the argument/return values observed at each frame. Answers "what flowed in to reach this call" — use when tracing how a bad value or state reached a function.

NameTypeReqDescription
symbolstringyesSymbol to inspect: a dotted qualname or a unique short name.

No output schema declared.

No examples provided.

values_of ~89

Value profile for a symbol across the captured run(s): per-argument and return type mix, null-rate, numeric/length ranges, and most-common values. Answers "what does this function actually receive and return at runtime" — use this for ground truth instead of inferring inputs/outputs from source.

NameTypeReqDescription
symbolstringyesSymbol to inspect: a dotted qualname or a unique short name.

No output schema declared.

No examples provided.

vinv_deadcode ~177

List Python definitions (functions, classes, methods) that NOTHING in the repository references — dead code — found by static analysis of the source. Needs no prebuilt index and no runtime, so it works immediately on any workspace and returns each unused symbol with its file and line. Use it to find safe-to-remove code; before deleting a reported symbol, still confirm it is not referenced dynamically (by name) or exported as public API.

NameTypeReqDescription
includestring–Only report definitions under this path prefix (e.g. "src/").
reasonsboolean–Date each symbol from git history and classify it as never-wired vs lost-its-callers (slower; needs git).
show_probableboolean–Also include methods that may be overrides or duck-typed (higher recall, more false positives).

No output schema declared.

No examples provided.

vinv_feedback ~100

After you have acted on vinv_query results (opened the files, made the edit), call this once to record whether they helped, passing the vinv_decision_id from that response. Use reward in [-1,1], where 1 is fully useful and -1 is harmful. This trains retrieval for this workspace.

NameTypeReqDescription
decision_idstringyes–
outcomestring–Optional short outcome label.
rewardnumberyes–

No output schema declared.

No examples provided.

vinv_index ~129

Build or refresh Vinv's semantic code index for THIS workspace. The build runs in the BACKGROUND and this call returns IMMEDIATELY with status — it never blocks. Call with no arguments to start/refresh the index and read its status; pass rebuild=true to force a full rebuild from scratch. Until the first build completes, vinv_query returns a "still indexing" notice, so call this once up front on a fresh workspace, then poll it for readiness.

NameTypeReqDescription
rebuildboolean–Force a full rebuild from scratch (default false: incremental update when an index already exists).

No output schema declared.

No examples provided.

vinv_ingest_run ~163

Report a test run you performed, so it appears in the Journey and Findings views. Supply one entry per check with the unit you exercised, a scenario name, and the pass/fail verdict — the verdict is the one thing traces cannot supply. A unit is usually an HTTP endpoint ("METHOD /path"), but a repo with no service has units too: a CLI invocation ("RUN <command>") or a driven function ("CALL module.function"). Per-unit code coverage is joined automatically from the captures. Run this AFTER the work has been captured by tracelens.

NameTypeReqDescription
checksarrayyesOne entry per check performed.
sourcestring–Who produced this run, recorded as provenance (e.g. "claude-code e2e suite").

No output schema declared.

No examples provided.

vinv_list_candidates ~121

Ranked optimization candidates from the captured traces, each with the evidence behind it and a playbook for that class of waste (cache, fanout, n-plus-1, per-call, serial-async, wait, gc-pressure, alloc-churn, mem-leak). Read this before attempting any performance work — it reports what the traces actually measured, not a static guess.

NameTypeReqDescription
include_playbookboolean–Include the full playbook text for each candidate (default true).
limitnumber–Max candidates to return (default 10).

No output schema declared.

No examples provided.

vinv_query ~106

Semantic code search over the prebuilt index of this workspace. Use INSTEAD of grep/glob when looking for code by meaning or behavior rather than an exact string — e.g. "where are auth tokens refreshed", "what validates uploads". Returns the most relevant symbols (functions/classes) ranked, with file paths and scores, in a single call.

NameTypeReqDescription
querystringyesNatural-language search query.
top_knumber–Number of results (default 5).

No output schema declared.

No examples provided.

vinv_run_status ~54

What vinv currently holds for this workspace: capture sessions, whether an external run has been ingested, endpoint/coverage/issue counts, and the number of ranked candidates. Call this to check whether an ingest landed.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

vinv_session ~524

Read what Vinv has observed about this workspace at runtime, and drive its automated fix/optimize runs ("episodes"), from chat. READ: action="requests" (what became of each sweep/fix you QUEUED — a queued sweep does not always dispatch, and this is the only durable record of why one did not), action="trajectory" (every episode so far — what was tried, whether it verified, the reward, the standing goal, any disputes), action="status" (one-paragraph session summary), action="issues" (functions observed raising errors in captured runtime traces), action="hotspots" (the few functions where most traced runtime concentrates), action="memory_trends" (symbols retaining more memory every capture session — leak suspects), action="cache_candidates" (functions recomputing identical inputs — memoization sites with measured reclaimable time), action="opportunities" (the live optimization opportunity board with per-entry lifecycle status: posted entries are dispatchable, dispatched/resolved never re-dispatch until they expire), action="playbook" with kind (distilled how-to-fix guidance for one kind of performance waste — fix patterns, traps, verification discipline — plus the file paths holding this workspace’s current evidence of that kind: board entries, prior optimization attempts, learned prediction calibration). ACT: action="fix" with issue (and optional service) queues an automated fix run that a coding agent executes and Vinv verifies; action="run_sweep" with sweep queues a run pre-seeded with the named evidence (error clusters, hotspots, leak trends, or cache sites); action="set_goal"/"set_budget" steer future runs. Queued runs are picked up by the Vinv extension in the editor.

NameTypeReqDescription
actionstringyesOperation to perform.
budgetnumber–Episode budget for set_budget.
goalstring–Standing goal for set_goal; an empty string clears it.
issuestring–For action="fix": what to investigate and fix.
kindstring–For action="playbook": which waste kind to get guidance and live evidence paths for.
servicestring–For action="fix": optional service name — the fix is then verified by replaying that service.
sweepstring–For action="run_sweep": which evidence seeds the queued run — runtime_errors (fix functions observed raising errors), hotspots (optimize where traced time concentrates), memory_trends (investigate le…

No output schema declared.

No examples provided.

why_did_this_run ~53

The entry-point triggers and call paths that led to a symbol running. Answers "why was this function invoked".

NameTypeReqDescription
symbolstringyesSymbol to inspect: a dotted qualname or a unique short name.

No output schema declared.

No examples provided.

Install

How do I install the Vinv MCP server?

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

npm · vinv-mcp

# add to Claude Code
claude mcp add vinvai-vinv -- npx -y vinv-mcp
Common questions

What is the Vinv MCP server?

Vinv is an MCP server listed in the public MCP registry as io.github.VinvAI/vinv. Vinv runs, tests, and finds issues in your services, with zero code changes. This page covers its npm package (vinv-mcp).

Is the Vinv MCP server safe to use?

Vinv scores 85 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. 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 Vinv MCP server expose?

Vinv exposes 16 tools: vinv_query, vinv_index, vinv_deadcode, vinv_feedback, vinv_session, and 11 more. Their descriptions and schemas cost roughly 2,069 tokens of context every time the server is loaded.

Is the Vinv MCP server still maintained?

Vinv 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 Vinv MCP server under?

Vinv declares the Apache-2.0 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 Vinv MCP server?

VerifyMCP ran 16 checks on Vinv, 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.