Skip to main content
Glama
jahija-okan

pkgproof

by jahija-okan

pkgproof-mcp

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

One tool, verify_package. It runs eight checks against pkgproof.net covering advisories, install scripts, typosquat and combosquat names, scope, repository provenance and maintainer reputation, 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 20 or newer.

Related MCP server: npm-guardian

Free, no key

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

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

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, scoped or not: left-pad, @scope/thing.

version

no

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

ecosystem

no

Defaults to npm, the only ecosystem this service covers.

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.

Setting the account up does cost ALGO, once. An Algorand account cannot receive an asset until it opts into it, so USDC sent to an account that has not opted in will not arrive. Three steps, in this order:

  1. Fund the throwaway account with about 0.3 ALGO. Algorand locks 0.1 as the account's minimum balance, another 0.1 for as long as it holds USDC, and the opt-in transaction itself costs a fee.

  2. Opt into ASA 31566704 (USDC on Mainnet). This is a zero-amount transfer from the account to itself; any Algorand wallet will do it.

  3. Send USDC to the account.

The key is the base64 account key, not a 25-word mnemonic.

{
	"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.

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. The payment path is exercised against a fabricated 402 and a published test account: an EIP-3009 authorisation is signed locally, so the payload and the header are checked without a wallet or a network.

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 package before installing it. Runs eight checks covering advisories, install scripts, typosquat and combosquat names, scope, repository provenance and maintainer reputation, 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, scoped or not: left-pad, @scope/thing.
versionNoExact version to verify. Omit to verify the package rather than one release.
ecosystemNoPackage ecosystem. Only npm is supported.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.
ecosystemYes
checked_atYesWhen the verdict was computed, ISO 8601 UTC.

TDQS

A5/5.0
Behavior5/5

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

Describes the eight check areas, the verdicts returned, and that each reason is labelled as fact or heuristic with a source. It also discloses the paid nature and one-verification-per-call behavior, consistent with the annotations indicating non-read-only and non-idempotent behavior.

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

Conciseness5/5

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

The description is dense but every clause carries useful information: purpose, checks, verdicts, labelling, and cost. There is no filler or vague wording.

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?

Covers what the tool does, what it returns, and the operational constraints (cost, one call per verification, daily free limit). It is self-contained for an agent to decide when and how to invoke it, especially with the output schema available.

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

Parameters5/5

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

The input schema already provides detailed parameter descriptions, and the tool description reinforces them by mentioning scoped names, optional version omission, and npm-only ecosystem support. Parameter meaning is fully unambiguous.

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?

Clearly states the tool's purpose: verifying an npm package before installation, and enumerates the check categories and verdict types. It is specific about the resource and behavior, leaving no ambiguity even without sibling tools.

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

Usage Guidelines5/5

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

Explicitly advises use before installing a package and clarifies that one call verifies one package. It also provides operational details such as the daily free call and subsequent cost, making usage boundaries clear.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedverify_package

TDQS

A4.9/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlap.

Naming Consistency5/5

The single tool name 'verify_package' follows a clear verb_noun pattern.

Tool Count3/5

While the server has a narrow focus, having only one tool feels thin; however, the tool is comprehensive and covers many verification aspects, so it is borderline acceptable.

Completeness5/5

The single tool appears to fully cover the intended domain of package verification, including security, provenance, and reputation checks, with no obvious missing functionality.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
    C
    maintenance
    Verifies npm package names for safety, detecting typosquats and nonexistent packages before your coding agent installs them.
    2
    19
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jahija-okan/pkgproof-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server