Skip to main content
Glama

pkgproof-mcp

An MCP server that verifies an npm or PyPI package before you install it.

One tool, verify_package. It runs nine checks against pkgproof.net covering advisories, install scripts, typosquat and combosquat names, scope and declared-repository checks, and how the release differs from its predecessors, and answers safe, caution, block or does_not_exist with every reason labelled as fact or heuristic against its source.

The first verification each day is free and needs no configuration at all. No account, no key, no signup. Later calls the same day cost $0.05 in USDC, paid per call over x402, and only if you configure a wallet.

Install

Nothing to install or host: your MCP client runs the server itself. Needs Node 22 or newer.

Every release from 0.1.1 on is built and signed by CI and carries an npm provenance attestation tying the tarball to the commit and workflow run that produced it. A tool that vets other packages should be checkable the same way:

npm audit signatures

The server is also listed in the MCP Registry as net.pkgproof/pkgproof.

Related MCP server: lockfile-guardian

Free, no key

Add this to your MCP client configuration and you are done:

{
	"mcpServers": {
		"pkgproof": {
			"command": "npx",
			"args": ["-y", "@pkgproof/mcp"]
		}
	}
}

Claude Code

The repository is its own plugin marketplace, so there is no JSON to edit:

/plugin marketplace add jahija-okan/pkgproof-mcp
/plugin install pkgproof@pkgproof

The plugin runs the published package pinned to the version it was released beside, not whatever npx resolves to that day.

Claude Desktop

Releases carry a prebuilt .mcpb bundle on the releases page. Download it and open it: Desktop installs the server and holds the wallet keys in the OS secret store rather than in a plain-text configuration file.

The tool

verify_package, and nothing else. One call is one verification, so the daily allowance means the same thing here as it does over HTTP.

Argument

Required

Meaning

name

yes

Package name: left-pad, @scope/thing (npm), requests (PyPI).

version

no

Exact version. Omit to verify the package rather than one release.

ecosystem

no

npm (the default) or pypi.

It answers twice over: a summary the agent reads, and the service's own JSON alongside it in structuredContent, under a declared output schema, carrying the verdict, every reason with its source, and the time the verdict was computed.

Calls run one at a time. The service allows one verification in flight per payer and refuses the second, so an agent walking a dependency list is queued here rather than failed.

Two networks

pkgproof settles on two chains, each on its own endpoint. They are not interchangeable: they take different key formats, and only one of them has a free tier.

Algorand Mainnet

Base

Endpoint

x402-algo.pkgproof.net

x402.pkgproof.net

Network

algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=

eip155:8453

Asset

USDC, ASA 31566704

USDC, 0x8335…2913

Price

$0.05 per verification

$0.05 per verification

Free tier

no, every call is paid

yes, one verdict per caller per day

Key variable

PKGPROOF_ALGORAND_PRIVATE_KEY

PKGPROOF_BASE_PRIVATE_KEY

Key format

base64 account key

0x-prefixed EVM key

Network fee per payment

none, sponsored

none, sponsored

One-time setup

~0.3 ALGO, and an opt-in to the asset

none, just send USDC

How the server picks. The free attempt always goes to Base, because it is the only rail that answers an unpaid call. Payments prefer Algorand, and fall back to Base only when no Algorand key is configured. So a wallet on either chain works, and configuring neither still gets you a verdict a day.

Paid, with a wallet

WARNING

Fund a throwaway wallet, never a main one. The key is stored in plain text in your MCP client's configuration file, which is not an encrypted store, and anything able to read that file can spend the wallet. Put in what you are willing to spend on package verification and nothing more. There is deliberately no spend cap in this server, so the wallet's own balance is the only limit.

Algorand (preferred)

Verifications cost the account no ALGO. The 402 names a fee payer, so the facilitator covers the network fee on every payment and your ALGO balance does not move.

{
	"mcpServers": {
		"pkgproof": {
			"command": "npx",
			"args": ["-y", "@pkgproof/mcp"],
			"env": {
				"PKGPROOF_ALGORAND_PRIVATE_KEY": "..."
			}
		}
	}
}

Base

Send USDC on Base to the throwaway wallet's address. You do not need ETH: payment is an off-chain signature and the facilitator pays the gas.

{
	"mcpServers": {
		"pkgproof": {
			"command": "npx",
			"args": ["-y", "@pkgproof/mcp"],
			"env": {
				"PKGPROOF_BASE_PRIVATE_KEY": "0x..."
			}
		}
	}
}

The server always tries the free call first, so a configured wallet is only charged once the day's free verification is used up.

Configuration

Variable

Required

Meaning

PKGPROOF_ALGORAND_PRIVATE_KEY

no

Throwaway Algorand account holding USDC on Mainnet, base64. Preferred for payment when set.

PKGPROOF_BASE_PRIVATE_KEY

no

Throwaway EVM wallet holding USDC on Base, 0x-prefixed. Used when no Algorand key is set.

With neither set, the server is free-tier only and says so once the day's verification is spent.

Easy setup, step by step

Needs Node 22 or newer. Use a throwaway account, as warned above.

  1. Generate a throwaway Algorand account. This downloads a small helper script that creates a fresh account on your machine:

    git clone https://github.com/jahija-okan/pkgproof-x402-algorand
    cd pkgproof-x402-algorand
    npm install
    npx tsx algo-account.ts new

    It prints ADDRESS, KEY_B64 and MNEMONIC once and saves nothing. Keep them somewhere safe, such as a password manager. Use KEY_B64 everywhere below, never the 25-word MNEMONIC.

  2. Send 0.3 ALGO to ADDRESS. Buy ALGO on an exchange and withdraw it on the Algorand network. A new account is empty and cannot do anything until it holds ALGO. This covers the account's minimum balance and the opt-in fee, and is a one-time cost. Verifications themselves cost no ALGO.

  3. Opt the account into USDC. Algorand accounts must opt into an asset before they can receive it, so USDC sent to an account that has not opted in will not arrive. This command signs that opt-in with your key:

    ALGOD_URL=https://mainnet-api.algonode.cloud ASSET_ID=31566704 \
    ALGO_PRIVATE_KEY=<KEY_B64> npx tsx algo-account.ts optin
  4. Send USDC on Algorand to ADDRESS. Withdraw USDC from an exchange on the Algorand network, not Base or Ethereum. Each verification costs $0.05, so $1 covers 20 of them.

  5. Check that both arrived. This reads the account from the network and prints its ALGO balance and USDC balance. NOT OPTED IN means step 3 did not go through:

    ALGOD_URL=https://mainnet-api.algonode.cloud ASSET_ID=31566704 \
    npx tsx algo-account.ts balance <ADDRESS>
  6. Add the server to Claude Code. This registers pkgproof as an MCP server and hands it the key, which it uses to sign payments on your machine and never sends anywhere. --scope user installs it for every project, without it, Claude Code registers the server for the current directory only:

    claude mcp add --scope user pkgproof -e PKGPROOF_ALGORAND_PRIVATE_KEY=<KEY_B64> -- npx -y @pkgproof/mcp
  7. Run a verification. Start claude and ask: check package crossenv with pkgproof. Claude calls the verify_package tool and reports a verdict with its reasons.

The first verification each day is free and goes through Base. Later ones are paid from the Algorand account.

Privacy Policy

One HTTPS request per verification, carrying the package name, version and ecosystem you asked about and nothing else: no account, no telemetry, no file contents. Wallet keys are used to sign locally and are never transmitted. Full text in PRIVACY.md.

Development

npm install
npm test           # unit tests, and a real client handshake over an in-memory transport
npm run lint       # typecheck, formatting, eslint
npm run inspector  # build, then the MCP inspector against the local server

No test spends anything, and the suite enforces it rather than trusting it: a test that reaches for the network fails, and the run refuses to start at all if a wallet key is set in the environment. The payment path is exercised against a fabricated 402 and a published test account, so an EIP-3009 authorisation is signed locally and the payload and header are checked without a wallet.

License

Apache-2.0. If you distribute a modified version, section 4(b) requires you to mark the files you changed: a fork of a security tool that still carries this name should not be mistakable for this one.

Available Tools

1 tool
verify_packageVerify packageA

Verify an npm or PyPI package before installing it. Runs up to nine checks covering advisories, install scripts, typosquat and combosquat names, scope and declared-repository checks, and how the release differs from its predecessors, and answers safe, caution, block or does_not_exist with every reason labelled as fact or heuristic against its source. One call is one verification: the first each day is free, and later ones cost $0.05 in USDC when a wallet is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesPackage name: left-pad or @scope/thing on npm, requests on PyPI.
versionNoExact version to verify. Omit to verify the package rather than one release.
ecosystemNoPackage ecosystem: npm or pypi.npm

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameYes
reasonsYesEvery reason behind the verdict.
sourcesYesThe datasets consulted, by name and URL.
verdictYes
versionYesThe version verified, or null if none was given.
dist_tagNoThe dist-tag a version-less request resolved through; null when a version was given.
ecosystemYes
checked_atYesWhen the verdict was computed, ISO 8601 UTC.
resolved_versionNoThe release the checks ran against: the version asked for, or the registry's latest.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the check inventory, the four possible verdicts, and that every reason is labelled as fact or heuristic against its source. Critically, it discloses cost behavior (first call each day free, later calls $0.05 USDC when a wallet is configured), which an agent must know before invoking. The readOnlyHint=false and openWorldHint=true annotations are consistent with a tool that performs live external lookups and can charge a wallet.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are front-loaded in the first sentence, with mechanism and cost following. The enumeration of nine checks is dense but each item is substantive; the cost sentence is longer than strictly necessary but earns its place since pricing affects invocation decisions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema, the description need not explain return structure, and it still characterizes the verdict vocabulary and fact/heuristic labelling. Combined with the documented checks, verdict outcomes, and payment terms, an agent has everything needed to decide whether and how to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents name formats (left-pad, @scope/thing, requests), the version-omission semantics, and the npm/pypi enum with default. The description adds only ecosystem context (npm or PyPI) that the schema already carries, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Verify an npm or PyPI package') plus the exact scope of work (up to nine checks across advisories, install scripts, typosquat/combosquat names, scope/repository checks, and release diffs). It also names the possible outcomes (safe, caution, block, does_not_exist), so an agent knows precisely what the call produces. There are no siblings to disambiguate against, but the purpose is unambiguous on its own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before installing it' gives a clear triggering context, and 'One call is one verification' defines the unit of invocation, which helps an agent decide when to call once vs. multiple times. It does not state a when-not-to-use case (e.g., cached results, already-installed packages), but with no alternatives available that gap is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.1
    • Changedverify_package3 fields changed
      • changedInput schema / properties / ecosystem / description
        Previous value: -"Package ecosystem. Only npm is supported."New value: +"Package ecosystem: npm or pypi."
      • changedInput schema / properties / ecosystem / enum
        Previous value: -[
        -  "npm"
        -]New value: +[
        +  "npm",
        +  "pypi"
        +]
      • changedInput schema / properties / name / description
        Previous value: -"Package name, scoped or not: left-pad, @scope/thing."New value: +"Package name: left-pad or @scope/thing on npm, requests on PyPI."
  2. 1 tool updatev0.1.12
    • Changedverify_package2 fields changed
      • addedOutput schema / properties / dist_tag
        Added value: +{
        +  "description": "The dist-tag a version-less request resolved through; null when a version was given.",
        +  "type": [
        +    "string",
        +    "null"
        +  ]
        +}
      • addedOutput schema / properties / resolved_version
        Added value: +{
        +  "description": "The release the checks ran against: the version asked for, or the registry's latest.",
        +  "type": [
        +    "string",
        +    "null"
        +  ]
        +}
  3. 1 tool updatev0.1.0
    • First observedverify_package

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusing it with another operation. Its purpose (verify an npm/PyPI package before install) is stated precisely, so misselection is not a concern.

Naming Consistency5/5

verify_package uses a clean, predictable verb_noun snake_case pattern. A one-tool surface cannot exhibit convention mixing, so consistency is trivially perfect.

Tool Count3/5

One tool is thin for a server, even though the tool deliberately aggregates nine checks and four verdicts into a single call. It is defensible as a focused single-purpose service, but it sits at the borderline of feeling under-scoped.

Completeness4/5

The single call covers the core verification lifecycle well: advisories, install scripts, typosquat/combosquat, scope, repository, and release diffing, with labelled fact/heuristic reasoning. Minor gaps remain (no batch/multi-package verification, no result caching or history retrieval), but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Audits npm packages for supply-chain attacks (typosquatting, malicious install scripts, credential exfiltration) before installation, returning a SAFE/SUSPICIOUS/DANGEROUS verdict.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Audits your package-lock.json for supply-chain attacks before install. Cross-checks every resolved entry against the live npm registry to detect integrity mismatches, new install scripts, and other malicious signals.
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Verifies npm package names for safety, detecting typosquats and nonexistent packages before your coding agent installs them.
    2
    8 npm
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI coding agents to automatically verify npm packages against the live registry before installation, flagging hallucinated, slopsquatted, or otherwise suspicious packages with risk verdicts.
    1 npm
    MIT