# zzop (mcpb · linux-x64) Deterministic repository oracle for AI agents: inventory, dependency graph, frontend-backend join. - Trust score: 54/100 (low) - Change this week: +2 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-04 ## Components - mcpb · `osx-arm64`: 10/100, [markdown](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-darwin-arm64-mcpb.md), [page](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-darwin-arm64-mcpb) - mcpb · `osx-x64`: 10/100, [markdown](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-darwin-x64-mcpb.md), [page](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-darwin-x64-mcpb) - mcpb · `linux-arm64`: 10/100, [markdown](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-arm64-gnu-m.md), [page](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-arm64-gnu-m) - mcpb · `linux-x64`: 54/100 (this document), [markdown](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp.md), [page](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp) - mcpb · `win-x64`: 10/100, [markdown](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-win32-x64-msvc-mc.md), [page](https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-win32-x64-msvc-mc) ## Channel facts - Registry: `mcpb` - Package: `https://github.com/eezz4/zzop/releases/download/v0.41.0/zzop-mcp-linux-x64-gnu.mcpb` - Version: `0.41.0` - Transport: `stdio` - SHA-256: `0bb4415660b4b0006615d35e6b11c9781547796c4b30480f1fe059407be627bc` ## 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-04. - **Supply Chain Security**: 0/100 - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package. - Known CVEs could not be checked: we found no dependency list to check in this bundle: either it runs a compiled binary, whose bundled manifests we do not read, or none of the package.json, requirements.txt, pyproject.toml or uv.lock files it ships for its runtime declares a dependency we can read (a requirements.txt that only points at a setup.py project, a local path, or a nested requirements file we cannot follow counts as none). - Install-script risk not yet assessed. - Dependency health could not be checked: we found no dependency list to check in this bundle: either it runs a compiled binary, whose bundled manifests we do not read, or none of the package.json, requirements.txt, pyproject.toml or uv.lock files it ships for its runtime declares a dependency we can read (a requirements.txt that only points at a setup.py project, a local path, or a nested requirements file we cannot follow counts as none). - **Provenance & Transparency**: 48/100 - Source repository is publicly reachable at the declared URL. - Provenance check failed: no build-provenance attestation is published. - Clear OSI-approved license (MIT). - Actively maintained (last published 0 days ago). - Publishes a security disclosure policy (SECURITY.md). - **Schema Quality & AI Usability**: 75/100 - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 8778 tokens (~313/item across 28 items; 9 tools + 19 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**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation. - An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 60/100 - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. **Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm. ## Install ### How do I install the zzop MCP server? zzop ships as an MCPB bundle, a single file you download and open in an MCP host that supports MCPB bundles, such as Claude Desktop. The host reads the launch command from the bundle's own manifest, so there is no command to copy. Before opening it, check the file's SHA-256 matches the one the MCP registry declares for it, 0bb4415660b4b0006615d35e6b11c9781547796c4b30480f1fe059407be627bc; the commands to do that are on this page. If it does not match, do not open it. - Download bundle: `https://github.com/eezz4/zzop/releases/download/v0.41.0/zzop-mcp-linux-x64-gnu.mcpb` - SHA-256: `0bb4415660b4b0006615d35e6b11c9781547796c4b30480f1fe059407be627bc` ### Verify on macOS / Linux ```bash echo "0bb4415660b4b0006615d35e6b11c9781547796c4b30480f1fe059407be627bc zzop-mcp-linux-x64-gnu.mcpb" | shasum -a 256 -c ``` ### Verify on Windows (PowerShell) ```powershell (Get-FileHash -Algorithm SHA256 .\zzop-mcp-linux-x64-gnu.mcpb).Hash -eq "0bb4415660b4b0006615d35e6b11c9781547796c4b30480f1fe059407be627bc" ``` ## 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-03 (score 54, 0) - [functional] Package version: 0.40.0 → 0.41.0 ### 2026-11-01 (score 54, +1) - [security] Stability: 0.97 → pass ### 2026-10-30 (score 53, +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. ### 2026-10-28 (score 52, +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-26 (score 51, +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 50, 0) - [security regression] Tool safety: pass → unverified - [security regression] Stability: 0.73 → unverified - [functional regression] Schema quality: 100 → unverified - [functional regression] Capabilities: fail → unverified - [functional regression] Tool coverage: 100 → unverified - [functional improvement] Schema quality: 356 → 315 - [functional] Package version: 0.39.0 → 0.40.0 ### 2026-10-23 (score 50, +1) No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-21 (score 49, +1) No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes. ## MCP tools (9) ### `analyze_repo` (~1344 tokens) Analyze a repository Run zzop's deterministic analysis on ONE repository/tree. Pass EITHER `path` (a tree root — finds the one zzop.config.jsonc at or above it: rules, packs, overlays, mounts, with the reply's `config` field saying whether one was honored) OR `configPath` (a zzop.config.jsonc at ANY location, for a config that does not sit at the tree root; the CLI twin spells this `zzop analyze --config `). A config is REQUIRED: a tree with no zzop.config.jsonc at or above it is refused, and the error names the `config-template` contract document and, on this server, the resource URI that serves it (write those bytes to /zzop.config.jsonc and retry). Everything the config does not say still defaults (bundled rule packs + git signals included); the one thing with no default is its `vocabulary` block, the names zzop would otherwise guess about that project, where an undeclared key is a judgment zzop does not make. Returns a summary (full counts by severity/rule, engine warnings) plus a capped findings list — truncation is always disclosed. The reply's `coverage` field is the structural coverage census, the run's own blindness disclosure (its degraded count is the full, uncapped one the capped `degraded` list points at): read it before treating zero findings as a clean bill, because a run that could see little reports little. Beside it, `coverageGaps` — shape `{basis, extensions, meaning}` — names the PRINCIPAL filetypes whose code did not reach the DEPENDENCY GRAPH — because no structural parser read them, because a parser read every one of them and bailed (`coverage.degraded` tells those two apart, and they take opposite remedies), or because they parsed and none of their declared imports resolved — with a `basis` sentence so an empty list reads as measured rather than unasked, and a `meaning` that says which rules those gaps make untrustworthy. Each row is `{ext, files, kind, structural}`, and its own legend says how to read `kind`. Beside it, `configWarnings` is the confi… Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) naming the ONE tree to analyze — the config-first mode, for a config that does not sit at the tree root. A config declaring 2+ trees is ref… - `limit` (integer): Findings list cap (default 50, max 1000). 0 is legal — "counts only, no findings listed". - `path` (string): Absolute path to the repo/tree to analyze. - `rule` (string): Exact rule id to include in the findings list. Valid ids are listed in the rule-catalog resource (zzop://contract/rule-catalog); a filter matching zero findings for an id absent from this run's own f… - `severity` (string): Minimum severity to include in the findings list (counts always cover everything). ### `cross_repo` (~755 tokens) Join repositories across the layer boundary Analyze 2+ repos/trees and join them across the layer boundary — the cross-layer (kind,key) join (e.g. a React consume matching a Spring provide, a shared DB table, route drift). Pass EITHER `configPath` (a zzop.config.jsonc — its `trees`, including "auto", define the join; the config-first way) OR `paths` (explicit tree roots, each tagged by directory name — every root LOADS its own zzop.config.jsonc and must have one; the reply's `config` field stays null because no single config governs the run, and `configWarnings` names the ones that were honored). Returns per-tree summaries with engine warnings, the join buckets, matched edges, and cross-layer findings (capped lists disclose truncation). Each `sources[]` row carries `packsLoaded`, the same `{id, rules, ruleIds, source, filesInScope?, filesInScopeIfEnabled?, zeroAdmissionRules?, didNotRun?}` pack-load confirmation analyze_repo's reply carries for one tree: A row carrying `didNotRun` never ran, so its silence is not cleanliness. ONE `packsLoadedMeaning` object at the reply root defines those keys for every source. Each row likewise carries `coverage`, the per-tree structural coverage census, including the engine's `joinContributionZero` assertion — the positive statement that a tree contributed NOTHING to the join — so a barely-seen source reads as silence, not cleanliness; check it before calling a quiet join clean. TWO VIEWS OF ONE BUCKET, and they are different numbers on purpose: `buckets` counts RAW ROWS (one per recorded call site) while `distinctBucketKeys` lists the DISTINCT keys those rows collapse into, so `buckets.X` is always >= the length of `distinctBucketKeys.X` — the reply states this relationship itself in `bucketMeaning`, so no reader has to infer it. The parallel `distinctBucketKeyFirstSites` gives ONE site per distinct key, the FIRST recorded `file:line`, so e.g. an unresolvedConsumes key is locatable without a further query. The honored config file, if any, is echoed at the top level (`conf… Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) whose trees define the join (config-first mode). - `limit` (integer): Findings list cap (default 50, max 1000). 0 is legal — "counts only, no findings listed". - `paths` (array): Absolute paths to the repos/trees to join (paths mode — every root under the one zzop.config.jsonc found above them). - `rule` (string): Exact rule id to include in the findings list. Valid ids are listed in the rule-catalog resource (zzop://contract/rule-catalog); a filter matching zero findings for an id absent from this run's own f… - `severity` (string): Minimum severity to include in the findings list (counts always cover everything). ### `check_file` (~734 tokens) Everything zzop knows about one file DEFINITIVE answer to "what does zzop know about THIS FILE?" — the targeting twin of check_endpoint, with a file PATH as the target instead of an io key. Use it when you are working IN a file and want everything about that file rather than everything about the tree. Returns: which tree it belongs to (`sourceId`, plus `otherTrees` when the same relative path exists in more than one, never a silent pick), a `verdict`, its `loc`, its `symbols` (count + exported names), its `io` provides/consumes, its `dependencies` in BOTH directions (`imports` and `importedBy` — the second is the half you cannot read off the file itself), and every finding anchored in it, the tree's own and the cross-layer join's merged into one list with counts by severity and rule. NOTHING IS CAPPED: a single file's facts are bounded by the file, so this surface drops nothing and therefore never has to disclose a truncation. THE VERDICT ANSWERS WHETHER THE FILE WAS ANALYZED, NOT WHETHER IT IS HEALTHY, and that distinction is the point of the tool: an empty findings list means "clean" for an `analyzed` file and means "nothing structural ever ran" for a `lexical-only` or `degraded` one. Sealed four-token vocabulary — "analyzed", "lexical-only", "degraded", "not-found" — and the reply SPELLS OUT the returned token's meaning in its own `verdictMeaning` field. `dependencies` carries the same kind of field, `dependenciesMeaning`: an EMPTY `imports` list is ambiguous on its own, so the reply says what it covers rather than leaving this description to define it. Three host-layer channels ride along beside the analysis, and they are named here because a CLOSED "Returns:" list reads as a denial of anything it omits: `config` (the config file this answer was computed under, or null), `warnings` (engine-side diagnostics — WHY a parse degraded, which packs did not load), and `configWarnings` (unknown keys, unknown rule ids). A `lexical-only` verdict without reading `warnings` tells you the file was not analyzed… Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) whose trees define the analysis. - `path` (string): Absolute path to ONE repo/tree (finds the zzop.config.jsonc at or above it, like analyze_repo). - `paths` (array): Absolute paths to 2+ repos/trees to join (paths mode, like cross_repo — each root loads its own zzop.config.jsonc). - `sourceId` (string): Optional. Pins the answer to ONE tree by its sourceId, for a relative path that exists in several. Omit it and every tree is searched, with `otherTrees` naming any additional match. - `target` (string, required): The file to ask about — tree-relative (`src/api/users.ts`) or absolute; forward or back slashes both accepted. An absolute path matches by its tail, so you can pass what your editor gave you. ### `check_endpoint` (~501 tokens) Check one io key across the join DEFINITIVE answer to "is io key X provided/consumed/joined?" — matches `pattern` against ANY cross-layer io key (http routes, DB tables, tRPC procedures) as a case-insensitive substring, over a fresh analysis of the given tree(s). Returns one `verdict` from a sealed eight-token vocabulary — "linked", "provided-only", "consumed-unprovided", "external", "unresolved-only", "ambiguous", "mixed", "not-found" — and the reply SPELLS OUT the returned token's meaning in its own `verdictMeaning` field. An "ambiguous" verdict's candidate providers are listed per matched item, inside each `matches.ambiguousConsumes[]` entry's own `candidates` array — there is no top-level `candidates` field. Full per-bucket counts ride along uncapped; matched objects (file/line/source intact) and related findings are capped with disclosed truncation. `relatedFindings` is a TEXT match, never a computed link — a finding is listed when its rendered message contains the pattern or a matched key as a case-insensitive substring, so it both over- and under-matches, and an empty array is not evidence that no finding concerns the key. The reply states that itself, beside the list. The same three host-layer channels check_file names ride along here too — `config`, `warnings`, `configWarnings` — for the same reason: a verdict computed over a tree whose packs failed to load is a verdict about less than you asked for, and `warnings` is where that is said. Pass exactly ONE of `path` (one tree — the join still runs, intra-tree edges included), `paths` (2+ tree roots, each loading its own config), or `configPath`. Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) whose trees define the analysis. - `path` (string): Absolute path to ONE repo/tree (finds the zzop.config.jsonc at or above it, like analyze_repo). - `paths` (array): Absolute paths to 2+ repos/trees to join (paths mode, like cross_repo — each root loads its own zzop.config.jsonc). - `pattern` (string, required): Non-empty, case-insensitive substring to match against every io key (and against the raw expression of unresolved consumes). ### `check_coverage` (~864 tokens) Check how much of a repo zzop can see Answer "how much of this stack does zzop actually SEE?" for 1+ trees — the aggregate visibility view behind the `zzop coverage` CLI twin, and the one surface built to be read BEFORE trusting a zero. Every fact in the reply is exactly one of three kinds and may only say what its source can back: MEASURED (this run: the per-extension dispatch table, whose five column definitions the reply owns in `dispatchMeaning` and are not repeated here), CAPABILITY (this build, true before any tree is walked: `frameworkRecognizers`, every framework recognizer compiled in with the io channels it fills, uncrossed with any tree; and `nativeAnalyses`, the roster of native analyses this build registered — including `disabled` (this caller's config turned them off) and `shippedOff` (this BUILD ships them off by default, so their silence is a default, never a clean bill)), and UNMEASURED (`unmeasured`, a FIELD rather than a caveat sentence so it cannot be dropped in transit — today it names RECALL: how many of the findings that EXIST in your tree zzop reports has never been measured on your tree, and the committed benchmark scores zzop's own labeled corpus, not yours). There is deliberately no single coverage score; the reply's `unmeasured` note says why. The CAPABILITY×MEASURED crosses are the cells to read first. `blindSpots` crosses each rule's own compiled-in sightline declaration with this tree's structural extensions, naming rules whose finding count carries NO information about your code here; beside it `blindSpotBasis` says what the cross was computed from AND what it excluded, so an empty array cannot be read as "no blind spots". `unreadExtensions` names each filetype that is a principal share of this tree and that NO structural parser read — the population the per-rule cross structurally cannot contain, since a language with no parser never becomes a structural extension and so vanishes from the very list a reader checks for blindness. Its `kind` field decides the remedy and t… Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) whose trees define the run (config-first mode). - `paths` (array): Absolute paths to the repos/trees to report visibility for — ONE is legal here (unlike cross_repo's 2+). Every root is governed by the one zzop.config.jsonc found above it. ### `module_map` (~647 tokens) Map a codebase into modules and their imports Answer "what IS this codebase?" — the import graph collapsed into MODULES and the imports between them, as data. Call it FIRST on a tree you have not seen: it is the orientation reply, and it is small on purpose. A small `fold` is a fraction of analyze_repo's reply size over the same tree, which carries no module map at all. A MODULE is the first `fold` segments of a file path — nothing is inferred about packages, layers or ownership. `fold` is REQUIRED because an unfolded map is the file graph, which is the thing this collapses; raise it for a finer grain. That is the ONLY knob, and it is also the answer to "this is too big to read", because NOTHING HERE IS CAPPED: every module and every edge at the grain you asked for is present, no argument can drop one, and there is no truncation field because there is no truncation. Returns `{fold, modules[], edges[], census, meaning}`. The reply's own `meaning` field defines those keys and ships with every call. Read it before reading the rows; it is short, and the two things it exists to stop you misreading are that `edges[]` and `census.fileImports` count different populations, and that `modules[].lines` is a partial sum whenever `linesMeasuredOver` is below that row's `files`. THIS IS A TOPOLOGY, NEVER A VERDICT. No row says a module is badly placed; there is no severity, no score, no ranking, and no finding of any kind in this reply — a large module and a thick edge are facts about shape, not judgements about it. For findings ask analyze_repo or cross_repo; for whether this tree's zeros mean anything ask check_coverage, which is also where you learn whether a filetype reached the dependency graph at all — a language no parser read contributes no imports here, so a thin map can be a thin reading rather than a thin codebase. The CLI twin is `zzop map ... [--fold ]`, which defaults `fold` to 1 because a terminal caller is looking at the answer. Input parameters: - `configPath` (string): Path to a zzop.config.jsonc (or a directory containing one) whose trees define the map (config-first mode). - `fold` (integer, required): How many leading path segments make one module. 1 is the top-level map, 2 the next grain down. Required: an unfolded map is the file graph. Spelled the way the CLI picture lane spells the same collap… - `paths` (array): Absolute paths to the repos/trees to map — ONE is legal (a map is a question about a tree before it is a question about a join). Every root is governed by the one zzop.config.jsonc found above it. ### `analyze_envelope` (~884 tokens) Analyze a Normalized AST envelope (Mode A) Run Mode A full-envelope analysis: a complete Normalized AST envelope (a custom parser's output, already validated against its contract) REPLACES native parsing entirely for this run — contrast validate_envelope, which only checks the envelope's shape and runs no analysis at all, and Mode B overlay/mount requests, which merge external symbols ON TOP of a natively-parsed tree instead of replacing it. Only symbol-scan/io-scan DSL rules can fire (an envelope carries no source text, so text-scan/regex-body rules never match — the zzop://contract/rule-catalog resource says which rules are which kind); the native call-graph rules (mutating-route-no-auth, unsafe-read-endpoint, non-idempotent-write) additionally run when the envelope supplies its `files[].calls` channel (call edges — see the zzop://contract/envelope-schema resource; an envelope with http routes and no calls keeps them silent and the reply's warnings say so). The one tool that needs no config: bundled rule packs load the same way they do for every other zzop-mcp tool, and an envelope carries no filesystem location, so there is no `config` file to auto-discover (the reply has no `config`/`path` field at all) and none to require either. OPTIONAL `configPath` — read this before trusting a verdict: WITHOUT it the run judges by zzop's BUILT-IN convention vocabulary, so it does not know what THIS project calls its own auth guards, its generated-file banners or its data-access receivers (a finding whose text points at a `vocabulary` key names a declaration the run never read), and only the bundled packs load — whose every rule's `file_pattern` targets zzop's OWN native filetypes, so an envelope describing a language zzop has no parser for, the case Mode A exists for, matches no bundled rule at all (the reply's warnings say so rather than letting the zero read as clean). WITH it, the named zzop.config.jsonc supplies exactly two things: its `vocabulary` and its rule-pack selection (`packs.extraDirs` — the way to bri… Input parameters: - `configPath` (string): Optional path to a zzop.config.jsonc (or a directory containing one) whose `vocabulary` and rule-pack selection this run applies. Omitted: the built-in vocabulary and the bundled packs alone. - `envelopeJson` (string, required): The Normalized AST envelope JSON text to analyze (see the zzop://contract/envelope-schema resource). - `limit` (integer): Findings list cap (default 50, max 1000). 0 is legal — "counts only, no findings listed". - `rule` (string): Exact rule id to include in the findings list. Valid ids are listed in the rule-catalog resource (zzop://contract/rule-catalog); a filter matching zero findings for an id absent from this run's own f… - `severity` (string): Minimum severity to include in the findings list (counts always cover everything). ### `validate_envelope` (~299 tokens) Validate a Normalized AST envelope Validate a Normalized AST envelope (a custom parser's output) against its contract WITHOUT running an analysis — the authoring feedback loop. Returns {valid, issues[], hints[]}; never fails on bad input. The two lists are DIFFERENT AXES: `issues` are why the envelope is REJECTED (they alone set `valid`), while `hints` are shapes that are accepted but almost certainly not what you meant. Their consequences are NOT uniform, so read the hint text instead of assuming one: some shapes make the cross-layer join find nothing at all (an `http` key that is not the normalized "METHOD /path" form the join keys on; a provide key carrying a host, which is consume-side external egress only), while others still join and instead change what the run produces (an absolute files[].path is added as a synthetic entry as a Mode B overlay rather than merging onto the file it names; a duplicate provide is joined once per copy). Every hint names its own concrete consequence and the fix. Treat a non-empty `hints` on a valid envelope as the more urgent signal. Hints are reported for an invalid envelope too (both axes in one round-trip), and are empty when the text did not parse at all. Pair with the zzop://contract/* resources (schema, guide, key-normalization fixture). Input parameters: - `envelopeJson` (string, required): The envelope JSON text to validate. ### `validate_rule_pack` (~287 tokens) Validate a DSL rule pack Validate a DSL rule pack's STRUCTURE before loading it — the exact judgments the engine's pack loader makes at load time (bad JSON, missing field, wrong type, too-new schema_version) plus every rule that would load but could silently never fire — a matcher regex that fails to compile, a line-scan declaring neither `line_pattern` nor `any`, and a method-scan whose `trigger` names a label no `patterns` entry declares. This checks shape ONLY — it never judges rule quality or semantics (whether a pattern over-matches, whether a rule is useful). Validation is also PACK-LOCAL: it cannot see any other pack, so a pack `id` colliding with a bundled or another loaded pack (which replaces it WHOLE) is invisible here — that only surfaces at load time via `packsLoaded` (and its shadow warning, when one fires); check `packsLoaded` after loading a pack this tool passed. Returns {valid, issues[]}; never fails on bad input. Pair with the zzop://contract/rule-pack-schema resource (the machine-readable shape) and the dsl-reference/dsl-authoring-guide resources. Input parameters: - `packJson` (string, required): The rule-pack JSON text to validate (one pack file — rules/dsl//.json in-repo or a packsDir file — or one packDefs entry). ## Diagnostics Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp#diagnostics ## Score history - 2026-11-04: 54 - 2026-11-03: 54 - 2026-11-02: 54 - 2026-11-01: 54 - 2026-10-31: 53 - 2026-10-30: 53 - 2026-10-29: 52 - 2026-10-28: 52 - 2026-10-27: 51 - 2026-10-26: 51 - 2026-10-25: 50 - 2026-10-24: 50 - 2026-10-23: 50 - 2026-10-22: 49 - 2026-10-21: 49 - 2026-10-20: 48 - 2026-10-19: 48 - 2026-10-18: 47 - 2026-10-17: 47 - 2026-10-16: 46 - 2026-10-15: 46 - 2026-10-14: 45 - 2026-10-13: 10 - 2026-10-12: 10 - 2026-10-10: 10 - 2026-10-09: 10 - 2026-10-06: 10 - 2026-10-04: 40 - 2026-10-03: 40 - 2026-10-02: 40 ## Common questions ### What is the zzop MCP server? zzop is an MCP server listed in the public MCP registry as io.github.eezz4/zzop. Deterministic repository oracle for AI agents: inventory, dependency graph, frontend-backend join. This page covers its MCPB bundle (https://github.com/eezz4/zzop/releases/download/v0.41.0/zzop-mcp-linux-x64-gnu.mcpb). ### Is the zzop MCP server safe to use? zzop scores 54 out of 100 on VerifyMCP. 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 zzop MCP server expose? zzop exposes 9 tools: analyze_repo, cross_repo, check_file, check_endpoint, check_coverage, and 4 more. Their descriptions and schemas cost roughly 6,315 tokens of context every time the server is loaded. ### What licence is the zzop MCP server under? zzop declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls. ## Links - Repository: https://github.com/eezz4/zzop - Website: https://eezz4.github.io/zzop/ - Changelog RSS feed: https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp.json - HTML version of this page: https://verifymcp.io/servers/eezz4-zzop/https-github-com-eezz4-zzop-releases-download-v0-36-0-zzop-mcp-linux-x64-gnu-mcp