mcp-sequentialthinking-tools: a scratchpad MCP server that validates tool-plan names

The problem is unrecorded tool plans, not tool selection

An agent that decides to read three files and then run a check usually leaves no trace of that decision. The plan exists inside the model's context window and disappears when the turn ends. mcp-sequentialthinking-tools exists to give that plan a place to live: each call to the sequentialthinking_tools tool stores one thought under a session_id, with a thought_number and an estimate of total_thoughts that the server raises automatically if it is lower than the current step number. The README's stated use cases are narrow and concrete. Breaking a messy problem into steps, revising or branching a plan, keeping a small reasoning history by session, validating tool-plan names against a supplied tool list, and clearing or inspecting history during a long agent run. The README also says plainly not to use it for trivial requests because it adds overhead. That is an unusual admission in an MCP server README and it sets the boundary early. The audience is people building or debugging agents who want the reasoning step to be an inspectable record rather than an implicit side effect of a prompt.

What the server does not do, according to its own README

The name invites a wrong assumption. The project is adapted from the MCP Sequential Thinking Server, and the repository description frames it as guidance for tool usage. The README contradicts the broader reading in its first paragraph: the server does not discover your other MCP tools and does not choose tools for the model. If you pass available_tools and recommended_tools, the server validates that the recommended names exist and stores the step. That is the whole of the tool-related behaviour. There is no registry scan, no capability query against other servers, no ranking. The model authors the recommendation; the server checks the name against a list the caller provided and either stores the record or refuses. Anyone evaluating this as a router will be disappointed, and the README is explicit enough that the disappointment is avoidable.

How one thought is recorded, validated and rejected

The sequentialthinking_tools tool takes four required parameters: thought, thought_number, total_thoughts and next_thought_needed. Everything else is optional. session_id buckets the history and defaults to the string default. is_revision with revises_thought marks a step as a correction of an earlier one. branch_from_thought with branch_id starts a separate line of reasoning from a given step, and get_thinking_history can filter by branch_id. available_tools accepts either an array of tool names or objects with name and description. recommended_tools carries model-authored entries with tool_name, confidence, rationale and priority. The validation rule is the interesting part: if recommended_tools contains a name not present in available_tools, the call returns isError: true and does not store the thought. The rejection is atomic. You do not get a stored step with a warning attached; you get nothing, and the model has to correct the name and resubmit. The README's example passes available_tools as ["read", "bash"] and recommends read with confidence 0.9 and priority 1. That example is the clearest statement of the intended contract: the caller supplies the universe of names, the model proposes within it, the server enforces membership.

Redaction is a filter, and the README says so

Thought text, tool descriptions, rationales and remaining-step text are treated as untrusted input. Text resembling a prompt injection is scanned and redacted before it is stored or returned in history, and any call that triggered redactions carries a security_warnings field naming the fields that matched. The README then draws its own limit: this is defensive filtering, not a guarantee that arbitrary adversarial text is safe. It also tells you not to put secrets in thoughts or tool descriptions. Treat that instruction literally. The server stores what you send it, minus whatever the scan catches, and history is retrievable per session. If your agent's reasoning steps quote file contents or environment values, those strings are now part of a record that get_thinking_history will hand back. The redaction layer is not a data-loss-prevention system and the README does not present it as one.

Running it: npx, one config block, one environment variable

The README gives a Claude Desktop style configuration block. The server entry is named mcp-sequentialthinking-tools, the command is npx, the args are -y and mcp-sequentialthinking-tools, and the env block sets MAX_HISTORY_SIZE to 1000 in the example. MAX_HISTORY_SIZE is per session and also defaults to 1000, so the example value is the default made explicit rather than a tuned number. The server uses tmcp and ships a small stdio transport that accepts both standard Content-Length framed MCP messages and newline-delimited JSON used by older tmcp tooling. That dual acceptance matters if you are running an older client, because the transport will not be the reason a connection fails. For local development the README lists pnpm install, pnpm test, pnpm build and pnpm check, with vite-plus handling build, test, format and lint orchestration. Publishing goes through pnpm changeset, pnpm changeset version and pnpm release. There is a companion prompt named sequential-thinking-guidance whose stated job is to tell the model to use the server honestly, as a scratchpad and validator rather than an external reasoning engine. If you install the server and skip the prompt, the model may treat it as something it is not.

History retrieval, clearing, and the limits that come with them

get_thinking_history returns stored thoughts for a session. It takes session_id (default default), an optional branch_id filter, and a limit that defaults to 50 and caps at 500. clear_thinking_history clears one session or every session, using session_id or all_sessions. The cap of 500 per retrieval is worth noting when MAX_HISTORY_SIZE is set to 1000: a single call cannot page out the full bucket, so a long session needs either multiple calls or a lower limit with deliberate paging on your side. The README does not describe pagination, cursors or ordering, so the exact behaviour of repeated calls against the same session is not something the supplied material establishes. The clearing tool is the one to be careful with. Passing all_sessions wipes every bucket, and because history is the product here, that is a destructive operation with no described undo. In a long agent run, calling clear_thinking_history on the wrong session silently removes the record you were about to inspect.

Where it is the wrong tool, and what to compare it against

Two cases stand out. The first is trivial work: the README itself says the server adds overhead and should not be used for trivial requests, so wrapping every short interaction in a recorded thought sequence costs calls and context for no inspection value. The second is tool routing. If what you need is a component that knows which MCP tools exist and picks between them, this server will not do it; it validates names against a list you assembled by hand. For the routing case, the natural comparison is a server that exposes the tool catalogue itself, such as an MCP gateway or proxy that aggregates downstream servers and presents their tools to the client. That approach differs in mechanism, not just in scope. A gateway enumerates tools by connecting to the servers it fronts, so the model sees real names and real schemas without a caller-maintained array, and selection happens against that live catalogue. mcp-sequentialthinking-tools inverts the direction: the caller declares available_tools, the model recommends within that declaration, and the server checks membership. The trade-off is control versus reach. The declared-list approach is deterministic and cheap to validate, and it fails closed when the model invents a name. A gateway reaches tools you did not enumerate, but it introduces a process that must know about every downstream server and can present tools that are not appropriate for the current step. Neither is a superset of the other.

Maintenance surface and licence

The project is MIT licensed, with the LICENSE file in the repository, and the README points to it. MIT is permissive: it allows use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice, and if you are redistributing the server inside a product you should read the LICENSE file yourself rather than rely on this summary. On maintenance, the observable facts are thin. The repository is not archived, the default branch is main, the most recent push recorded is 2026-09-10, and the only release listed is v0.1.0 from 2026-08-25. A 0.1.0 version number is the useful signal here: the README describes the behaviour of a first release, and the parameter set, the validation rule and the security_warnings field are all part of that initial surface. Version 0.1.0 also means the parameter names and the error contract are the things most likely to move. If you build against this, pin the version in your MCP client configuration rather than relying on npx to resolve the latest, because the args array in the README uses -y and will fetch whatever the registry currently serves.

Editorial conclusion

Adopt it if you want a per-session reasoning log with branch and revision metadata, name validation against an available_tools list you supply, and a history you can clear mid-run. Do not adopt it if you expect the server to discover your other MCP tools or pick one for the model; the README states it does neither. Before wiring it in, verify the redaction behaviour of the security scan on your own thought text, because the README describes it as defensive filtering rather than a safety guarantee, and confirm your client can speak the stdio transport, since the server accepts both Content-Length framing and newline-delimited JSON.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. spences10/mcp-sequentialthinking-tools on GitHub