Skip to main content
Glama

PG1 Sovereign Threat Intelligence

check_package

PG1 Sovereign Threat Intelligence: a pre-install check for one npm or PyPI package - check before you install. No payment required - this tool is always free, and no AI model is involved. SIBLING DIFFERENTIATION: Use before installing or recommending a software package (npm or PyPI) only. Do NOT use for domains (use check_domain_age / check_hostname_reputation), CVE ids (use get_cve_details) or products by vendor name (use get_cve_by_product). BEHAVIOR: Returns { ecosystem, name, version_checked, exists, version_exists, first_published, age_days, latest_version, latest_published, reported_malicious, malicious_reports, vulnerabilities, lookalike_of, deprecated, install_scripts, attribution }. Signals: whether the package (and the version, if given) exists in the registry - a package that does not exist is a key signal, since names AI assistants invent get registered by attackers; first and latest publish dates; public malicious-package reports (OpenSSF Malicious Packages, via OSV.dev) for the version checked; known vulnerabilities for that version (OSV.dev: ids and severity only); whether the name looks like a popular package's (typosquat patterns); and, for npm only, the deprecated flag and install scripts (preinstall/install/postinstall). With no version, the latest version is checked. STATUS: "flagged" when the version is reported malicious (PACKAGE_REPORTED_MALICIOUS - worded "reported malicious" because such reports can be false positives), the package or version does not exist (PACKAGE_NOT_FOUND / PACKAGE_VERSION_NOT_FOUND), or the package is under 30 days old AND its name looks like a popular package's (PACKAGE_NEW_LOOKALIKE); otherwise "unknown" if any lookup did not complete (a failed registry lookup gives exists: null, never false); otherwise "no_flags". A look-alike name alone, a new package alone, known vulnerabilities, deprecation and install scripts are informational reasons that never flag on their own. This tool never returns "safe" or "clean"; no_flags means nothing was found in the sources checked. VALIDATION: one package per call; malformed input returns an MCP tool error (isError: true, code invalid_ecosystem, invalid_package_name or invalid_version). Registry answers are cached for 1 hour and malicious/vulnerability answers for 15 minutes. Rate-limited to 60 calls/hour per caller when unauthenticated; a valid Gumroad license key (X-API-KEY header) exempts the limit. Data sources and licences: https://pg1-ai-agent.vercel.app/docs/attributions

Input Schema

NameRequiredDescriptionDefault
nameYesMandatory package name, exactly one, e.g. 'lodash', '@types/node' or 'requests'.
versionNoOptional exact version to check, e.g. '4.17.21'. No ranges or tags. Defaults to the latest published version.
ecosystemYesMandatory package ecosystem: 'npm' or 'pypi'.

Output Schema

NameRequiredDescriptionDefault
nameYesThe name as given (trimmed).
noteNo
cachedYes
checksNoWhich underlying sources were checked for this result and whether each one completed.
existsYesWhether the package exists in the registry; null when the registry lookup did not complete (never false on a failure).
statusNo"unknown" whenever a source needed for this answer timed out, errored, or was skipped - never "no_flags" in that case.
reasonsNoMachine-readable reason codes for anything flagged in this result. Empty when nothing was flagged.
age_daysYesDays since the first publish.
ecosystemYes
deprecatedYesnpm only: whether version_checked is deprecated. null for PyPI or when unknown.
request_idNoUUID for this request, also sent as the X-Request-Id response header.
attributionYesAlways present: the data sources and a link to their licences.
lookalike_ofYesThe popular package this name looks like, if any.
test_fixtureNotrue only when the input was a documented integration test fixture and this response is canned; absent on real results.
canonical_nameNoThe name as the registry spells it, when the package exists.
latest_versionYes
version_existsYesWhether version_checked is published; null when unknown.
first_publishedYesISO timestamp of the first publish.
install_scriptsYesnpm only: the install-time scripts version_checked runs. null for PyPI or when unknown.
version_checkedYesThe version the malicious-report, vulnerability, deprecation and install-script signals describe: the requested version, or the latest one.
vulnerabilitiesYesKnown vulnerabilities for version_checked: id and severity only. null when not checked.
latest_publishedYesISO timestamp of the latest version's publish.
lookalike_patternNo
malicious_reportsYesReport ids (MAL-...).
version_requestedYes
reported_maliciousYestrue when a public malicious-package report covers the version checked (or the package, when no version could be determined); null when that lookup did not complete. Reports can be false positives.
deprecation_messageNonpm only: the publisher's deprecation message (untrusted text, cut to 300 characters).
vulnerabilities_omittedNoAdvisories left out because they come from a source outside PG1's licence-checked list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/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 burden and does so thoroughly: status semantics (flagged/no_flags/unknown), the important null-vs-false distinction for failed lookups, explicit warning that 'safe'/'clean' is never returned, caching TTLs, a 60 calls/hour rate limit, the X-API-KEY auth exemption, and the exact error codes on malformed input. This is far beyond what any annotation would provide.

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?

Long but deliberately structured with front-loaded labeled sections (SIBLING DIFFERENTIATION, BEHAVIOR, STATUS, VALIDATION) so an agent can scan to the relevant part. Some density is unavoidable given the disambiguation and status logic, though the full return-shape listing is partly redundant with the output schema.

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?

For a tool with an output schema, a 3-param schema, and no annotations, the description covers routing, status interpretation, failure modes, rate limits, auth, and data provenance. Nothing an agent needs to call this correctly or interpret the result is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all three parameters and the enum; baseline would be 3. The description adds meaningful semantics beyond it: 'with no version, the latest version is checked' clarifies the null default, 'one package per call' sets cardinality, and the invalid_ecosystem/invalid_package_name/invalid_version codes tie malformed inputs back to specific parameters.

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?

States a specific verb and resource ('pre-install check for one npm or PyPI package') and explicitly distinguishes itself from four sibling categories (domains, hostnames, CVE ids, vendor products) by naming the exact alternatives. An agent can route correctly without opening any schema.

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?

Gives explicit when-to-use ('before installing or recommending a software package') and when-not-to-use with the correct sibling for each excluded case ('use check_domain_age / check_hostname_reputation', 'get_cve_details', 'get_cve_by_product'). No inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.