Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Atom of Thoughts Use AoT-fast to analyze tradeoffs between JWT and session auth."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Structured reasoning for LLMs. Decompose, track confidence, visualize, approve.
1. Add to your MCP config:
{
"mcpServers": {
"atom-of-thoughts": {
"command": "npx",
"args": ["-y", "@dioptx/mcp-atom-of-thoughts"]
}
}
}2. Restart your client.
3. Ask the model to reason something through:
"Use AoT-fast to think through whether we should use JWT or session-based auth for the API."
The model breaks the problem into five kinds of atoms (premise, reasoning, hypothesis, verification, conclusion), each tagged with a confidence score. You get a structured chain you can audit, not a black-box answer.
Works with Claude Code, Cursor, Windsurf, or any MCP-aware client.
Related MCP server: verifiable-thinking-mcp
npx (recommended; zero install, always latest)
{ "command": "npx", "args": ["-y", "@dioptx/mcp-atom-of-thoughts"] }npm global
npm install -g @dioptx/mcp-atom-of-thoughts{ "command": "mcp-atom-of-thoughts" }Smithery
npx -y @smithery/cli install @dioptx/mcp-atom-of-thoughts --client claudeDocker
docker build -t aot .{ "command": "docker", "args": ["run", "-i", "--rm", "aot"] }graph LR
P["P · Premise"]:::premise --> R["R · Reasoning"]:::reasoning
R --> H["H · Hypothesis"]:::hypothesis
H --> V["V · Verification"]:::verification
V --> C["C · Conclusion"]:::conclusion
classDef premise fill:#6b7280,stroke:#9ca3af,color:#fff,font-weight:bold
classDef reasoning fill:#3b82f6,stroke:#60a5fa,color:#fff,font-weight:bold
classDef hypothesis fill:#eab308,stroke:#facc15,color:#000,font-weight:bold
classDef verification fill:#06b6d4,stroke:#22d3ee,color:#fff,font-weight:bold
classDef conclusion fill:#22c55e,stroke:#4ade80,color:#fff,font-weight:boldAtoms chain through dependencies. Each carries a confidence score from 0 to 1. Reasoning terminates when a high-confidence conclusion lands or max depth is hit. Each problem runs in its own session, so two threads of thought never bleed into each other.
Three tools cover the full surface:
Tool | When to reach for it |
| Default. Tradeoffs, debugging, decisions, option evaluation. Depth 3. |
| Plans, architecture, decomposition into sub-problems. Depth 5. |
| Sessions, export, approval polling, decomposition lifecycle. |
AoT-fast({atomId:"P1", content:"API returns 500 on POST /users", atomType:"premise"})
AoT-fast({atomId:"R1", content:"Unhandled exception in route handler", atomType:"reasoning", dependencies:["P1"]})
AoT-fast({atomId:"C1", content:"Add try-catch in POST handler", atomType:"conclusion", dependencies:["R1"], confidence:0.9})Only atomId, content, and atomType are required. Everything else has sensible defaults.
Pass viz: true on any call to open an interactive D3 graph in the browser:
AoT-fast({atomId:"C1", ..., viz: true})Approve and reject decisions POST back to the server over HTTP. No filesystem polling.
Watch the model reason in a second terminal pane while it works, and feed approve/reject decisions back into the next tool call. The event feed is on by default; nothing extra to configure.
In a second pane next to your LLM client:
npx -y @dioptx/mcp-atom-of-thoughts tui
Atoms appear as the model emits them, walking the chain premise → reasoning → hypothesis → verification → conclusion. Confidence bars fill in real time, dependencies show as inline arrows, and a velocity sparkline tracks event rate. Auto-scroll keeps the newest atom selected.
j / k move the selection. a accepts an atom; * stars it as critical context; r rejects it and prompts for a one-line reason. s submits the verdict. The submit flash tells you exactly what to do next: ask the model to call atomcommands check_approval. The verdict is written as the same approval JSON the existing file-fallback path already polls for, so feedback flows back through a contract the server already understands. Zero new wire protocol.
t opens settings: confidence threshold to hide low-confidence atoms, color theme (vibrant, soft, or mono), compact mode, dependency arrows toggle. ? shows the full keymap.
Key | Action |
| Move selection |
| Accept the selected atom |
| Reject (prompts for a one-line reason) |
| Clear feedback on the selected atom |
| Star as critical context |
| Submit verdict (writes |
| Settings (threshold, theme, compact mode, deps) |
| Keys help |
| Pause / resume event stream |
| Quit |
Skip setup and see it in action:npx -y @dioptx/mcp-atom-of-thoughts tui --demo
{
"args": ["-y", "@dioptx/mcp-atom-of-thoughts", "--mode", "fast", "--viz", "never"]
}Flag | Default | Effect |
|
| Which tools to register |
|
|
|
| 5 / 3 | Override depth limit |
| OS temp | Where to write viz HTML |
| ~/Downloads | Approval JSON fallback |
Each reasoning chain gets its own session. Default ID: "default".
atomcommands new_session creates and activates a new one.
atomcommands switch_session / list_sessions / reset_session for management.
When reasoning terminates, the session auto-archives. The next zero-dependency atom auto-spawns default-2, default-3, and so on.
Or pass sessionId on any AoT call to target one explicitly.
Two problems in one MCP process stay isolated without manual session management.
Prefer a browser tab to a terminal pane? Pass viz: true on any AoT call. The server writes a self-contained HTML file (D3 inlined, works offline) and opens it:
Force-directed graph colored by atom type with confidence rings
Sidebar to approve or reject phases or individual atoms
Approve / reject POSTs to a local 127.0.0.1 listener on an ephemeral port; falls back to a ~/Downloads file scan if the listener can't bind
The TUI and the browser viz both feed atomcommands check_approval. Pick whichever fits your workflow.
npx (zero install):
{ "command": "npx", "args": ["-y", "@dioptx/mcp-atom-of-thoughts"] }npm global:
npm install -g @dioptx/mcp-atom-of-thoughtsSmithery:
npx -y @smithery/cli install @dioptx/mcp-atom-of-thoughts --client claudeDocker:
docker build -t aot . && docker run -i --rm aotgit clone https://github.com/dioptx/mcp-atom-of-thoughts.git
cd mcp-atom-of-thoughts
npm install
npm test # 183 tests (unit + e2e)
npm run buildSee MIGRATION_v2_to_v3.md for the full lookup table. The short version:
AoT-light is now AoT-fast
AoT is now AoT-full
generate_visualization is now viz: true on any AoT call
export_graph and check_approval are now atomcommands subcommands
--no-viz and --no-approval are replaced by --viz auto|always|never
MIT. Based on Atom of Thoughts.
Default structured reasoning. Decomposes problems into atomic thoughts with dependency tracking. Depth 3.
Use for: think-through, analyze, reason about tradeoffs, debug root causes, evaluate alternatives, make decisions. Most reasoning tasks belong here.
Trigger phrases: "think through", "analyze", "reason about", "debug", "evaluate options", "compare approaches".
Atom types: premise (facts) → reasoning (logic) → hypothesis (proposals) → verification (checks) → conclusion (answer).
Minimal 3-call example: Call 1: {atomId:"P1", content:"The API returns 500 on POST /users", atomType:"premise"} Call 2: {atomId:"R1", content:"500 suggests unhandled exception in route handler", atomType:"reasoning", dependencies:["P1"]} Call 3: {atomId:"C1", content:"Add try-catch in POST /users handler", atomType:"conclusion", dependencies:["R1"], confidence:0.9}
Only atomId, content, and atomType are required. dependencies defaults to [], confidence defaults to 0.7.
Use AoT-full instead when you need >5 reasoning steps, multi-angle verification, or decomposition of sub-problems.
viz param: only set viz:true when the user explicitly asks to see the graph or says "visualize". Never set it automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| atomId | Yes | Unique identifier for the atom (e.g., 'P1', 'R1', 'H1', 'C1') | |
| content | Yes | The thought content of this atom | |
| atomType | Yes | Type of atom | |
| dependencies | No | IDs of atoms this depends on (default: []) | |
| confidence | No | Confidence 0-1 (default: 0.7) | |
| isVerified | No | Whether this atom has been verified | |
| depth | No | Depth level (auto-calculated if omitted) | |
| viz | No | Render and open a D3 visualization of the current graph after this atom (default: false). Set true during planning or when the user is reviewing your reasoning; leave false during execution. | |
| sessionId | No | Target session for this atom (default: active session). Sessions isolate atom graphs so two reasoning problems in one process don't collide. Use atomcommands new_session/switch_session to manage explicitly. Auto-spawned on next zero-dep atom after a session terminates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description covers depth, atom types, required/optional fields, defaults, and viz param usage. Could add read-only hint but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and example, though slightly long. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, description covers usage, parameters, and behavior comprehensively. Example helps. Lacks return value info but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds significant value: explains defaults, provides example, clarifies viz and sessionId usage, and gives atom type enum semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's for structured reasoning, lists specific use cases and trigger phrases, and distinguishes from sibling tool AoT-full.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (think-through, analyze, etc.) and when not (use AoT-full for complex cases), including trigger phrases and alternative tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep structured reasoning with decomposition-contraction. Depth 5.
Use for: implementation plans, architecture decisions, multi-step verification, problems that decompose into sub-problems.
Trigger phrases: "plan", "design", "megathink", "full AoT", /aot-plan.
Same atom types and parameters as AoT-fast. Drives decomposition via the atomcommands tool (decompose → sub-atoms → complete_decomposition). Reach for AoT-fast first unless you genuinely need the extra depth or decomposition.
viz param: only set viz:true when the user explicitly asks to see the graph or says "visualize". Never set it automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| atomId | Yes | Unique identifier for the atom (e.g., 'P1', 'R1', 'H1', 'C1') | |
| content | Yes | The thought content of this atom | |
| atomType | Yes | Type of atom | |
| dependencies | No | IDs of atoms this depends on (default: []) | |
| confidence | No | Confidence 0-1 (default: 0.7) | |
| isVerified | No | Whether this atom has been verified | |
| depth | No | Depth level (auto-calculated if omitted) | |
| viz | No | Render and open a D3 visualization of the current graph after this atom (default: false). Set true during planning or when the user is reviewing your reasoning; leave false during execution. | |
| sessionId | No | Target session for this atom (default: active session). Sessions isolate atom graphs so two reasoning problems in one process don't collide. Use atomcommands new_session/switch_session to manage explicitly. Auto-spawned on next zero-dep atom after a session terminates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the decomposition process via 'atomcommands' and the 'viz' parameter behavior. However, it does not specify what happens at the end of depth 5 (e.g., auto-termination or continuation), which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage, inter-tool comparison, and parameter notes. Every sentence adds value, and there is no unnecessary verbiage. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema), the description covers all critical aspects: core functionality, usage conditions, important parameter nuances (sessionId, viz), and relationship to sibling tools. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds useful context beyond the schema, particularly for 'sessionId' (explaining isolation and auto-spawning) and 'viz' (when to set it). This extra guidance is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'deep structured reasoning with decomposition-contraction' at 'Depth 5', and lists specific use cases and trigger phrases. It effectively distinguishes itself from the sibling 'AoT-fast' by noting it is used when extra depth or decomposition is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool ('implementation plans, architecture decisions, multi-step verification, problems that decompose into sub-problems'), provides trigger phrases, and advises to use 'AoT-fast' first unless genuinely needing extra depth. This clearly guides the agent on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lifecycle and meta operations for the current AoT session.
Commands:
decompose: Break an atom into sub-atoms (requires atomId)
complete_decomposition: Finish a decomposition (requires decompositionId)
termination_status: Check if reasoning should stop
best_conclusion: Get the highest-confidence verified conclusion
set_max_depth: Change max depth limit (requires maxDepth)
export: Export the current atom graph as JSON for analysis or visualization (optional title)
check_approval: Poll for browser-based approval decisions (optional downloadsDir, sessionStartTime)
new_session: Create and switch to a new session (optional sessionId; auto-generated if omitted)
switch_session: Activate an existing session (requires sessionId)
list_sessions: List all sessions with status and atom counts
reset_session: Wipe atoms in a session (defaults to active)
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to execute | |
| atomId | No | Atom ID (for decompose) | |
| decompositionId | No | Decomposition ID (for complete_decomposition) | |
| maxDepth | No | Maximum depth (for set_max_depth) | |
| title | No | Optional title (for export) | |
| downloadsDir | No | Override downloads directory (for check_approval) | |
| sessionStartTime | No | Unix timestamp to ignore older approval files (for check_approval) | |
| sessionId | No | Session ID (for new_session/switch_session/reset_session, optional for new_session/reset_session) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries full burden. It discloses some behavioral traits (e.g., 'Wipe atoms' for reset_session, 'requires atomId' for decompose), but lacks details on error conditions, ordering constraints, or state changes. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a list of commands and their details. It is fairly concise given the number of subcommands, though some verbosity could be trimmed (e.g., repeating 'requires' in each item).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description fails to explain what each command returns (e.g., does export return JSON? does list_sessions return a list?). It also omits prerequisites like needing an active session. These gaps hinder an AI agent from fully understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters (schema_coverage=100%). The description adds minimal value beyond repeating which command uses which parameter, so it does not significantly enhance meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool handles 'lifecycle and meta operations for the current AoT session' and enumerates multiple subcommands with brief explanations. However, it does not differentiate from sibling tools (AoT-fast, AoT-full) which likely have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (AoT-fast, AoT-full). The description only lists available commands without context on selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v3.0.0AoT-fastAoT-fullatomcommandsEach tool has a clearly distinct purpose: AoT-fast handles simple structured reasoning, AoT-full handles deep reasoning with decomposition, and atomcommands manages lifecycle operations. There is no ambiguity about which tool to use for a given task.
Naming is somewhat inconsistent: two tools use the prefix 'AoT-' (AoT-fast, AoT-full) while the third uses a different style (atomcommands). This mixed convention makes the set less predictable but still readable.
Three tools is on the low side for a reasoning server that offers multiple capabilities (simple reasoning, deep reasoning, lifecycle operations). The boundary between AoT-fast and AoT-full could be merged into one tool with a depth parameter, and atomcommands bundles many features into one tool.
The tool set covers the core reasoning workflow (simple and deep) and all necessary life-cycle operations (sessions, decomposition, export). Minor gaps exist, such as a dedicated tool to list atoms in a session, but these can be addressed via existing commands like export.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for generating rough-draft project plans from natural-language prompts.
Shared reasoning for unresolved, disputed, multi-step, provenance-sensitive problems across agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dioptx/mcp-atom-of-thoughts'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
