MCP On-Demand Loading: Context Myth Busted (2026)

A post on r/AI_Agents titled "Stop Building MCP for Personal Tools" argued that MCP servers waste context window by pre-loading tool definitions. The top comment corrected the misconception: Claude Code loads MCP tools on demand via the /context command, not pre-loaded into the initial context. This changes the calculus for when MCP makes sense versus when a simple script is enough.

The misconception

The original post assumed that every MCP server you configure adds its full tool schema to the system prompt on every conversation. If you had 10 MCP servers with 5 tools each, that would be 50 tool definitions consuming thousands of tokens before you type a single message. Under this assumption, MCP is wasteful for personal tools where you only use one or two tools per session.

How it actually works in Claude Code

Claude Code defers MCP tool loading. Tools are registered but their schemas are not injected into the context until they are needed. The /context command and tool search mechanism allow loading specific tools on demand. This means having 20 MCP servers configured costs zero context tokens until you actually invoke one of their tools.

When MCP makes sense

• Tools you use across multiple projects. A search MCP server works in your web app project, your data analysis repo, and your content pipeline. One configuration, every project.
• Tools with authentication complexity. An MCP server handles OAuth flows, token refresh, and credential storage once. Your scripts just call the tool.
• Tools that benefit from structured schemas. When the LLM needs to understand the tool's parameters to decide how to use it, a typed MCP schema is better than a docstring in a bash script.

When scripts are fine

• One-off tasks in a single project. A bash script that curls an API does not need MCP wrapping if you only use it here.
• Simple transformations. Piping JSON through jq is faster than building an MCP server that does the same thing.
• Tasks where the LLM does not need to understand the tool. If you are running the script manually, MCP adds no value.

Example: search MCP server vs curl script

A search tool is a good MCP candidate because you use it across projects, the LLM benefits from understanding the parameters (query, num_results, search_type, freshness), and authentication is consistent.

# As a simple script (fine for one project):
import requests, os

resp = requests.post(
    "https://api.scavio.dev/api/v1/search",
    headers={"x-api-key": os.environ["SCAVIO_API_KEY"]},
    json={"query": "MCP server best practices", "num_results": 5}
).json()
for r in resp["results"]:
    print(f"- {r['title']}: {r['url']}")

# As MCP, the LLM can dynamically choose parameters:
# - search_type: "reddit" vs "google" vs "news"
# - freshness: "day" vs "week" vs "month"
# - num_results: 3 for quick checks, 10 for deep research
# The schema tells the LLM what is possible without hardcoding.

The /reload pattern

After adding or modifying an MCP server configuration, run /reload in Claude Code to pick up the changes without restarting the session. This is important when iterating on tool schemas. Change the schema, /reload, test. No need to close and reopen the editor.

Context cost reality check

Even if tools were pre-loaded (which they are not in Claude Code), a typical MCP tool schema is 200-400 tokens. Ten tools would cost 2,000-4,000 tokens out of a 200K context window, roughly 1-2%. The context cost argument was overstated even under the wrong assumption. With on-demand loading, it is zero until use.

Decision framework

Ask two questions. First: will I use this tool in more than one project or session? If yes, MCP saves configuration repetition. Second: does the LLM need to understand the tool's parameters to use it effectively? If yes, a typed schema beats a comment in a script. If both answers are no, a script is simpler and faster to write.

The bottom line

MCP is not wasteful. On-demand loading means zero context cost for unused tools. The real decision is about reuse and schema value, not token budgets. Build MCP servers for tools you use everywhere. Use scripts for one-off tasks. Do not build MCP servers for tools you will use once and forget.