Skip to main content

Step 0 — On-demand loading of MCP

The first thing /debug does when it launches is not investigating the bug but preparing the tools. In "Step 0" of SKILL.md, it loads the tools of the Model Context Protocol (MCP).

MCP is not available from the start (so we load it)​

MCP is a mechanism for calling, as tools, features outside the model — such as fetching official documentation or doing structured reasoning. While convenient, keeping all MCP tools active at all times would crowd the context with tool definitions alone.

So in this environment, MCP tools are deliberately kept in an unloaded state (deferred). Just before use, only the schema of the needed tool is loaded with ToolSearch. The deferred state and ToolSearch are built-in Claude Code mechanisms (📦), while the procedure for "what to always load in Step 0" is the author's design (🔧) written in /debug's SKILL.md.

Loading the needed MCP each time
ToolSearch(query="select:mcp__sequential-thinking__sequentialthinking", max_results=1)
ToolSearch(query="select:mcp__context7__resolve-library-id,mcp__context7__query-docs", max_results=1)

Rather than "loading everything up front," you "take it out when you use it." This is MCP's on-demand loading. The details of the mechanism are covered in The two-stage loading of MCP.

Why sequential-thinking is "mandatory"​

In /debug's Step 0, loading sequential-thinking is required. This ties directly to the nature of debugging: "form multiple hypotheses and verify them in turn."

SKILL.md Step 0 (excerpt)
- sequential-thinking: mandatory. Structures the verification process for
    multiple hypotheses. Makes corrections / branches / backtracking explicit
    at each step.
  - Without MCP: you fixate on one hypothesis and waste time /
    you miss the true cause and only erase the symptom (symptomatic treatment)

sequential-thinking is an MCP for advancing thought in stages: "hypothesis → verification → branch → correction." For today's fetchUser bug, you would structure it like this.

  • Hypothesis H1: when the array is empty, array[0] returns undefined (a logic error)
  • Hypothesis H2: it references the return value of an async operation without awaiting it (a concurrency error)
  • Hypothesis H3: the type definition promises User, but the actual value is User | undefined (a type error)

If you do not decide in advance to "verify these one at a time," you jump at the first thing that comes to mind and fix the wrong place. By making MCP mandatory, we structurally avoid that failure pattern.

context7 is for "when the library is suspect"

The other MCP, context7, fetches the official documentation of libraries and frameworks. In /debug, you use it "when the error is suspected to originate in a library." Rather than judging by an old API spec you remember, you confirm the correct usage of the target version and any known defects from primary sources. For a bug in your own logic, like today's, there are times it has no role to play.

Consistency with the harness as a whole​

This stance of "do not judge from memory; verify first" is not unique to /debug. A standard called rules/fact-check.md is in effect across the whole (an Inferential Guide, in the terms of Guides and Sensors). The policy is to make MCP the first choice for things like library specs and AWS behavior. The skill's Step 0 is that standard distilled into a concrete procedure.

Summary of this chapter

The key points are as follows.

  • MCP is not kept always on; its schema is loaded with ToolSearch just before use (on-demand)
  • /debug force-loads sequential-thinking to build a structure of verifying multiple hypotheses "one at a time"
  • The stance of "do not assert from memory; verify" is continuous with the standard rules/fact-check.md imposes across the whole

Next, in The rules and hooks that act during investigation and fixing, we look at what interrupts while you read and write files.