DepScope — an AI-native verification layer between agents and package registries

Hi all, I’m Vincenzo. Since my tip 3 days ago got decent reception, I figured I
owed the community the bigger picture — what this actually is, why we built it,
and what’s emerging in the real usage data.


The problem, in three pieces

Millions of AI coding agents — ChatGPT, Claude, Cursor, Copilot, Windsurf —
recommend npm / PyPI / Cargo packages every day to millions of developers. Three
things are broken at the same time:

  1. Tokens burned at scale. Each agent fetches raw registry JSON — ~3 KB of keys
    the model doesn’t actually need — to make a single install decision. Repeated
    billions of times a day across every agent, it’s real LLM input cost and real
    energy on the compute side.

  2. Stale training data. Cut off 6-12 months before the answer: recent CVEs
    missed, deprecated libraries still suggested, package names occasionally
    hallucinated (I’m seeing API requests for packages that don’t exist — the model
    invented the name based on a plausible pattern).

  3. No shared layer. Every agent hits the public registries independently,
    reinventing the lookup. Zero coordination, zero cache efficiency, zero
    consolidated signal.


What DepScope is

depscope.dev is the shared layer: OSV + GitHub Advisory Database as a live API,
a dedicated endpoint that returns a 74%-smaller payload than raw registry JSON
for the same install decision, and an MCP server for direct Claude / Cursor
integration. Covers 17 ecosystems (npm, PyPI, Cargo, Go, Maven, NuGet, RubyGems,
Composer, Pub, Hex, Swift, CocoaPods, CPAN, Hackage, CRAN, Conda, Homebrew).
402 vulnerabilities tracked with cross-ecosystem correlation. Open
infrastructure, MIT client SDK, EU-hosted.


Who we are, briefly

DepScope is a diversification project inside a company that has been operating
in digital for years. We haven’t raised VC and we’re not looking to. This gives
us a very different cost structure from the usual supply-chain security players
— and the freedom to keep the public API genuinely public, without quarterly
conversion pressure. When traffic scales beyond a certain threshold there will
be real infrastructure costs; we’ll cover them via parallel revenue streams
already in design (API Pro for commercial SLAs, threat-intel data feeds, private
instances) — none of which involves monetizing the public API an AI agent
queries. The neutrality of a verification layer depends on its independence.

The underlying positioning, for context: OSV (Google) and Sigstore (Linux
Foundation) are precedents of neutral public infrastructure for the supply chain
— but they were designed for humans and CI pipelines, returning raw JSON.
DepScope tries to do the same job from an AI-native perspective: useful
semantics in one round-trip, lightweight payload, endpoints shaped for LLM
decisions rather than human reading. I don’t know of anyone else building that
specific layer today.


What’s emerged in 72h of public data

  • 334 npm downloads of the MCP server (organic, zero ads)
  • 13,800+ API calls on /api/check/* today alone
  • The hallucinated-package signal is real — I see it daily in the logs.
    Model-invented names that follow naming conventions but don’t exist in any
    registry
  • Most-queried by agents so far: express, axios, fastapi, drizzle-orm, requests,
    lodash, zod

How to use it

ChatGPT Custom Instructions:
Before suggesting any npm/pip/cargo install, call:
GET https://depscope.dev/api/check/{ecosystem}/{package}

If deprecated=true or risk_level=critical, propose the alternatives
field instead. Cite the health score in your answer.

Custom GPT: ChatGPT - DepScope

Claude Code / Cursor / Windsurf / Claude Desktop (MCP server, one-liner):
claude mcp add depscope – npx -y depscope-mcp
Full integration examples: DepScope — Package Intelligence for AI Agents


What I’d ask the community

If you’ve hit cases of ChatGPT suggesting:

  • a deprecated package (“Yes, use request for HTTP…”)
  • a hallucinated package that doesn’t exist on npm/PyPI
  • a vulnerable library without mentioning the known CVE

Drop the example in the thread. I’m collecting real cases for a follow-up post
on patterns — specifically which naming conventions trigger hallucination most
often. It’s the most interesting signal emerging right now and I can only see it
partially from server-side.

Happy to answer technical questions on the API/MCP design or the data pipeline —
but for anything longer-form, email works better for me than threads.

Vincenzo