Who should use Context7
Long-tail library coverage, deep API documentation mid-task, private repo docs, and teams that want an enterprise contract.
honest comparisonContext7pricing checked 16 Aug 2026
should-i-use vs Context7: an honest comparison from the smaller one
TL;DR: Context7 is a documentation firehose: massive community-contributed coverage, real docs snippets, and 1,000 free calls a month. should-i-use is a judgment layer: 992 curated libraries with verdicts, skip-conditions, and a hard 500-token cap, using 4.8x fewer tokens per answer in our measured benchmark, free without an API key. If you want docs, use Context7. If you want a decision, use should-i-use. Many agents should use both.
The core difference
Context7 answers "how does this library work?" by returning documentation. should-i-use answers "should I install this at all?", and only then "how do I do this one thing." One treats context as a bucket to fill, the other as a budget to spend.
Token cost (measured, not claimed)
10 rounds, 20 queries per round. Libraries sampled at random from our own 992-library index in its own npm/PyPI ratio. Query text authored from each library's whatIs description only, never from our stored answer patterns (that would hand us a guaranteed hit on every row). Ours = one how_do_i call; Context7 = the two calls an agent actually makes (resolve-library-id + docs).
| should-i-use | Context7 | |
|---|---|---|
| Median tokens per answer | 238 | 1,154 |
| Mean | 253 | 1,226 |
| Rows answered (of 200) | 200 | 199 |
Ratio: 4.8x, by median, by mean, and by median of per-row ratios. Every number is a measured MCP response. Read the full method, results, and caveats.
Coverage: they win, and we say so
Context7 indexes far more projects than our 992. If you work with long-tail or internal libraries, Context7 answers where we say "not indexed." Our bet is different: cover what people actually install, refresh its signals daily, and say "I don't know" plainly for the rest. In the benchmark sample Context7 had no usable entry for exactly one library; across the whole npm+PyPI universe the gap runs the other way, and pretending otherwise would be silly.
What only Context7 has
Deep, version-specific documentation snippets pulled from source docs
A community index orders of magnitude larger than ours
Private-repo parsing (paid) and an enterprise tier (SOC-2, SSO, self-hosted)
What only should-i-use has
Opinions. A verdict, skip-conditions, and 4-axis scores with a one-line reason each. Docs tell you how; nobody's docs tell you don't.
audit_dependencies. Manifest in, REPLACE / WATCH / WORTH RECONSIDERING out. It catches crypto-js (19.3M weekly downloads, dead) and python-jose (10.6M, unmaintained).No API key, no rate limit, no server dependency. The npx package bundles the whole index; lookups never leave your machine. The hosted endpoint is free too.
A fully public index. Every guide, score, and data file is on GitHub. Context7's parsing backend is private.
Pricing
Context7 free tier: 1,000 calls/month, then 20 bonus calls/day. An active coding agent makes two calls per lookup; a busy week can exhaust the month. Pro is $10/seat/month for 5,000 calls. should-i-use is free at any volume because there is nothing to meter: the data ships in the package.
Who should use which?
Who should use should-i-use
Token-budgeted agents, dependency decisions before npm install, dependency audits of unfamiliar codebases, and anyone who wants "no" to be a possible answer.
The honest close
Use should-i-use first: it is cheap, opinionated, and fails loudly when it doesn't know. Fall back to Context7 when you need the firehose. They are complementary more than they compete, which is exactly why we benchmarked against them instead of pretending they don't exist.
Limitations (ours, so you don't find them the hard way)
Worth knowing before you rely on it:
Coverage is curated, not complete. A few hundred libraries, not every package on npm and PyPI.
audit_dependencies therefore stays quiet on anything unindexed, and a clean audit means "nothing flagged in what I know", not "your dependencies are fine".The tools are advisory unless you add the policy line. An agent calls MCP tools when it decides to, so on its own this is a strong suggestion, not an interceptor: nothing forces every
npm install through a check. To make the check near-automatic, run npx should-i-use-mcp install --with-policy inside a project: it appends a one-line dependency policy to your CLAUDE.md/AGENTS.md (creating AGENTS.md if neither exists), and agents that read project rules will then consult the index before adding any dependency.Guides are research, not test drives. Each guide is grounded in the library's documentation, release notes, changelog, and issue history on a fixed rubric, not a hands-on install of every release. The 50 most-downloaded entries are additionally install-verified in clean containers (latest run: 49/50 clean; the one timeout was sglang's CUDA wheel tree, which its own guide warns about).
Guides are point-in-time. Signals refresh daily and guides are reviewed on a pipeline, so a library that shipped a big release or found a new maintainer this week can be ahead of what the guide says. Check
docs_link when the answer looks stale.pick_library ranks on keywords, not embeddings. Plain phrasing works well; unusual or metaphorical phrasing can miss entirely. If nothing matches, it says so instead of returning a shrug, but you may need to reword.The benchmark is indicative, not definitive. 10 rounds of 20 queries on randomly sampled libraries, measured across two days. The 4.8x figure is a real measurement, not a general law. The method and every row are in bench/; rerun it yourself if the number matters to you.
Verdicts are opinions. Informed, sourced, and argued, but still one person's judgment call. Disagreeing with one is a valid bug report.
Pricing checked: August 16, 2026.