Claude Code has first-class MCP support baked into the CLI itself, so there's no separate config file format to learn beyond the standard .mcp.json shape, and the VS Code extension shares the same underlying agent — connect the server once and both surfaces see it. This topic covers the install, then two real patterns: decomposing a genuinely large refactor, and using revision/branching to recover from a wrong turn mid-task, plus the prompting habits that actually get Claude to invoke the tool instead of reasoning inline.
Installing and Connecting Sequential Thinking MCP to Claude Code
The fastest path is the built-in claude mcp add command, run from your project root:
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking
By default this writes to your local scope, meaning it's private to you and this one project (stored in ~/.claude.json under the project's key). Two other scopes matter in team settings:
claude mcp add sequential-thinking --scope project -- npx -y @modelcontextprotocol/server-sequential-thinking
claude mcp add sequential-thinking --scope user -- npx -y @modelcontextprotocol/server-sequential-thinking
If you go with project scope, the committed .mcp.json looks like this:
{
"mcpServers": {
"sequential-thinking": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
}
}
}
Confirm the connection before relying on it:
claude mcp list
sequential-thinking: npx -y @modelcontextprotocol/server-sequential-thinking - ✓ Connected
The first time Claude actually invokes sequentialthinking in a session, Claude Code will prompt for tool-use permission unless you've pre-approved it. For a tool this low-risk (no filesystem or network access), it's reasonable to allowlist it in .claude/settings.json:
{
"permissions": {
"allow": [
"mcp__sequential-thinking__sequentialthinking"
]
}
}
The VS Code extension reads the exact same .mcp.json and ~/.claude.json — there's nothing extra to configure there. Open the Claude Code panel inside VS Code, and any server visible to claude mcp list in the integrated terminal is visible to the panel too. The one practical difference is where you watch the thought log: in the CLI it streams to your terminal (unless DISABLE_THOUGHT_LOGGING=true is set); in the VS Code panel, each sequentialthinking call renders as a collapsible tool-use block you can expand per step, which is honestly the nicer way to review a long chain after the fact.
Tips
- Use--scope projectfor anything you want new team members to get automatically ongit cloneplusclaude mcp addrequires no re-running — it's already in.mcp.json.
- Runclaude mcp listafter any config change — a silently disconnected server (wrong npx path, network-blocked registry) fails quietly and Claude just stops using the tool without telling you why.
- In VS Code, collapse tool-use blocks you're not actively reviewing — a 10-step chain with every JSON payload expanded makes the panel unreadable.
Decomposing a Large Refactor into Verifiable Reasoning Steps
The pattern that works well: ask Claude to use sequential thinking explicitly for the planning phase, then switch to normal tool calls (Read, Edit, Bash) for execution once the plan is set. Trying to make it think-and-edit interleaved on every step usually produces a worse plan, because the model starts optimizing for "what's the next edit" instead of "is this decomposition actually sound."
Concrete example: extracting a shared NotificationService out of three separate Express route handlers in a monorepo, each of which currently sends emails with slightly different (and duplicated) SMTP logic.
Prompt: I need to extract a shared NotificationService from the email-sending
code duplicated in src/routes/orders.ts, src/routes/signups.ts, and
src/routes/password-reset.ts. Use sequential thinking to plan this out before
touching any files — I want to see the decomposition before you start editing.
A representative chain Claude produces:
{
"thought": "First, read all three files to catalog exactly what SMTP config, templating, and error handling each one duplicates versus what's actually route-specific (recipient, subject, body content).",
"thoughtNumber": 1,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "orders.ts and signups.ts both use nodemailer directly with inline retry logic (3 attempts, 500ms backoff). password-reset.ts uses a queue (Bull) instead — that's a real behavioral difference, not just duplication, so the shared service needs to support both sync-send and queued-send.",
"thoughtNumber": 2,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "Design: NotificationService.send(payload, { mode: 'sync' | 'queued' }). Sync mode keeps the existing retry logic. Queued mode delegates to the existing Bull queue instance rather than reimplementing it — reuse, don't rebuild.",
"thoughtNumber": 3,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "Order of edits matters for reviewability: create src/services/NotificationService.ts and its tests first, get that green in isolation, then migrate orders.ts, then signups.ts, then password-reset.ts as three separate commits — never touch two route files in the same commit.",
"thoughtNumber": 4,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "Risk: password-reset.ts's queue consumer expects the job payload shape { to, resetToken }. If NotificationService changes that shape, the consumer breaks silently at runtime with no compile error since Bull jobs aren't typed end-to-end. Flag this explicitly and add a payload shape test.",
"thoughtNumber": 5,
"totalThoughts": 6,
"nextThoughtNeeded": true
}
{
"thought": "Final plan: 4 commits (service+tests, orders migration, signups migration, password-reset migration with payload shape test). Ready to execute in that order, verifying test suite green after each commit before proceeding to the next.",
"thoughtNumber": 6,
"totalThoughts": 6,
"nextThoughtNeeded": false
}
Notice thought 5 — that's the payoff. A plain "think step by step" prompt frequently glosses over the untyped queue payload risk because it reads as a minor implementation detail rather than a distinct reasoning step worth flagging. Forcing numbered, discrete thoughts made that risk visible before any code was touched, not discovered as a production incident after.
Tips
- Explicitly say "use sequential thinking to plan this before touching any files" — otherwise Claude Code often just starts editing directly on simpler-looking refactors.
- Ask for the plan to end in concrete, git-committable steps (as in thought 6) — an abstract plan that doesn't map to commits is harder to verify against as you execute.
- Re-read the chain for any thought that surfaces a cross-file coupling risk (like the Bull payload shape here) — those are exactly the things sequential decomposition is good at catching that inline reasoning skips.
Using Revision and Branching to Correct a Wrong Reasoning Path
Revision is most valuable when new information genuinely invalidates an earlier assumption — not as a formality. Here's a chain where thought 3 turns out to be wrong once thought 4 uncovers new information, and Claude explicitly revises rather than silently changing direction:
{
"thought": "Plan: migrate the rate limiter from in-memory counters to Redis, keyed per user ID, with a 60-second sliding window.",
"thoughtNumber": 3,
"totalThoughts": 5,
"nextThoughtNeeded": true
}
{
"thought": "Checked infra/redis.yaml — this app's Redis instance is shared across 4 services with a 512MB memory cap and no eviction policy set beyond noeviction. A per-user sliding window key for every active user will grow unbounded and risk OOM-killing writes for the other 3 services sharing this instance.",
"thoughtNumber": 4,
"totalThoughts": 6,
"nextThoughtNeeded": true,
"needsMoreThoughts": true
}
{
"thought": "Revising thought 3: don't use raw per-user keys with no TTL. Use Redis keys with an explicit 60-second EXPIRE set on every write, and use a fixed-window counter instead of sliding-window to cut per-user memory footprint roughly in half. This is a worse rate-limiting precision trade-off but an acceptable one given the shared-instance memory constraint.",
"thoughtNumber": 5,
"totalThoughts": 6,
"nextThoughtNeeded": true,
"isRevision": true,
"revisesThought": 3
}
The isRevision: true, revisesThought: 3 pair is what makes this auditable later — anyone reading the transcript sees exactly which assumption broke and why, instead of having to infer it from a change in tone between two paragraphs.
Branching serves a different purpose: keeping two real alternatives alive long enough to compare them, rather than committing early. Say the team is split between two approaches to that same rate limiter and you want Claude to reason through both before recommending one:
{
"thought": "Branch A — fixed-window Redis counter: simple, low memory, but allows up to 2x the limit right at window boundaries (burst at the edge of two adjacent windows).",
"thoughtNumber": 6,
"totalThoughts": 8,
"nextThoughtNeeded": true,
"branchFromThought": 5,
"branchId": "fixed-window"
}
{
"thought": "Branch B — token bucket with a background refill job: no boundary burst problem, smoother limiting, but needs a scheduled job (adds an operational dependency this team doesn't currently have — no cron infra in this service).",
"thoughtNumber": 6,
"totalThoughts": 8,
"nextThoughtNeeded": true,
"branchFromThought": 5,
"branchId": "token-bucket"
}
{
"thought": "Recommendation: fixed-window (branch A). The boundary-burst edge case is a known, acceptable trade-off for this use case (abuse prevention, not billing-accurate limiting), and it avoids introducing new operational infrastructure the team would need to maintain.",
"thoughtNumber": 7,
"totalThoughts": 8,
"nextThoughtNeeded": false
}
In practice, Claude Code doesn't always branch on its own initiative — it's more reliable when you explicitly ask "consider two approaches and branch on them" in the prompt, since branching is a less common pattern in its training distribution than plain linear reasoning.
Tips
- Don't expect spontaneous branching — ask for it by name in the prompt when you actually want two alternatives compared side by side.
- A revision without a stated reason is a red flag — ifisRevision: trueshows up with a thought that doesn't explain what new information triggered it, the model may be pattern-matching the field rather than genuinely reconsidering.
- Grep the thought log for"isRevision": trueafter a long session — it's a fast way to find every place the plan changed shape, which is exactly what you want to double-check before merging.
Prompting Patterns That Trigger Structured Thinking Reliably
Claude Code decides on its own, based on system-level tool-use heuristics, whether a task "deserves" the sequential thinking tool — and left to its own judgment it under-uses it, defaulting to inline reasoning for anything that doesn't look obviously multi-stage. A few prompt patterns reliably shift that behavior:
Use sequential thinking to plan out [task] before making any changes.
This has at least two viable approaches. Use sequential thinking and branch
to compare them before picking one.
Walk through this incrementally with sequential thinking, and if any earlier
assumption turns out wrong partway through, explicitly revise it rather than
just continuing.
The third pattern is the one that most reliably produces genuine isRevision usage — without that explicit permission, Claude tends to just quietly incorporate new information into later thoughts rather than flagging that an earlier one was wrong, which defeats the auditability purpose of using the tool at all.
For CI or scripted use via claude -p (print mode), the same instruction works in a one-shot prompt, though without an interactive session there's no opportunity to redirect a branch mid-chain — the whole thing runs to completion unattended:
claude -p "Use sequential thinking to diagnose why the nightly build in \
.github/workflows/ci.yml started failing, then propose a fix. Do not apply \
the fix yet, just report the plan." --output-format json
Tips
- Name the tool explicitly in the prompt ("use sequential thinking") rather than the vaguer "think step by step" — the latter often just triggers inline reasoning with no tool call at all.
- Grant explicit permission to revise ("if an earlier assumption turns out wrong, revise it") — models are otherwise reluctant to flag their own earlier steps as incorrect.
- In unattended-pmode, ask for a plan without execution first, then run a second pass to execute — reviewing the reasoning chain before it touches files is the whole point of using this tool for risky changes.
Tips
Claude Code's native claude mcp add plus its VS Code panel makes this the smoothest of the four agent integrations in this module — no bespoke config format, and a genuinely useful visual transcript of the thought chain. The value comes from being deliberate about when you invoke it (planning and diagnosis, not routine edits) and explicit about what you want from it (revision permission, branching on real alternatives).
Tips
- Use--scope projectand commit.mcp.jsonso the whole team gets sequential thinking without individual setup.
- Pre-approve the tool in.claude/settings.jsonto remove the interactive permission prompt for a tool with no filesystem or network side effects.
- Ask for plan-then-execute, not plan-and-execute-interleaved — the decomposition quality is consistently better when the model isn't context-switching between reasoning and editing on every step.