Fact-Check the Reel First

Instagram told me I needed Context7. Several Reels, same pitch: Claude Code isn’t set up right without it. I don’t act on Reels in the moment. I go in looking for something specific, save what fits to a collection, and get out. Later I work through the collection and fact-check each one with Claude.

Context7 is an MCP server from Upstash that feeds an AI agent current library docs, so it stops writing code against last year’s API. My first instinct was to clone the repo and read the code. That instinct was aimed at the wrong thing.

The Insight

The code is fine. The server is small, open source, and has two tools: one finds a library, one fetches its docs. Both only read.

The risk sits behind it. Those docs come from Upstash’s own backend, which isn’t public. And anyone can submit a library to Context7, not just the people who maintain it. So the text that lands in my agent’s context was written by whoever submitted it, then filtered by a system I can’t see.

That matters because an agent can’t reliably tell documentation from instructions. A line in a setup guide that says to read a config file and send it somewhere looks like any other step. I can audit code once. I can’t audit content that changes every time the agent asks for it.

The Fix

I skipped Context7. What it sells is current docs, and I can get those without a middleman. Most days I tell Claude Code to check the official docs page before it writes anything. “Check the current Astro docs first” does the job. Plenty of libraries now publish an llms.txt file, a plain map of their docs written for AI, so I point the agent there. For the libraries I use every day, I save the docs into the project once. Then the text is mine.

Context7 isn’t the only server worth that question. I’d just installed the Chrome DevTools MCP, and the same test applies to it and every one after it: if something tricks it, what can it reach? So I shrink that first.

The first thing it shouldn’t reach is my keys. A .env file is plain text, and anything running as me can read it. My scripts don’t need the file, though. They need environment variables, and a .env is the lazy way to set them. A password manager’s CLI can inject them when the script runs, so nothing sits on disk. In the cloud, keys live in the platform’s own store: GitHub secrets for Actions, Netlify env vars for builds. Where a tool insists on a .env, it stays out of git, and a deny rule in ~/.claude/settings.json blocks Claude from reading it: "deny": ["Read(./.env)", "Read(./.env.*)"].

The rest is habit. Approval prompts stay on for shell commands and web requests. Servers install per project, not for everything. Install lines come from the vendor’s own GitHub or docs, never a Reel, and the npm publisher has to match the vendor. I pin a version instead of @latest, so an update can’t change things quietly.

The Hard Truth

None of this is a wall. Claude Code’s own issue tracker has reports of .env deny rules being ignored in some versions. A rule is one layer. The setup that holds up is the one where a leaked file has nothing worth taking.

Reading the code felt like diligence. It was the easy part. The real question with any tool that hands an agent outside text is who wrote that text, and whether I can see it. For Context7 I couldn’t, so I passed.

Sources

• Context7's MCP server has two tools, resolve-library-id and query-docs — Upstash on GitHub
• Context7's indexing and retrieval backend is proprietary and has no self-hosted option — GitHub
• Anyone can add a public library to Context7 without owning it — Context7 docs
• llms.txt was proposed by Jeremy Howard in September 2024 as a docs map for AI — Search Engine Land
• Users have reported Claude Code ignoring .env deny rules in some versions — GitHub, GitHub