pkg-oracle — Dependency Trust Oracle

Verify Package

verify_package

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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Exact package name as it would appear in the manifest (case-sensitive for npm scoped packages).
`version`	No	Optional exact version string to verify (e.g. "4.17.21"). Omit to check only the package name.
`ecosystem`	Yes	Package registry to check the name against.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

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.

All pkg-oracle — Dependency Trust Oracle tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?