·

Sequential Thinking MCP With Gemini CLI

Set up Sequential Thinking MCP in Gemini CLI so your AI agent can break complex problems into structured, step-by-step reasoning right from your editor.

Gemini CLI, Google's open-source terminal agent, added MCP support early and uses a config shape close enough to Claude Desktop's that migrating a config between the two is mostly copy-paste. The interesting part of this integration isn't the setup — it's how Gemini's own models handle the revision and branching fields compared to Claude, since that difference actually changes how you should prompt it.

Installing and Connecting Sequential Thinking MCP to Gemini CLI

Gemini CLI reads MCP server definitions from settings.json, either per-project at .gemini/settings.json or globally at ~/.gemini/settings.json. The key is mcpServers, matching the same shape used across most of these clients:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

There's also a CLI shortcut that writes this file for you, which is worth using so you don't hand-edit JSON and typo a key:

gemini mcp add sequential-thinking npx -y @modelcontextprotocol/server-sequential-thinking

One Gemini-CLI-specific setting worth knowing about is trust. By default, Gemini CLI prompts for confirmation the first time it calls a new MCP tool in a session, same as most agents. For a side-effect-free tool like this one, it's reasonable to mark it trusted so the prompt doesn't interrupt a reasoning chain mid-flow:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
      "trust": true
    }
  }
}

Verify the server is live from inside a Gemini CLI session:

/mcp list

sequential-thinking - Ready (1 tool)
  - sequentialthinking

If it shows Disconnected and you're behind a corporate proxy, check that npx's registry lookup isn't being blocked — Gemini CLI's error surfacing for a failed stdio spawn is fairly terse (often just "server exited"), so dropping to a raw terminal and running the npx command by hand is the fastest way to see the actual underlying error.

Tips
- Use gemini mcp add over hand-editing settings.json — it validates the JSON shape for you and avoids a silent typo breaking the whole config file.
- Set trust: true only for tools with no filesystem or network side effects — sequential thinking qualifies, most other MCP servers in this course don't.
- If a connection fails, run the exact npx -y @modelcontextprotocol/server-sequential-thinking command directly in your terminal first — Gemini CLI's own error message for a failed MCP spawn is rarely specific enough to debug from alone.

Driving Multi-Step Analysis and Trade-off Evaluation in Gemini CLI

With Gemini 2.5 Pro as the backing model (the default for Gemini CLI at the time of writing), sequential thinking chains tend to be thorough on breadth — Gemini is good at enumerating options — but noticeably more eager to set nextThoughtNeeded: false early compared to Claude models working the same problem. In practice this means Gemini CLI chains often run 2-3 thoughts shorter than a Claude Code chain on an equivalent prompt, converging on an answer before fully working through second-order consequences.

The fix is prompting for depth explicitly rather than trusting the model's own totalThoughts estimate:

Use sequential thinking to evaluate whether we should add a caching layer in
front of the /api/search endpoint. Don't converge early — explicitly consider
cache invalidation, staleness tolerance, and memory cost as separate thoughts,
not folded into one summary thought.

A chain from that prompt, worth reading for both what it gets right and where it needs the nudge:

{
  "thought": "The /api/search endpoint hits Elasticsearch directly on every request, with p50 latency of 180ms and p99 of 1.2s under current load — caching could help but only if query patterns repeat meaningfully.",
  "thoughtNumber": 1,
  "totalThoughts": 4,
  "nextThoughtNeeded": true
}

{
  "thought": "Checked query logs — top 100 distinct queries account for roughly 40% of total search volume, which is a strong repeat pattern. A cache would meaningfully reduce Elasticsearch load.",
  "thoughtNumber": 2,
  "totalThoughts": 4,
  "nextThoughtNeeded": true
}

Without the explicit "don't converge early" instruction, this is where Gemini frequently jumps straight to a recommendation in thought 3 and stops at totalThoughts: 3, skipping invalidation strategy and memory cost entirely. With the instruction in place, it continues:

{
  "thought": "Invalidation: search results depend on inventory availability, which changes frequently. A naive TTL cache of 5 minutes risks showing out-of-stock items as available. Need either a short TTL (30-60s, limiting cache benefit) or event-based invalidation tied to inventory updates.",
  "thoughtNumber": 3,
  "totalThoughts": 5,
  "nextThoughtNeeded": true,
  "needsMoreThoughts": true
}

{
  "thought": "Memory cost: caching the top 100 queries with full result payloads (avg 15KB per response) is only 1.5MB — trivially cheap. Recommendation: short TTL cache (45s) on top-N queries only, not a general-purpose cache for the full query space, given the staleness constraint from inventory data.",
  "thoughtNumber": 4,
  "totalThoughts": 5,
  "nextThoughtNeeded": false
}

Tips
- Explicitly instruct "don't converge early" or "cover X, Y, Z as separate thoughts" when using Gemini CLI — its default depth is shallower than Claude's on equivalent prompts.
- Watch for totalThoughts estimates that shrink rather than grow across a chain — that's the tell that the model is winding down prematurely.
- Gemini's breadth (enumerating more candidate factors per thought) is a genuine strength — lean into it for option-generation tasks even if you need to push for depth on the follow-through.

Practical Example: Choosing an Architecture with Explicit Reasoning Steps

A architecture-choice prompt tends to showcase Gemini CLI's enumeration strength well — deciding between REST and GraphQL for a new BFF (backend-for-frontend) layer serving three different mobile clients with different data needs.

Use sequential thinking to decide between REST and GraphQL for our new BFF
layer. We have 3 mobile clients (iOS, Android, and a lightweight partner SDK)
with meaningfully different data needs per screen. Branch on both options
before recommending one.

{
  "thought": "Core tension: iOS and Android need rich, deeply nested data per screen (product details, reviews, recommendations in one call), while the partner SDK needs a minimal flat payload for a single embedded widget. A one-size response shape serves neither well.",
  "thoughtNumber": 1,
  "totalThoughts": 6,
  "nextThoughtNeeded": true
}

{
  "thought": "Branch A - REST: would need either heavily over-fetching endpoints for the rich clients or a proliferation of narrow endpoints per screen. Versioning is straightforward and well-understood, and the team already has REST tooling (OpenAPI codegen) in place.",
  "thoughtNumber": 2,
  "totalThoughts": 6,
  "nextThoughtNeeded": true,
  "branchFromThought": 1,
  "branchId": "rest"
}

{
  "thought": "Branch B - GraphQL: each client requests exactly the fields it needs per screen, solving the over-fetch/under-fetch tension directly. Cost: the team has zero production GraphQL experience, and query complexity limiting (to stop the partner SDK's client from accidentally requesting an expensive nested query) needs to be built, not assumed.",
  "thoughtNumber": 3,
  "totalThoughts": 6,
  "nextThoughtNeeded": true,
  "branchFromThought": 1,
  "branchId": "graphql"
}

{
  "thought": "Team experience is a real cost, not just a preference — a GraphQL rollout with no prior production experience commonly costs 2-4 extra weeks in resolver design and N+1 query pitfalls (needing DataLoader-style batching) before it's genuinely stable.",
  "thoughtNumber": 4,
  "totalThoughts": 6,
  "nextThoughtNeeded": true
}

{
  "thought": "Recommendation: GraphQL, because the underlying data-shape mismatch across 3 clients is a structural problem REST doesn't solve well, and it will resurface repeatedly as more clients are added. The ramp-up cost is real but one-time; the REST over-fetch problem is recurring and gets worse with each new client.",
  "thoughtNumber": 5,
  "totalThoughts": 6,
  "nextThoughtNeeded": false
}

That's a genuinely useful trade-off writeup — the honest inclusion of "the team has zero production GraphQL experience" as a real cost, not a footnote, is the kind of thing that makes a recommendation trustworthy rather than a one-sided pitch.

Tips
- Ask explicitly for both branches to include team/organizational cost, not just technical merits — architecture decisions that ignore team readiness are incomplete regardless of which model produces them.
- Request a recommendation, not just two branches left unresolved — branching without a final synthesis step just leaves you with two essays instead of a decision.
- Save chains like this directly into your architecture decision record (ADR) — the branch structure maps cleanly onto an ADR's "options considered" section.

Comparing Reasoning Quality Between Gemini CLI and Claude Code

Run head-to-head on the same prompts, a few consistent differences show up. Gemini 2.5 Pro tends to generate broader initial option sets — more candidate causes in a diagnosis, more architectural options considered — but converges to a final answer with fewer total thoughts and uses isRevision less often, more frequently absorbing a correction into the next thought's prose instead of flagging it structurally. Claude models (3.7 Sonnet and the 4.x family) tend toward narrower initial framing but longer chains with more explicit self-correction, and use branchFromThought/branchId more consistently when asked, without needing the same explicit anti-convergence nudging Gemini benefits from.

Neither is strictly better — for fast option enumeration where you'll do the final judgment call yourself, Gemini CLI's output is often quicker to scan. For chains where the auditability of the reasoning trail matters (post-incident reviews, migration plans someone else will sign off on), Claude Code's more disciplined use of isRevision and branchId produces a more useful paper trail with less prompting effort on your part.

Cost and latency also diverge in practice: Gemini CLI's shorter convergent chains are cheaper and faster per session simply because there are fewer round trips, which is a real advantage if you're running this at volume and don't need the deeper audit trail every time.

Tips
- Default to Gemini CLI for quick option enumeration where you'll make the final call yourself and don't need a detailed revision trail.
- Default to Claude Code when the reasoning chain itself is a deliverable someone else will review — incident postmortems, migration sign-offs, architecture decision records.
- If you standardize on Gemini CLI for cost reasons but still need auditability, invest in the explicit "don't converge early, flag any correction as a revision" prompt pattern — it closes most of the gap.

Tips

Gemini CLI's Sequential Thinking MCP setup is close to identical to every other client here, but the model behind it changes what you get out of the tool more than the config does. Set trust: true for smooth sessions, but budget extra prompting effort into asking for depth and explicit revision-flagging if the reasoning trail itself needs to hold up to later scrutiny.

Tips
- Test both gemini mcp add and hand-editing settings.json once each so you know how to recover if the CLI shortcut ever produces an unexpected key name in a future version.
- Keep an eye on totalThoughts trending down mid-chain — it's the single most reliable early signal of premature convergence with Gemini models.
- Reach for Claude Code instead when the chain needs to double as a written record other engineers will read and trust later.

Next Sequential Thinking MCP With Cursor