Last scanned (6 hours ago)
Scores higher than 95% of PyPI servers
Category Developer Tools
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
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 1 of 35 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to hslee16/Archy). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 1 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability69
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 4363 tokens (~311/item across 14 items; 14 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 Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 14 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
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 →
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.
- 5 Nov 26 +15
- Malware scan: unverified → pass ▲ security
- 4 Nov 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 0.53.2 → 0.53.3 functional
- 3 Nov 26 0
- Stability: 0.97 → pass security
- 2 Nov 26 0
- Stability: pass → 0.97 functional
- 1 Nov 26 0
- Stability: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: 100 → unverified ▼ functional
- Package version: 0.53.0 → 0.53.2 functional
- Package version: 0.53.0 → 0.53.1 functional
- 31 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- 30 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 0.52.0 → 0.53.0 functional
- 28 Oct 26 0
- Stability: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: 100 → unverified ▼ functional
- Package version: 0.50.0 → 0.52.0 functional
- Package version: 0.50.0 → 0.51.0 functional
- Package version: 0.50.0 → 0.50.1 functional
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 pypi/archy@0.53.3
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | hslee16/Archy |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/hslee16/Archy/.github/workflows/publish.yml@refs/tags/v0.53.3 |
| Rekor log index | 3684837103 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:2ca9af99c0715be50bd41d9cfb9ea6c259d7dd0d5ad64a2d25a5b7f298afbfd8 |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | Known build tool | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 35 packages
| Packages resolved | 35 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
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 →
archy_brief One bounded briefing before touching an unfamiliar repository ~255
**Call once, before starting on an unfamiliar repository.** Composes `archy_conventions` (naming, mirrored surfaces, gates, export and doc gaps), the layer `coverage` of `archy.yaml` and, with `contracts=True`, the transitive import-linter verdict, into one answer to 'what do I need to know before I touch this'. `top_n` (default 8) bounds the ranked sections and `conventions.totals` says how many were dropped; `gates`, `errors`, `export_gaps` and `doc_gaps` are never truncated. `coverage` is null when there is no usable archy.yaml. This tool does NOT run the direct-edge check, so `transitive_checked=false` with a `transitive_unverified_reason` means the `forbid` rules are unverified, not that they hold; pass `contracts=True` to settle it. It is ranked and truncated like `archy_conventions`, so for a negative call `archy_module_view`. Advisory: mutates nothing.
| Name | Type | Req | Description |
|---|---|---|---|
| contracts | boolean | – | – |
| include_tests | boolean | – | – |
| path | string | yes | – |
| top_n | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| contracts | – | – | – |
| conventions | – | yes | – |
| coverage | – | – | – |
| transitive_checked | boolean | – | – |
| transitive_unverified_reason | – | – | – |
No examples provided.
archy_check Check layer boundaries ~462
**Call after any Python edit that adds, removes, or changes an import statement.** Returns forbidden direct edges between layers declared in archy.yaml under `violations`, plus Stable Dependencies Principle violations (when `sdp.enabled: true` in archy.yaml) under `sdp_violations`. Empty lists on both mean no direct boundary crossings. `required_violations` reports the INVERSE constraint: `required:` rules in archy.yaml declare that every module matching `source` must TRANSITIVELY reach `must_reach` (e.g. every standalone entrypoint must reach a model registry that has to be imported before the framework configures itself). Reach counts indirect paths and the implicit package-`__init__` import, so satisfying such a rule once in a package `__init__.py` covers its submodules; each violation carries a `detail` saying which module fails and why, and a rule whose patterns match nothing is reported as a violation rather than passing silently. Fix by adding the missing import, not by deleting the rule. Pass `contracts=True` to ALSO run the transitive (multi-hop) import-linter contracts (Layers, Forbidden, Independence, Protected, AcyclicSiblings) - stricter than the direct archy.yaml edges - nested under the `contracts` field; a failed contract means an indirect import path violates the architecture, so restructure rather than weaken the rule. That path reads .importlinter (or pyproject.toml, override with `contracts_config_path`, relative to `path`) and needs `pip install archy[contracts]`; if the extra is absent, `contracts` comes back with `available=false` and an advisory rather than raising (replaces the removed archy_contracts tool). If no archy.yaml is found, returns an in-band CheckErrorPayload (an `error` field, not a raised error) so you can create one or pass `config_path` (relative to `path`), and contracts are not run in that case; a malformed archy.yaml instead raises (it cannot be checked against).
| Name | Type | Req | Description |
|---|---|---|---|
| config_path | – | – | – |
| contracts | boolean | – | – |
| contracts_config_path | – | – | – |
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_conventions Report the project's house style ~544
**Call before adding a new class, field, or command to an unfamiliar project.** Derives the repository's own conventions from its source instead of leaving you to infer them by reading. Returns five censuses: `naming` (class-name suffix families GROUPED BY HOME MODULE, so the module you are about to edit shows its own patterns - the answer to 'what do I call a new one and where does it go'), `surfaces` (mirrored helper sets like `_x_to_text`/`_x_to_json` and names defined in several modules - the answer to 'how many places must I wire a new field'), `gates` (sites where a FAILED FINDING exits non-zero, each with its literal exit `code` and the lever that controls it: `flag:--strict`, `config:<attr>`, `param:<name>`, or `hardcoded` - the answer to 'should my new finding fail the build or only warn'), `errors` (the separate, usually much larger set of USER-ERROR exits - bad config, missing file - which say nothing about gating and are kept apart so the gate count stays meaningful), `models` (base-class, frozen, and tuple-vs-list census over the value types), `bases` (kind families grouped by what they derive from TRANSITIVELY, counting only bases this project defines - a family reached through an intermediate class is reported under the base that names it, and suffix agreement is stated so a family whose name is not the rule says so), `registries` (`NAME = Ctor(...)` families with the distribution of every keyword passed - how a project declares codes, messages, or flags when it does not use classes), `export_gaps` (family members absent from an `__all__`, or from a `from .x import Y as Y` block, that already lists their siblings) and `doc_gaps` (members the project's own `.rst`/`.md` surface does not name, where it already documents most of the family). Advisory only; it never fails and mutates nothing. `min_family` raises the floor for reporting a family (default 2, raise it on a large project to cut noise). `include_tests` censuses test modules too (default false:…
| Name | Type | Req | Description |
|---|---|---|---|
| include_tests | boolean | – | – |
| min_family | integer | – | – |
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| bases | array | – | – |
| doc_gaps | array | – | – |
| docs_scanned | integer | – | – |
| errors | array | yes | – |
| export_gaps | array | – | – |
| gate_codes | array | yes | The literal exit statuses this project fails findings with. |
| gate_modules | array | yes | Modules that fail the build on a FINDING. Everything else is advisory -- user-error exits live in `errors` and say nothing about whether a new finding should gate. |
| gates | array | yes | – |
| models | – | yes | – |
| modules_scanned | integer | yes | – |
| modules_unparsed | integer | yes | – |
| naming | array | yes | – |
| partition | – | – | – |
| registries | array | – | – |
| root | string | yes | – |
| surfaces | array | yes | – |
| unparsed_modules | array | – | – |
No examples provided.
archy_cycles Find import cycles ~62
Find import cycles (Tarjan SCCs of size >= min_size, plus self-loops) in a Python project. Returns cycles sorted largest-first.
| Name | Type | Req | Description |
|---|---|---|---|
| internal_only | boolean | – | – |
| min_size | integer | – | – |
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
archy_diff Diff against baseline ~162
Compare the current project state to the last snapshot. Returns a risk-weighted `summary` (headline + top regressions / improvements), per-component score deltas, and the cycles and layer violations that have been added or resolved since the baseline. Use after edits to localize regressions; see the `loop` prompt. `strict=True` with `baseline` (a committed file, relative to `path`) adds `strict`. `passed` is false when a cycle or layer violation is new, or when archy.yaml removes or narrows a rule the baseline fingerprint records. `reason` names it. A baseline with no fingerprint still checks cycles and violations.
| Name | Type | Req | Description |
|---|---|---|---|
| baseline | – | – | – |
| path | string | yes | – |
| strict | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_dsm Design Structure Matrix ~306
Design Structure Matrix view of the import graph. `response_format='summary'` (the DEFAULT) returns a compact overview -- block structure (group labels + sizes), counts, the back-edges (source later than target in the ordering = the cycle signal), and inter-block coupling -- without the full cell list, so a routine call stays small. `response_format='full'` returns the full matrix the agent reads positionally: cell (row=source, col=target) is non-empty when source imports target; it refuses matrices with more than 2000 cells with a DSMTooLargePayload (narrow with `focus`/`package`, or read the summary). Use `group_by='community'` for block-diagonal cohesion, `group_by='layer'` for layer-violation forensics, or `group_by='topological'` to localize back-edges. Narrow large projects with `focus` (qualname + focus_depth-hop neighborhood) or `package` (qualname prefix). When `baseline_path` (relative to `path`) is provided, returns a DSMDiff regardless of response_format (`new_back_edges` flags cycles the edit just introduced).
| Name | Type | Req | Description |
|---|---|---|---|
| baseline_path | – | – | – |
| focus | – | – | – |
| focus_depth | integer | – | – |
| group_by | string | – | – |
| package | – | – | – |
| path | string | yes | – |
| response_format | string | – | – |
| weight | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_duplicates Duplicate-function clusters ~440
Cluster functions with an identical normalized body shape (identifiers/literals folded to placeholders). Returns two tiers: `duplicates` (the primary 'likely duplicate' list to investigate) and `variants` (demoted clusters that are likely intentional: same-class siblings, boilerplate, copies wholly in test suites or vendoring/isolation dirs, and - with `co_change` (the DEFAULT) - `independent` copies whose files are actively maintained yet never co-change in git, i.e. deliberately parallel implementations; each carries a `variant_reason`). Within the primary tier, `exact=true` marks byte-identical (Type-1) clusters, the highest-confidence 'definitely refactor these' subset. `min_nodes` (default 30) is the minimum normalized AST-node count, skipping trivial getters/stubs. This is an advisory SURFACER, never a score axis: refactorability is a semantic call the reader (you) makes, so a cluster means 'investigate,' not 'provably identical' (the co-change demotion lifts primary precision above the ~50% syntactic ceiling by moving benign parallel copies to variants). `near_miss=true` (opt-in, slower) adds a `near_miss` tier: Type-3 (gapped) clones - a copy with statements inserted/removed that the exact shape-hash cannot see - found by token-multiset overlap, each with a `similarity`. LOWER confidence than the shape tiers; use it for recall (the exact hash finds ~0% of Type-3). `response_format='summary'` (the DEFAULT) returns each cluster's ranking fields plus one sample member; `response_format='full'` returns the complete member lists. `co_change=false` skips the git pass. An empty `duplicates` with a `note` is a real answer.
| Name | Type | Req | Description |
|---|---|---|---|
| co_change | boolean | – | – |
| members | integer | – | – |
| min_nodes | integer | – | – |
| near_miss | boolean | – | – |
| path | string | yes | – |
| response_format | string | – | – |
| top_n | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| duplicated_functions | integer | yes | – |
| duplicates | array | yes | – |
| exact_total | integer | yes | – |
| min_nodes | integer | yes | – |
| near_miss | array | yes | – |
| near_total | integer | yes | – |
| note | – | yes | – |
| shown | integer | yes | – |
| total | integer | yes | – |
| variant_total | integer | yes | – |
| variants | array | yes | – |
No examples provided.
archy_graph Inspect dependency graph ~306
Inspect the dependency graph. With no `focus`, `response_format='summary'` (the DEFAULT, replaces the removed archy_graph_summary) returns a compact top-N overview (modules by fan-in, fan-out, PageRank, and edit-risk, plus top external deps; `top_n` controls N) so a routine call doesn't dump the whole graph into context; `response_format='full'` returns the complete node/edge dump matching `archy graph --format json`, but refuses graphs larger than `max_nodes` (default 500, must be >= 1) with a GraphTooLargePayload (bump it explicitly, or narrow with `focus`). Pass `focus=[<qualname or path>]` (replaces the removed archy_graph_focus) for a bounded subgraph centered on those modules: `depth` caps hop distance and `direction` is 'in' (who depends on me), 'out' (my dependencies), or 'both'; each edge carries the source line numbers of the import statements. With `focus` set, `response_format`/`max_nodes`/`top_n` do not apply (the neighborhood is already bounded).
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| direction | string | – | – |
| focus | – | – | – |
| internal_only | boolean | – | – |
| max_nodes | integer | – | – |
| path | string | yes | – |
| response_format | string | – | – |
| top_n | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_impact Compute change blast radius ~585
Given a list of changed file paths, return what they affect. `mode='blast'` (the DEFAULT) returns the internal modules that transitively import any of them (the blast radius): use before refactoring or removing a module to see what would break. An empty `impacted` means no STATIC importer was found, not that removal is safe: archy cannot see importlib.import_module / __import__, entry points and plugin registries, Django INSTALLED_APPS, pytest plugins, config-driven dispatch, module __getattr__ hooks or string-keyed factories, so `rg` for those before deleting (`empty_caveat` is set whenever this applies). `propagation_cost` is the MacCormack-style scalar (fraction of internal modules the edit set can reach); `chains` explains *why* each impacted module is reachable (the shortest import path back to a changed module, hop by hop with the line numbers where each import lives) so you can cite the specific edge(s) to preserve. Chains are ranked closest-first and capped at `max_chains` (negative for all); `chains_omitted` reports how many were left out. `mode='affected'` (replaces the removed archy_affected) is the CI-shaped lookup instead: it returns the impact pre-classified into `impacted_tests` and `impacted_modules`, with traversal depth-capped (`depth`, default 5) so a single-line edit doesn't fan out to thousands of nodes; an empty `impacted_tests` carries the same static-only `empty_caveat` (no test imports it statically, not that no test exercises it). Test detection uses pytest conventions (test_*.py, *_test.py, files under tests/) unless `test_filter` overrides with a recursive glob. Files that resolve to no module are returned in `unresolved`, except a `.py` path that is missing inside the project, which is `deleted` with `deleted_reason` (the scan sees only the current tree, so its dependents are not selected). Internal modules only. `co_change=true` (blast mode only, opt-in) adds a `co_changed` list: modules that historically co-change with the edited set…
| Name | Type | Req | Description |
|---|---|---|---|
| co_change | boolean | – | – |
| depth | integer | – | – |
| files | array | yes | – |
| max_chains | integer | – | – |
| mode | string | – | – |
| path | string | yes | – |
| test_filter | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_module_view Everything known about ONE module, complete and unranked ~312
**Call when the question is a NEGATIVE.** `archy_conventions` ranks and truncates, so a module's absence from it means nothing; every list here is COMPLETE for the one `module` named, so absence IS the answer, about STATIC edges only: an empty `imported_by` does not rule out importlib.import_module / __import__, entry points, plugin registries, INSTALLED_APPS, pytest plugins or config-driven dispatch, so `rg` for those before calling a module dead. Use it for `does risk import hotspots`, `does anything still reach layers`, `is this module dead`. Returns `imports_internal` (the project modules this one imports, with relative imports resolved), `imported_by` (every project module that imports it, tests included even when they are otherwise set aside, because a module imported only by tests IS imported), `classes`, `functions`, `exports` (null when the module declares no `__all__` and no explicit re-exports, which is different from an empty one), `suffix_families`, `gates` (its exit sites) and `status` - which says whether the module was censused or set aside and why, so an empty result is never mistaken for `nothing to report`. Raises on an unknown module name rather than returning an empty view. Advisory: mutates nothing.
| Name | Type | Req | Description |
|---|---|---|---|
| include_tests | boolean | – | – |
| module | string | yes | – |
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| census_complete | boolean | – | – |
| classes | array | yes | – |
| exports | – | yes | – |
| functions | array | yes | – |
| gates | array | yes | – |
| imported_by | array | yes | – |
| imports_internal | array | yes | – |
| module | string | yes | – |
| status | string | yes | – |
| suffix_families | array | yes | – |
| unparsed_modules | array | – | – |
No examples provided.
archy_score Score project structure ~248
Compute the composite quality score (modularity, acyclicity, depth, equality, complexity - geometric mean of five axes) for a Python project. `view='current'` (the DEFAULT) returns the five-axis score payload; optionally append the result to .archy/history.jsonl (record=True) and/or compare against the most recent recorded run as a regression gate (strict=True). `strict_tolerance` must be in [0, 1] (default 0.02). Pass record=True to record a baseline at session start (replaces the removed archy_record_baseline). `view='history'` instead reads the recent score history (.archy/history.jsonl), returning up to `last_n` rows oldest-first so you can compare deltas over time (replaces the removed archy_trend); last_n must be >= 1, and record/strict/strict_tolerance do not apply.
| Name | Type | Req | Description |
|---|---|---|---|
| internal_only | boolean | – | – |
| last_n | integer | – | – |
| path | string | yes | – |
| record | boolean | – | – |
| strict | boolean | – | – |
| strict_tolerance | number | – | – |
| view | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
archy_simulate Simulate import-edge change ~294
Counterfactual pre-edit check: given a proposed import-edge delta (`add` / `remove` lists of {from, to} module-or-path pairs), return the structural consequence BEFORE any file is written -- new/resolved cycles, new back-edges, new layer/SDP violations, per-axis score delta, and the propagation_cost change -- with a risk-ranked `summary` phrased conditionally ('would form a cycle'). Use it to test a refactoring hypothesis and reshape the plan before editing. Endpoints matching no internal module are returned in `applied.unresolved` with a `did you mean` in `applied.unresolved_hints`; a spec that could not be applied is listed in `applied.skipped`, and `applied.coverage` is `none` when no requested edge was simulated (the zero deltas then describe an unchanged graph, not a free edit) or `partial` when some were. Caveat: it models the graph delta you describe, not arbitrary code edits (it cannot move the complexity axis), and one submodule import (`a.b.c`) also implies edges to its ancestor packages -- include them in `add` to model it exactly (a lone submodule edge is a lower bound; see docs/research/SIMULATE_ORACLE_EMPIRICS.md).
| Name | Type | Req | Description |
|---|---|---|---|
| add | – | – | – |
| path | string | yes | – |
| remove | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| applied | – | yes | – |
| cycles | – | yes | – |
| new_back_edges | array | yes | – |
| propagation_cost | – | yes | – |
| required_violations | – | – | – |
| score_delta | – | yes | – |
| sdp_violations | – | yes | – |
| summary | – | yes | – |
| violations | – | yes | – |
No examples provided.
archy_snapshot Snapshot baseline ~135
Capture score, cycles, and layer violations to .archy/baseline.json as a baseline that archy_diff will compare against. Call at the start of an editing session. Also returns `invariant_brief`: the constraints to know before your first edit (declared layers, forbidden inter-layer edges, whether the graph is acyclic, the baseline score per axis, and the top load-bearing / highest-risk modules). Read it up front to avoid proposing a cross-layer or cycle-introducing edit, rather than being told after the diff. See the `loop` prompt for full usage.
| Name | Type | Req | Description |
|---|---|---|---|
| path | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| baseline_path | string | yes | – |
| cycles | array | yes | – |
| invariant_brief | – | yes | – |
| required_violations | array | – | – |
| score | – | yes | – |
| sdp_violations | array | – | – |
| violations | array | yes | – |
No examples provided.
archy_what_to_refactor_next Rank refactor priorities ~252
Ranked refactor-priority list (replaces the removed archy_hotspots and archy_high_risk_modules via `lens`). `lens='fused'` (the DEFAULT) merges the behavioral lens (cyclomatic complexity x git churn) and the structural lens (the edit-risk composite: central and fragile) into one summed priority, so a module flagged by both generally outranks a single-lens one. `lens='behavioral'` ranks CC x churn hotspots only (needs git; answers 'where is the refactoring leverage?'); `lens='structural'` ranks the edit-risk composite only (git-free; answers 'is this edit dangerous?'). Each entry says which lenses fired and carries a one-line `rationale`. `min_risk` (default 0.15) is the structural floor; pass 0 to surface every module on the structural lens. An empty `priorities` with a `note` is a real answer: there is genuinely nothing to prioritize.
| Name | Type | Req | Description |
|---|---|---|---|
| lens | string | – | – |
| min_risk | number | – | – |
| path | string | yes | – |
| since | – | – | – |
| top_n | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| git_available | boolean | yes | – |
| min_risk | number | yes | – |
| note | – | – | – |
| priorities | array | yes | – |
| shown | integer | yes | – |
| since | – | yes | – |
| total | integer | yes | – |
No examples provided.
How do I install the archy MCP server?
archy runs locally as a PyPI package, launched with uvx archy mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · archy
claude mcp add hslee16-archy -- uvx archy mcp
What is the archy MCP server?
archy is an MCP server listed in the public MCP registry as io.github.hslee16/archy. Architectural sensor for Python codebases. This page covers its PyPI package (archy).
Is the archy MCP server safe to use?
archy scores 92 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. 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 archy MCP server expose?
archy exposes 14 tools: archy_score, archy_cycles, archy_check, archy_impact, archy_snapshot, and 9 more. Their descriptions and schemas cost roughly 4,363 tokens of context every time the server is loaded.
Is the archy MCP server still maintained?
archy 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 archy MCP server under?
archy 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 archy MCP server?
VerifyMCP ran 16 checks on archy, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to a PyPI package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.