Skip to main content
Glama

pkg-oracle — Dependency Trust Oracle

Server Details

Blocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Available Tools

1 tool
verify_packageVerify PackageAInspect

Dependency Trust Oracle. Call this BEFORE writing any package into a manifest (package.json, requirements.txt, pyproject.toml, ...). It checks whether the package actually exists on its registry, cross-references OSV.dev for known CVEs, pulls the package's OpenSSF Scorecard via deps.dev, and runs a Levenshtein-distance typosquat/slopsquat check against a curated list of popular packages combined with the package's publish age. Returns a synthetic verdict: ALLOW (no issues found), WARN (proceed with caution — read the findings before installing), or BLOCK (do not install — likely a hallucinated package name, an active typosquat, or a known critical/high-severity vulnerability). Always call this before running an install command for a package you have not already verified in this session. First 5 calls per caller are free; after that this tool requires x402 payment (USDC on Base) and will return a payment-required error with the amount and address to pay.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesExact package name as it would appear in the manifest (case-sensitive for npm scoped packages).
versionNoOptional exact version string to verify (e.g. "4.17.21"). Omit to check only the package name.
ecosystemYesPackage registry to check the name against.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it lists the checks performed, explains the meaning of each verdict, and reveals the payment requirement after five calls. It also notes the error behavior (payment-required with amount and address). This goes well beyond a generic 'verify package' statement.

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?

The description is front-loaded with the critical trigger ('Call this BEFORE...') and then gives details. It is a bit long but every sentence conveys necessary operational information; only minor overlap exists between the two 'call before' statements.

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?

The tool has no output schema, so the description's explanation of the ALLOW/WARN/BLOCK verdicts is essential and provided. It also covers the payment model, making the tool fully understandable for an agent to invoke correctly.

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 coverage is 100%, so the schema already fully documents name, version, and ecosystem. The description adds broad behavioral context (e.g., registry check, publish age) but does not clarify parameter formats or edge cases beyond the schema. Baseline 3 applies.

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?

The description states a specific job ('Dependency Trust Oracle') and enumerates the concrete verification steps: registry existence, OSV CVE cross-reference, OpenSSF Scorecard, and typosquat detection. It also defines the output verdicts (ALLOW/WARN/BLOCK), making the tool's purpose unmistakable. No sibling tools exist, so no differentiation is needed.

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?

The description explicitly says to call it before writing a package into a manifest and before any install of a not-yet-verified package, and implies it is unnecessary for already verified packages. It also discloses the 5-call free tier and subsequent payment requirement, which is critical usage context. No alternatives are named, but no siblings exist to compare against.

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 update
    • First observedverify_package

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Related MCP Servers

  • 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    Validates and checks packages across 19 ecosystems to prevent AI agents from installing hallucinated, deprecated, or malicious packages.
    117
    AGPL 3.0
  • 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.
    0
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Pre-install risk gate for npm packages. Stops AI coding agents from running malicious or lifecycle scripts run.
    1
    2
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or misselection. The purpose of verify_package is singular and unambiguous: assess a package before installation.

Naming Consistency5/5

The single tool name follows a clear verb_noun convention (verify_package). With only one tool, there are no inconsistencies or mixed naming styles to penalize.

Tool Count3/5

A single tool for a package-trust oracle feels slightly thin, even though this one tool is substantive and not trivial. Companion operations such as auditing a manifest or fetching detailed vulnerability data could make the surface more complete.

Completeness4/5

The tool covers a full verification workflow: package existence, known vulnerabilities, scorecard, typosquat risk, and publish age, ending in an actionable verdict. Minor gaps exist, such as no batch/manifest-level audit or separate detailed findings lookup, but agents can work around them by calling per package.

Resources