Web Search & Fetch

A model's training data has a cutoff. Libraries release new versions, APIs change their shape, documentation gets rewritten — and writing code against a library as it existed at training time instead of as it exists today is a quiet, common source of subtly wrong code. Web search and fetch exist to close that gap when it matters.

Two distinct tools

Search runs a query and returns results — useful when you know roughly what you're looking for but not the exact source ("what changed in this framework's latest major version," "how does this error get resolved").

Fetch retrieves the content of a specific, known URL — useful when you already have the right page (a documentation link, an issue tracker entry, a changelog) and need its actual content rather than a search result snippet about it.

When this is worth reaching for

• Fast-moving libraries and frameworks, where the API surface at training time and the API surface today may have diverged in ways that produce code that looks right and isn't.
• Verifying an error message or stack trace against current documentation or issue trackers, rather than pattern-matching against a vaguely similar error from memory.
• Checking a specific claim before it goes into code or a written explanation — a deprecation notice, a security advisory, a version-specific behavior change.

What it can't do

It only reaches the public web. It has no access to private documentation, internal wikis, or systems behind authentication it doesn't have credentials for — for those, the MCP topic covers how to connect Claude Code to systems like that deliberately, with you controlling exactly what it can reach and what credentials it uses.

A practical habit

When something feels like it depends on details that could plausibly have changed since training — a specific API signature, a current best practice, a tool's current default behavior — checking first is cheap compared to writing code against an assumption that turns out to be stale. This is a good instinct to encourage explicitly in your project memory if your project depends on libraries that change quickly.

Next: subagents, for isolating a chunk of work in its own context.