AI coding agents do not know which version of a library you have installed. They know the library in a general sense — the API as it appeared across their training data, which skews toward older, more documented releases. If you are running Next.js 15 and the model learned mostly from Next.js 14 examples, it writes Next.js 14 code. The output compiles. The behavior is wrong.
Context7 solves this at the lookup level. When you include a version in your query — /vercel/next.js@15, /prisma/prisma@6, /remix-run/remix@2 — it returns documentation scoped to that specific release. The agent answers from the version you are actually running, not the version that happened to be most common in training data.
Training data skews toward older versions. The most-documented version of any library is rarely the current one — it is the version that had the most tutorials, Stack Overflow answers, and blog posts written about it, which takes time to accumulate. A model trained today still knows React 17 and Next.js 13 better than it knows their latest releases.
This is not a fixable model problem. The agent cannot see your package.json. It does not know you are on Prisma 6, not Prisma 5. Without an explicit signal, it will write code that is plausibly correct against the version it knows best — which may not be the version you are running.
The solution is to include version context in the lookup. Context7 makes that explicit and automatic: resolve the library, specify the version, get documentation from that release.
The syntax is /username/library@version. For example:
/vercel/next.js@15/prisma/prisma@6/remix-run/remix@2You can include this format directly in your prompt when asking the agent to use Context7, or set it as the default library reference in your project configuration. Most agents will pass it through to the Context7 MCP tool automatically.
To find the right version tag, check your package.json or lock file. Context7 indexes tagged releases from the library's repository — if the tag exists in the source, it is likely indexed.
App Router migrations and server component patterns
The App Router introduced in Next.js 13 and refined through 14 and 15 changed routing, data fetching, and caching conventions significantly. An agent writing App Router code from Next.js 13 patterns on a Next.js 15 project produces code that is structurally wrong, not just stylistically different.
Schema definitions, client initialization, and query APIs
Prisma has made breaking changes to its client initialization, relation syntax, and migration API across major versions. Generated code from the wrong version will fail at the type level or at runtime in ways that are slow to diagnose.
Routing conventions, loader patterns, and form handling
Remix v1 and v2 use different routing file conventions and different approaches to form actions and data loading. Code written for v1 patterns does not work in a v2 project, and the error messages are not always obvious about the cause.
Concurrent features, hooks, and server component patterns
React 18 and 19 introduced concurrent rendering, server components, and new hooks. Agents familiar with React 17 patterns may write code that works but misses newer primitives or relies on patterns that are now discouraged.
Client initialization, service calls, and configuration
AWS, GCP, and Azure SDKs rename client constructors, change config interfaces, and reorganize service namespaces between major versions. An outdated initialization pattern often compiles but connects to the wrong endpoint or uses deprecated defaults.
Without a version, Context7 returns documentation from the latest indexed release of the library. For stable, slow-moving libraries this is fine — the API is likely the same as what you are running.
For fast-moving frameworks mid-migration, it is a gamble. If your project is pinned to an older major version and the latest release made breaking changes, the agent will write code for the wrong API.
The safe habit is to include the version whenever the library has had at least one major release that changed its primary API. If you are not sure, check — a few seconds in your package.json is cheaper than debugging version-mismatch errors after the fact.
Use the format /username/library@version in your prompt or API call. For example, /vercel/next.js@15 or /prisma/prisma@6. Context7 will return documentation scoped to that release rather than the latest indexed version.
Context7 uses the same version tags as the library's source repository. Typically this is the major version (e.g., @15, @6) or a full semver tag (e.g., @15.1.0). Check the library's GitHub releases page or your package.json to find the right tag.
Context7 indexes tagged releases from source repositories. Most libraries with active release tagging are covered for recent major versions. Older versions and libraries without release tags may have limited or no versioned history.
Not necessarily. For stable libraries with infrequent breaking changes, the latest indexed version is usually close enough. Pin a version when you know there have been breaking changes between releases, when your project is locked to an older major, or when the framework has a history of significant API shifts.
Check your package.json for the installed version range, or your lock file (package-lock.json, yarn.lock, pnpm-lock.yaml) for the exact resolved version. Use the major version number when specifying a Context7 lookup — for example, if you have next@15.1.2, use /vercel/next.js@15.