mcp-sequentialthinking-tools

What it does

mcp-sequentialthinking-tools gives an assistant a place to write down its reasoning one numbered step at a time, with room to revise an earlier step, branch off from one, and raise its estimate of how many steps it needs. Steps are grouped by a session id, so separate tasks keep separate histories, and the assistant can read a history back or clear it partway through a long run.

Its extra over the reference Sequential Thinking server it was adapted from is a check on tool plans. When the caller sends a list of tools it has available together with the tools the model plans to use, the server confirms every planned name is in that list; if one is missing it returns an error and does not record the step. It does not find your other MCP tools or choose tools itself, whatever the package description suggests: the model writes the recommendations and the server only validates and stores them.

Text in thoughts, rationales and tool descriptions is scanned for prompt-injection patterns and redacted before it is stored or returned, with a security_warnings field naming the fields that matched. It also ships one prompt, sequential-thinking-guidance, that tells the model to treat the server as a scratchpad rather than a reasoning engine.

History lives only in the server process's memory (a Map in src/thinking.ts): nothing is written to disk, so every session is lost when the client restarts the server, and once a session passes MAX_HISTORY_SIZE (1000 by default) its oldest steps are dropped. A value for MAX_HISTORY_SIZE that is not a positive whole number falls back to 1000 (src/mcp-server.ts).

What it needs

Node.js 22 or later (the package's engines field), run through npx. No account, API key or network service is needed; it is a local stdio server for any MCP client.

Limits

Keeps history in memory only, so it is gone when the server restarts; each session holds at most MAX_HISTORY_SIZE steps (default 1000), oldest dropped first. get_thinking_history returns 50 steps by default, up to 500 with limit. It cannot see the client's real tool list: tool-plan checks only work when the caller passes available_tools. Its makers say the injection filtering is defensive and not a guarantee, and that it adds overhead on simple requests.

Who it suits

Suits people who want an assistant to plan long, multi-step work out loud, keep separate plans per task, and catch plans that name tools it does not have. It touches nothing outside its own memory, so it is low-stakes to add. If you only want plain numbered thinking without sessions or tool-plan checks, the reference Sequential Thinking server it was adapted from, which we also list (Docker image mcp/sequentialthinking), covers that. It is not a fit if you need reasoning kept across restarts, since nothing is saved to disk.