pkgproof
An MCP server exposing one tool, verify_package, that screens an npm or PyPI package before you install it.
Verify a package: pass a
name(left-pad,@scope/thing, orrequests), optionally an exactversionand anecosystem(npmdefault, orpypi).Get a verdict:
safe,caution,block, ordoes_not_exist, based on up to nine checks (advisories, install scripts, typosquat/combosquat names, scope and declared-repository checks, release-to-release diffs).See the reasoning: each reason carries a
code,kind(factorheuristic),source,detail, and optionaldata, plus asourcesmap andchecked_attimestamp.Read structured output: the raw service JSON arrives in
structuredContentunder a declared output schema, includingresolved_versionanddist_tag.Run free once a day: the first verification per day needs no account, key, or signup.
Pay per call beyond that: later calls cost $0.05 in USDC over x402, using a throwaway Algorand (preferred) or Base wallet key.
Deploy easily: run via
npx @pkgproof/mcp, install as a Claude Code plugin, or open the prebuilt.mcpbbundle in Claude Desktop.Serialize calls: one verification in flight per payer, so list-walking calls queue rather than fail.
Provides tools to verify npm packages before installation, checking for security advisories, typosquatting, and other potential risks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@pkgproofCheck the npm package axios for security issues."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 signaturesThe 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@pkgproofThe 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 |
| yes | Package name: |
| no | Exact version. Omit to verify the package rather than one release. |
| no |
|
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 |
|
|
Network |
|
|
Asset | USDC, ASA | USDC, |
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 |
|
|
Key format | base64 account 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
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 |
| no | Throwaway Algorand account holding USDC on Mainnet, base64. Preferred for payment when set. |
| no | Throwaway EVM wallet holding USDC on Base, |
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.
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 newIt prints
ADDRESS,KEY_B64andMNEMONIConce and saves nothing. Keep them somewhere safe, such as a password manager. UseKEY_B64everywhere below, never the 25-wordMNEMONIC.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.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 optinSend 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.Check that both arrived. This reads the account from the network and prints its ALGO balance and USDC balance.
NOT OPTED INmeans step 3 did not go through:ALGOD_URL=https://mainnet-api.algonode.cloud ASSET_ID=31566704 \ npx tsx algo-account.ts balance <ADDRESS>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 userinstalls 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/mcpRun a verification. Start
claudeand ask:check package crossenv with pkgproof. Claude calls theverify_packagetool 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 serverNo 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.
Links
Service and docs: https://pkgproof.net/docs
MCP Registry entry: https://registry.modelcontextprotocol.io/v0/servers?search=pkgproof
OpenAPI, Base rail: https://x402.pkgproof.net/openapi.json
OpenAPI, Algorand rail: https://x402-algo.pkgproof.net/openapi.json
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 toolverify_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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name: left-pad or @scope/thing on npm, requests on PyPI. | |
| version | No | Exact version to verify. Omit to verify the package rather than one release. | |
| ecosystem | No | Package ecosystem: npm or pypi. | npm |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| reasons | Yes | Every reason behind the verdict. |
| sources | Yes | The datasets consulted, by name and URL. |
| verdict | Yes | |
| version | Yes | The version verified, or null if none was given. |
| dist_tag | No | The dist-tag a version-less request resolved through; null when a version was given. |
| ecosystem | Yes | |
| checked_at | Yes | When the verdict was computed, ISO 8601 UTC. |
| resolved_version | No | The release the checks ran against: the version asked for, or the registry's latest. |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.2.1- Changed
verify_package3 fields changed- changed
Input schema / properties / ecosystem / descriptionPrevious value: -"Package ecosystem. Only npm is supported."New value: +"Package ecosystem: npm or pypi." - changed
Input schema / properties / ecosystem / enumPrevious value: -[ - "npm" -]New value: +[ + "npm", + "pypi" +] - changed
Input schema / properties / name / descriptionPrevious value: -"Package name, scoped or not: left-pad, @scope/thing."New value: +"Package name: left-pad or @scope/thing on npm, requests on PyPI."
1 tool update
v0.1.12- Changed
verify_package2 fields changed- added
Output schema / properties / dist_tagAdded value: +{ + "description": "The dist-tag a version-less request resolved through; null when a version was given.", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / resolved_versionAdded value: +{ + "description": "The release the checks ran against: the version asked for, or the registry's latest.", + "type": [ + "string", + "null" + ] +}
1 tool update
v0.1.0- First observed
verify_package
TDQS
Scored across 1 tool
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.
verify_package uses a clean, predictable verb_noun snake_case pattern. A one-tool surface cannot exhibit convention mixing, so consistency is trivially perfect.
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.
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
Related MCP Connectors
Check npm packages for typosquats, hallucinated names, install scripts and risky new releases.
Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAudits npm packages for supply-chain attacks (typosquatting, malicious install scripts, credential exfiltration) before installation, returning a SAFE/SUSPICIOUS/DANGEROUS verdict.MIT
- AlicenseNot gradedqualityDmaintenanceAudits 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
- AlicenseAqualityDmaintenanceVerifies npm package names for safety, detecting typosquats and nonexistent packages before your coding agent installs them.28 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables 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 npmMIT