pkgproof
Provides tools to verify npm packages before installation, checking for security advisories, typosquatting, and other potential risks.
Click on "Install 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 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 |
| yes | Package name, scoped or not: |
| no | Exact version. Omit to verify the package rather than one release. |
| no | Defaults to |
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.
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:
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.
Opt into ASA
31566704(USDC on Mainnet). This is a zero-amount transfer from the account to itself; any Algorand wallet will do it.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 |
| 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.
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. 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.
Links
Service and docs: https://pkgproof.net/docs
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name, scoped or not: left-pad, @scope/thing. | |
| version | No | Exact version to verify. Omit to verify the package rather than one release. | |
| ecosystem | No | Package ecosystem. Only npm is supported. | 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. |
| ecosystem | Yes | |
| checked_at | Yes | When the verdict was computed, ISO 8601 UTC. |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
verify_package
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap.
The single tool name 'verify_package' follows a clear verb_noun pattern.
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.
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
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
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…
x402-gated safety checker for npm/PyPI packages before you npm install / pip install.
Blocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables checking npm packages for known security vulnerabilities using the OSV API before installation. Supports both single package checks and bulk vulnerability scanning for multiple packages at once.2-
- 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
- AlicenseAqualityCmaintenanceVerifies npm package names for safety, detecting typosquats and nonexistent packages before your coding agent installs them.219MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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