Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

sequential-thinking: readOnlyHint and idempotentHint annotations are inaccurate (server is stateful, non-idempotent)

Open Beginner friendly
  • Is something wrong?
#4,721 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api

Research direction

Start in src/sequentialthinking/index.ts at the tool annotations, then read the state fields and mutations cited in src/sequentialthinking/lib.ts. Confirm the metadata matches the server's stateful behavior and that the read-only and idempotency claims are accurate when the change is complete.

Written by the indexing model from the issue text.

Description

Summary

The sequentialthinking tool annotations readOnlyHint: true and idempotentHint: true are inaccurate. The server is stateful and non-idempotent — it maintains per-session thoughtHistory and branches instance state that persists across calls and changes on every invocation.

These annotations were added per #3403's suggestion, but the suggested values were not verified against the server's actual stateful behavior.

Evidence (BETS cycle, 2026-08-30)

Ran a governed Benchmarking/Evaluation/Testing/Standards (BETS) cycle against @modelcontextprotocol/server-sequential-thinking (published npm version, via npx -y). 11 test cases across 4 lanes.

readOnlyHint: true is misleading

The SequentialThinkingServer class (confirmed in src/sequentialthinking/lib.ts on main) holds instance state:

  • private thoughtHistory: ThoughtData[] = [] (line 23-24)
  • private branches: Record<string, ThoughtData[]> = {} (line 25-26)

Each processThought call mutates this state:

  • this.thoughtHistory.push(input) (line 101) — appends to history on every call
  • this.branches[input.branchId].push(input) (line 111-112) — appends to branch when branchFromThought + branchId provided

Observed across 11 calls in one session: thoughtHistoryLength incremented linearly (1, 2, 3, ... 11). The server is not read-only — it accumulates session state with each invocation.

idempotentHint: true is false

A tool is idempotent if repeated calls with the same arguments produce the same result. Calling sequentialthinking twice with identical arguments produces different thoughtHistoryLength values (N, then N+1) and potentially different branches contents. The tool is non-idempotent by definition.

Suggested fix

annotations: {
  readOnlyHint: false,    // server maintains thoughtHistory and branches state
  destructiveHint: false, // accurate — no external side effects
  idempotentHint: false,  // repeated calls produce different history lengths
  openWorldHint: false,   // accurate — operates on internal reasoning state
},

Impact

Clients relying on readOnlyHint: true for safety assumptions (e.g., "safe to call in parallel", "no state side effects to roll back") will miss the session-state accumulation. Clients relying on idempotentHint: true for caching/retry (e.g., "safe to retry without checking result") will misbehave — a retried call produces a different history length and may create a duplicate branch entry.

Source confirmed on main

src/sequentialthinking/index.ts lines 201-209 (current main as of 2026-08-30):

annotations: {
  readOnlyHint: true,     // ← should be false
  destructiveHint: false,
  idempotentHint: true,   // ← should be false
  openWorldHint: false,
},

src/sequentialthinking/lib.ts lines 23-26, 101, 111-112 confirm the stateful behavior.

Context

  • BETS receipt: agents/_state/bets/20260830T092705Z_sequential-thinking.json (HUMMBL internal, available on request)
  • Related: #3403 (added these annotations without verification — the suggestion was accepted as-is)
  • Discovered during a governed BETS cycle on the MCP fleet, not via automated scanner

Happy to open a PR if that's preferred.

Dominant language
TypeScript
Stars
90.6k
Forks
11.7k
Avg merge
7h 57m
Merged PRs (30d)
20

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/servers

All issues in modelcontextprotocol/servers

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.