MAXential Thinking MCP

Name: MAXential Thinking MCP
Author: BAM-DevCrew

by BAM-DevCrew

Overview Schema Related Servers Score Discussions

TypeScript

Local

MAXential Thinking MCP

A structured, persistent reasoning workspace for AI. Provides 20 tools for building thought chains, exploring alternatives through branching, revising earlier thinking, searching reasoning history, and persisting sessions across context window resets and server restarts.

AI's built-in reasoning is ephemeral — when context windows fill, thinking gets compressed or lost. Complex problems need exploration of multiple approaches, backtracking when paths fail, and the ability to resume where you left off. MAXential externalizes reasoning into a workspace that persists, branches, and survives.

Origin

Forked from Anthropic's sequential-thinking MCP server, which provided a single tool with 9 parameters. Its schema included branching parameters (branch_from_thought, branch_id) but had no tools to create, switch, or manage branches — the parameters were effectively inert.

MAXential replaced that single tool entirely and built 20 purpose-specific tools across three releases:

Version	What was built
v2.0	Replaced the single tool with 11 focused tools: core thinking (`think`, `revise`, `complete`), full branch management (`branch`, `switch_branch`, `list_branches`, `get_branch`, `close_branch`, `merge_branch`), and navigation (`get_thought`, `get_history`)
v2.2	Added 5 organization tools: `tag`, `search`, `export`, `visualize`, `reset`
v2.3	Added 4 session persistence tools with SQLite storage: `session_save`, `session_load`, `session_list`, `session_summary`

Related MCP server: Think Strategies

Tools

Core Thinking

Tool	What it does
`think`	Add a thought to the reasoning chain. Thoughts are numbered and persisted automatically.
`revise`	Revise a previous thought when earlier thinking was flawed or incomplete. The original is preserved with revision history.
`complete`	Mark the thinking chain complete with a final conclusion.
`reset`	Clear the current session and start fresh.

Branching

Tool	What it does
`branch`	Create a new reasoning branch to explore an alternative path without losing the main thread.
`switch_branch`	Switch context to a different branch, or back to main.
`list_branches`	List all branches with their status and thought counts.
`get_branch`	Retrieve complete details of a specific branch.
`close_branch`	Close a branch with an optional conclusion.
`merge_branch`	Merge insights from a branch back into main. Strategies: `conclusion_only`, `full_integration`, `summary`.

Tool	What it does
`get_thought`	Retrieve a specific thought by its number.
`get_history`	Get thought history, optionally filtered by branch.

Organization

Tool	What it does
`tag`	Add or remove semantic tags on a thought (e.g., hypothesis, evidence, decision, finding).
`search`	Search thoughts by content text or by tags.
`export`	Export the thinking chain as markdown or JSON.
`visualize`	Generate ASCII or Mermaid diagrams of the thought structure and branches.

Session Persistence

Tool	What it does
`session_save`	Name and describe the current session for later retrieval.
`session_load`	Restore a saved session — all thoughts, branches, and tags are loaded back into memory.
`session_list`	Browse available sessions, most recently updated first.
`session_summary`	Generate a compressed summary of a session for token-efficient context loading.

Sessions are automatically persisted to SQLite as you work. Every think, branch, tag, and revise call writes through to disk in real time. Sessions survive server restarts, context window resets, and new conversations — pick up where you left off.

What the original provides vs. what MAXential provides

Capability	Anthropic sequential-thinking	MAXential Thinking
Interface	1 tool, 9 parameters	20 focused tools
Branching	Parameters in schema, no implementation	Full lifecycle: create, switch, list, inspect, merge, close
Revision	Not supported	Revise any thought, original preserved with history
Persistence	None — lost on server restart	SQLite — survives restarts, context resets, new conversations
Tagging	Not supported	Semantic tags on any thought
Search	Not supported	Search by content or tags
Export	Not supported	Markdown, JSON, Mermaid diagrams, ASCII visualization
Navigation	Not supported	Retrieve any thought by number, browse filtered history

Browsing session history

Session data is stored in a standard SQLite database at .maxential/thinking.db. There are several ways to browse past reasoning sessions:

Through the tools themselves — ask AI to use session_list to browse sessions, session_load to restore one, or session_summary for a compressed overview. AI can format, search, and summarize session content conversationally.

With a SQLite browser — open .maxential/thinking.db in any SQLite viewer (VS Code/VSCodium extensions, DB Browser for SQLite, or similar). The schema is straightforward:

Table	Contains
`sessions`	Session ID, name, description, status, timestamps
`thoughts`	Every thought with its number, content, branch, revision links
`branches`	Branch metadata, status, conclusions, merge history
`tags`	Semantic tags attached to thoughts

From the terminal:

sqlite3 .maxential/thinking.db "SELECT name, status, datetime(created_at/1000, 'unixepoch', 'localtime') as created FROM sessions ORDER BY updated_at DESC LIMIT 10;"

Installation

Claude Desktop / Claude Code

Add to your MCP configuration:

Claude Desktop config location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "maxential-thinking": {
      "command": "npx",
      "args": ["-y", "@bam-devcrew/maxential-thinking-mcp"]
    }
  }
}

From source

git clone https://github.com/BAM-DevCrew/MAXential-Thinking-MCP.git
cd MAXential-Thinking-MCP
npm install
npm run build

Then configure:

{
  "mcpServers": {
    "maxential-thinking": {
      "command": "node",
      "args": ["/path/to/MAXential-Thinking-MCP/dist/src/index.js"]
    }
  }
}

Configuration

Persistence

Session data is stored in SQLite. By default, the database is created at .maxential/thinking.db in the working directory.

{
  "mcpServers": {
    "maxential-thinking": {
      "command": "npx",
      "args": ["-y", "@bam-devcrew/maxential-thinking-mcp"],
      "env": {
        "MAXENTIAL_DB_PATH": "/path/to/your/thinking.db"
      }
    }
  }
}

`MAXENTIAL_DB_PATH` value	Behavior
(not set)	`.maxential/thinking.db` in working directory
`/path/to/file.db`	Use explicit file path
`:memory:`	In-memory only — no persistence across restarts

If SQLite initialization fails (permissions, native module issues), the server falls back to in-memory mode automatically — it never crashes.

Add .maxential/ to your project's .gitignore to keep session data out of version control.

Logging

{
  "mcpServers": {
    "maxential-thinking": {
      "command": "npx",
      "args": ["-y", "@bam-devcrew/maxential-thinking-mcp"],
      "env": {
        "MAXENTIAL_LOG_FILE": "/path/to/error.log"
      }
    }
  }
}

Usage

You don't call these tools directly — you ask your AI to use MAXential thinking, and it calls the tools as part of its reasoning. Here are examples of what that looks like in practice.

Working through a decision:

use maxential thinking for this - should we use REST or GraphQL for the new API?

AI builds a thought chain analyzing the question, branches to explore each approach separately, adds thoughts with tradeoffs, merges the findings, and reaches a conclusion. The entire reasoning process is numbered, structured, and persisted.

Exploring multiple approaches:

think through the auth redesign using maxential - I want to see branches for JWT, session tokens, and OAuth

AI creates three branches, reasons through each approach independently, then merges the insights back to compare. You can ask it to switch between branches, close dead ends, or dig deeper into a specific path.

Resuming previous thinking:

load up that session where you analyzed our database optimization options

AI browses saved sessions, finds the match, restores it with all thoughts, branches, and tags intact, and continues reasoning from where it left off — even across different conversations.

Reviewing past reasoning:

search your maxential thinking history for anything tagged as a decision

AI searches across the session's tagged thoughts and returns the results. You can also ask it to export the full chain as markdown, or generate a diagram of the thought structure.

Getting a quick summary:

give me a summary of that session - just the key findings, keep it short

AI generates a compressed summary of the session's conclusions, tagged highlights, and branch results — useful for loading context without replaying the full chain.

Development

npm install          # Install dependencies
npm run build        # Build TypeScript
npm run watch        # Watch mode
npm test             # Run tests with coverage
npm run test:unit    # Unit tests only
npm run test:integration  # Integration tests only

License

MIT

Contributing

Issues and PRs welcome at github.com/BAM-DevCrew/MAXential-Thinking-MCP

Available Tools

20 tools

branchA

Create a new reasoning branch and switch to it. Subsequent think calls go to this branch until you switch_branch. Use to explore an alternative approach without affecting the main thread. Each branch maintains its own thought sequence. Persists to SQLite. Use close_branch when a path is exhausted, or merge_branch to bring insights back to main.

ParametersJSON Schema

Name	Required	Description	Default
`reason`	Yes	Why you are branching
`branchId`	Yes	A short identifier for this branch

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description bears the full burden. It discloses persistence ('Persists to SQLite') and independence ('Each branch maintains its own thought sequence'). It does not mention any side effects or permissions, but the behavior is clear enough for safe use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences, each adding essential information. Front-loaded with the primary action. No redundant or filler words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description fully explains what happens (creates, switches, persists, maintains sequence). References sibling tools for further actions. Complete for a creation tool with two parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description mentions 'branchId' as a short identifier and 'reason' as why branching, which aligns with schema descriptions. No additional value beyond confirming purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create a new reasoning branch and switch to it') and clearly identifies the resource and action. It distinguishes itself from sibling tools by mentioning 'explore an alternative approach without affecting the main thread' and referencing close_branch and merge_branch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use context ('explore an alternative approach without affecting the main thread') and how subsequent calls work ('Subsequent think calls go to this branch until you switch_branch'). Also directs when to use alternatives ('Use close_branch when a path is exhausted, or merge_branch to bring insights back').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

close_branchA

Close a branch, marking it as no longer active. Optionally include a conclusion summarizing what was learned. Closed branches and their thoughts are preserved and remain readable. Use when a line of reasoning is exhausted or the answer is clear. Cannot be reopened. To bring findings back to main first, use merge_branch instead.

ParametersJSON Schema

Name	Required	Description	Default
`branchId`	Yes	The ID of the branch to close
`conclusion`	No	Summary or conclusion

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: branch and thoughts preserved, cannot be reopened. With no annotations, description adequately covers behavioral traits. Minor gap: no mention of permissions or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences well-structured: action, option, preservation, usage guidance. Front-loaded with core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for simple tool with two params. Describes what happens and usage context. No output schema needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage and description mentions optional conclusion, but adds no new detail beyond schema descriptions. Baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states action 'Close a branch' and resource. Explicitly distinguishes from sibling merge_branch by advising to use it instead for bringing findings back to main.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use ('line of reasoning exhausted or answer clear') and when-not (cannot be reopened, suggests merge_branch as alternative).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

completeA

Mark the thinking chain as complete with a final conclusion. Sets the session status to 'complete'. Use when reasoning has reached a definitive answer. The session remains accessible via session_load and session_list. Do not call if you plan to continue thinking — you can always add more thoughts.

ParametersJSON Schema

Name	Required	Description	Default
`conclusion`	Yes	Your final conclusion or answer

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the status change to 'complete' and persistence via session_load/list. However, it doesn't explicitly state irreversibility or side effects on branches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence adds value: action, status, usage condition, persistence info, and explicit don't-call advice. No fluff, well organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is fairly complete for a simple tool, covering purpose, usage, behavior, and persistence. Minor gap: no mention of return value or confirmation, but no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear description. The description adds no new meaning beyond the schema's 'Your final conclusion or answer', meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Mark the thinking chain as complete with a final conclusion' and sets session status to 'complete'. It differentiates from siblings like 'think' (add thoughts) and 'session_save' (save without completion).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'when reasoning has reached a definitive answer', and when not: 'Do not call if you plan to continue thinking'. Also mentions the alternative of adding more thoughts, and notes session accessibility after.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

exportA

Export the current session's thinking chain as formatted text. Read-only. Markdown format produces a human-readable document with section headers per thought, branch headings, and tags as inline markers — suitable for handoffs or documentation. JSON format produces machine-parseable output including all thoughts, branches, tags, and metadata. Optionally export a single branch by providing branchId. Default format is markdown. Use when sharing reasoning with humans or other systems.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format (default: markdown)
`branchId`	No	Export only a specific branch

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states 'Read-only' and describes both output formats and branch filtering. Could mention any limitations, but adequate for a simple export tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with about 5 sentences, front-loaded with main purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output schema but describes return formats adequately. For a simple export tool, it covers necessary aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions. The description adds context about default format and human-readable vs machine-parseable, slightly extending beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports the current session's thinking chain as formatted text, specifying markdown and JSON formats. It distinguishes from sibling tools like get_branch or get_thought.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context: 'Use when sharing reasoning with humans or other systems.' It also mentions optional single-branch export. No explicit when-not-to-use or alternatives, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_branchA

Retrieve a specific branch's metadata and full thought history. Read-only. Returns: branch ID, origin thought, status (active/closed/merged), conclusion if set, all thoughts in the branch with their numbers and content, and timestamps. Use to deeply inspect a branch's reasoning before deciding to merge, close, or continue it. Use list_branches first to get the branch ID.

ParametersJSON Schema

Name	Required	Description	Default
`branchId`	Yes	The ID of the branch to retrieve

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description clearly labels it as 'Read-only' and details the return fields. Lacks mention of error states or rate limits, but for a simple read operation, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences, each adding value: purpose, return contents, usage context, and prerequisite. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description fully explains the output fields. It covers purpose, usage, output, and prerequisite. Complete for a simple one-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter 'branchId' is fully described in the input schema (100% coverage). The description adds no additional parameter semantics beyond advising to get it from list_branches, which is contextual rather than semantic.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a specific branch's metadata and full thought history, specifying the action and resource. It distinguishes from sibling tools like list_branches (which only lists branches) and get_thought (single thought).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use to deeply inspect a branch's reasoning before deciding to merge, close, or continue it.' Also provides a prerequisite: 'Use list_branches first to get the branch ID.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_historyA

Retrieve the thought history for the current active session. Read-only. Returns thoughts in chronological order with their numbers, content, tags, branch assignments, and any revision links. Optionally filter to a specific branch with branchId, or cap results with limit. Use to review the full reasoning chain or to find context before adding the next thought.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Optional: limit results
`branchId`	No	Optional: filter by branch

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only behavior, chronological order, and contents (numbers, content, tags, branch assignments, revision links). Also mentions optional filtering with branchId and limit. Without annotations, this provides good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded key information: purpose, read-only, return contents, and usage recommendation. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description explains return details well. Covers optional parameters and use cases. Minor omission of behavior when history is empty, but overall complete for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover 100% of parameters. Description adds context 'optionally filter to a specific branch' and 'cap results', which reinforces schema but doesn't add new meaning beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies verb 'Retrieve', resource 'thought history', and scope 'for the current active session'. It distinguishes from siblings like get_thought (single thought) and list_branches, making the tool's unique purpose clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use cases: 'review the full reasoning chain or to find context before adding the next thought'. While it doesn't list alternatives, the context is clear and sufficient for an agent to choose appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_thoughtA

Retrieve a specific thought by its number, including any tags and revision history. Read-only. Use to reference or review earlier reasoning without scrolling through the full history.

ParametersJSON Schema

Name	Required	Description	Default
`thoughtNumber`	Yes	The thought number to retrieve

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It declares the tool is 'read-only' and lists output contents (tags, revision history). For a simple retrieval operation, this is sufficient behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundant information. The key action and purpose are front-loaded, making it efficient for an AI agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter, no output schema, and no enums, the description covers purpose, usage context, and behavior adequately. Mentioning the return format explicitly would be nice but is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a clear parameter description. The description adds value by specifying the response includes tags and revision history, reinforcing the parameter's role beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'Retrieve', the resource 'thought by its number', and the included data 'tags and revision history'. It clearly distinguishes from siblings like 'get_history' (full history) and 'think' (adds thoughts).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the use case: 'to reference or review earlier reasoning without scrolling through the full history'. This gives clear context for when to use this tool, though it does not explicitly mention alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_branchesA

List all reasoning branches in the current session. Read-only. Returns for each branch: branch ID, origin thought number, status (active/closed/merged), conclusion if set, thought count, and timestamps. Use to see what reasoning paths exist before switching, merging, or closing. The main branch is always included. No parameters — operates on the active session.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully compensates by stating read-only, listing return fields (branch ID, status, timestamps, etc.), and noting that the main branch is always included and no parameters are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded sentences with no fluff. Each sentence adds essential information: purpose, read-only nature, return fields, usage context, and parameter absence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no parameters and no output schema, the description is complete. It covers what it does, what it returns, how it's used, and its read-only nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters (0), schema coverage 100%. Description adds value by clarifying 'operates on the active session', which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List all reasoning branches in the current session', which is a specific verb+resource. It distinguishes from sibling tools like branch, close_branch, switch_branch, etc., by focusing on listing existing branches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description advises using before switching, merging, or closing branches, providing clear context for when to use. It doesn't explicitly exclude other scenarios, but the guidance is helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

merge_branchA

Merge findings from a branch back into the main thread as a new thought on main. The branch is marked as merged afterward. Strategies: conclusion_only — adds only the branch conclusion to main; full_integration — adds all branch thoughts to main; summary — generates a condensed summary of the branch on main. Use after a branch has produced useful findings you want on the main thread.

ParametersJSON Schema

Name	Required	Description	Default
`branchId`	Yes	The ID of the branch to merge
`strategy`	Yes	How to merge

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the branch is marked as merged and new thoughts are added. It lists three strategies. However, it does not specify whether the branch is closed automatically, nor how conflicts are handled, leaving minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a concise list of strategies. The main action is front-loaded. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only two parameters and no output schema, the description is largely complete. It covers the core behavior, when to use, and strategy options. It could mention the return value (a new thought on main) but is not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining each strategy in context ('conclusion_only — adds only the branch conclusion'), which is beyond the schema's simple enum descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'merge' and the resource 'branch', and specifies the outcome: 'back into the main thread as a new thought on main.' It distinguishes from sibling tools like 'close_branch' by being the dedicated merge operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use: 'Use after a branch has produced useful findings you want on the main thread.' It implies when not to use (e.g., no useful findings), but does not name alternatives like 'close_branch' or 'get_branch'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resetA

Clear the in-memory thinking state and start a fresh session. The previous session's data is NOT deleted — it remains in SQLite and can be loaded later with session_load. Destructive to in-memory state only. Returns confirmation. Use when switching to an unrelated problem where carrying the old context would be noise. Requires confirm=true to prevent accidental clearing.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	Must be true to confirm reset (prevents accidental clearing)

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description fully discloses: destructive only to in-memory state, data retained in SQLite, returns confirmation, and requires confirm flag. No surprises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, safety note, usage guidance. No redundancy, each sentence contributes unique information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects for a simple reset tool: what it does, what it doesn't do, when to use, parameter requirement, and return type (confirmation). No output schema needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, description adds context on why confirm is needed (prevents accidental clearing), going beyond type info. Slight added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it clears in-memory state and starts fresh session. Distinguishes from sibling tools (session_load) by noting previous data remains in SQLite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (switching to unrelated problem) and implies when not to. Also mentions confirm=true requirement to prevent accidental clearing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reviseA

Replace a previous thought with updated reasoning. The original thought is preserved in revision history. Use when earlier thinking was wrong, incomplete, or superseded by new information. Persists to SQLite. Do not use to add new thoughts — use think instead.

ParametersJSON Schema

Name	Required	Description	Default
`thought`	Yes	Your revised thinking
`revisesThought`	Yes	The thought number being revised

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the tool replaces a thought, preserves the original in revision history, and persists to SQLite. These are clear behavioral traits for a mutation operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, and every sentence provides essential information. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 simple parameters, no output schema, no annotations, and a single clear purpose, the description covers all necessary context: what it does, when to use, and its persistence behavior. It is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters have descriptions. The description adds minimal new meaning beyond the schema, only specifying that 'thought' is revised thinking and 'revisesThought' is the thought number. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it replaces a previous thought with updated reasoning, preserving the original in history. It distinguishes from 'think' (add new thoughts) and from other tools like 'branch' or 'complete'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use ('when earlier thinking was wrong, incomplete, or superseded') and when not to use ('do not use to add new thoughts — use think instead'). Also notes persistence behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchA

Search the current session's thoughts by text content, tags, or both. Text search is case-insensitive substring matching. Tag search requires all specified tags to be present. Optionally limit to a specific branch. Read-only. Returns matching thoughts with their numbers, content, and tags.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Filter by tags (must have all specified)
`query`	No	Text to search for (case-insensitive)
`branchId`	No	Limit search to specific branch

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses read-only nature, case-insensitive substring matching, and tag requirement (all tags must be present). It does not describe behavior when no parameters are provided (likely returns all thoughts) but overall is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, and contains no redundant information. Every sentence adds meaningful detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values (numbers, content, tags). It covers the main use cases but lacks details about pagination or handling of empty results. Still, it is adequate for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have descriptions in the schema. The description adds value by explaining the search semantics (case-insensitive, requires all tags, branch limiting) beyond the schema's basic field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches thoughts by text content, tags, or both, with specific matching behavior. It distinguishes from siblings like get_thought (by ID) and think (adds thoughts) by focusing on full-text/tag search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context about searching within the current session and available search modes. However, it does not explicitly state when not to use this tool (e.g., if thought ID is known) or list alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

session_listA

List previously saved thinking sessions in the SQLite database. Read-only. Returns: session UUID, name, description, status (active/complete/archived), created/updated timestamps, thought count, branch count. Sorted by most recently updated first. Use to find a session UUID before calling session_load or session_summary. Filter by status to find specifically complete or archived work.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max sessions to return (default: 20)
`status`	No	Filter by session status

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Declares read-only behavior, lists return fields and ordering. Without annotations, this provides essential safety information. Could mention lack of side effects more explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, efficient and no redundancy. Each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description includes return fields, sorting, and usage context. Covers all necessary information for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description only mentions filtering by status, which is already in schema, and does not add new semantic meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List previously saved thinking sessions in the SQLite database' and specifies it is read-only, distinguishing it from sibling tools like session_load and session_summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using it to find a session UUID before calling session_load or session_summary, and suggests filtering by status. Does not mention when not to use it, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

session_loadA

Restore a previously saved thinking session into memory, replacing the current in-memory state. All thoughts, branches, and tags from the saved session are loaded. The current session's data is not lost — it remains in SQLite and can be loaded later. Use after session_list to find the session UUID. Replaces current working state.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The session UUID to load (from session_list)

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It fully discloses that the in-memory state is replaced, but the current session remains in SQLite. States that all thoughts, branches, and tags are loaded. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with core purpose, followed by details and usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains state changes but does not mention return value or error handling. For a simple tool with one parameter, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for 'id'. The description adds context that the ID comes from session_list, improving usability beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool restores a saved thinking session, replaces current state, and loads all thoughts, branches, and tags. It distinguishes from siblings like session_save and session_list by specifying the action and context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use after session_list to obtain the UUID. Notes that current session data is not lost. Lacks explicit when-not-to-use or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

session_saveA

Name and describe the active thinking session for later retrieval. The session and all its thoughts are already persisted to SQLite automatically — this only adds a human-readable name and optional description. Persists session metadata. Use when you want to find this session later via session_list. Without session_save, the session keeps an auto-generated timestamp name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	A descriptive name for this session (e.g., 'Debugging auth flow')
`description`	No	Optional longer description of the session's purpose or context

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully discloses that the session is already persisted automatically and that this tool only adds metadata, avoiding any misleading implication of creating new data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with no unnecessary words. Front-loaded with the main purpose, followed by clarification of behavior and usage, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, lack of output schema, and straightforward parameters, the description covers behavior, usage, and parameter meaning completely, without needing additional details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions. The description adds 'human-readable' and 'optional longer description' but doesn't significantly extend beyond schema, earning the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to add a human-readable name and optional description to an already-persisted session, distinguishing it from sibling tools like session_list and session_load.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when you want to find this session later via session_list' and explains the alternative without the tool (auto-generated timestamp), providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

session_summaryA

Generate a compressed text summary of a saved session for token-efficient context loading. Read-only. Returns: session metadata, key findings extracted from conclusions and tagged thoughts, branch results, and final conclusion. Use when you want context from a previous session without loading the full thought history. For full restoration use session_load instead. Default summary length is 2000 characters, adjustable via maxLength.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The session UUID to summarize
`maxLength`	No	Target summary length in characters (default: 2000)

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool is read-only, specifies the returned content format (metadata, key findings, branch results, final conclusion), and mentions the default and adjustable summary length. Without annotations, it provides solid behavioral context, though it could further detail any potential side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and consists of four sentences that each add valuable information without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates by listing return fields. It covers usage, behavior, parameters, and output, making it sufficiently complete for a tool of moderate complexity with only two parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema (mentioning 'adjustable via maxLength' but default is already in schema). It does not deeply elaborate on parameter behavior or constraints beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('generate') and resource ('compressed text summary of a saved session'). It also notes read-only behavior and distinguishes from the sibling tool session_load.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('when you want context from a previous session without loading the full thought history') and when not to use it ('for full restoration use session_load instead'), providing clear guidance and an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

switch_branchA

Switch which branch receives new thoughts. Omit branchId to return to main. After switching, all think and revise calls apply to the active branch. Read-only tools (get_thought, search, get_history) can access any branch regardless of which is active. Does not modify any data.

ParametersJSON Schema

Name	Required	Description	Default
`branchId`	No	The branch to switch to, or omit for main

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses behavior: no data modification, read-only tools can access any branch. Explains effect on subsequent non-read tools. This compensates for lack of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each serving a purpose: purpose, omission behavior, additional context. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple tool, description covers purpose, parameter behavior, side effects, and interaction with sibling tools. Complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter description. Description reinforces omission behavior ('omit branchId to return to main') but adds no new semantics beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's purpose: 'Switch which branch receives new thoughts.' Distinguishes from sibling tools like branch, close_branch, merge_branch by specifying the exact action and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context on when to use: after switching, think and revise calls apply to active branch; read-only tools unaffected. Implicitly guides usage but doesn't explicitly exclude cases or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tagA

Add or remove semantic tags on a thought. Tags are searchable via the search tool. Common tags: hypothesis, evidence, decision, finding, question, risk. Persists to SQLite. At least one of 'add' or 'remove' should be provided.

ParametersJSON Schema

Name	Required	Description
`add`	No	Tags to add
`remove`	No	Tags to remove
`thoughtNumber`	Yes	The thought to tag

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses that changes persist to SQLite, which is a key behavioral trait. It does not detail any side effects beyond persistence, but the mutation is straightforward.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasteful words. The main purpose is front-loaded, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description covers purpose, inputs, constraints, persistence, and examples. It is complete enough for an AI agent to understand and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by listing common tag examples and stating the constraint that at least one of 'add' or 'remove' is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds or removes semantic tags on a thought, using a specific verb ('add or remove') and resource ('tags on a thought'). It distinguishes from sibling tools like 'search' by noting tags are searchable via that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage constraint: at least one of 'add' or 'remove' should be provided. It also implies when to use search for finding tags. However, it does not explicitly contrast with other sibling tools like 'think' or 'revise'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

thinkA

Add a numbered thought to your reasoning chain. Each call persists to SQLite automatically. On first call, a new session is created. Use for any multi-step reasoning — analysis, debugging, design, research. Subsequent thoughts are appended to the active branch (main by default). Do not use for simple, single-step answers.

ParametersJSON Schema

Name	Required	Description	Default
`thought`	Yes	Your current thinking step

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses persistence to SQLite, auto-creation of session on first call, and appending to active branch. Without annotations, this provides sufficient behavioral context, though could mention limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences with no wasted words. Front-loaded with core purpose, then persistence, then usage, then exclusion. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple single-parameter tool with no output schema, the description covers purpose, behavior, persistence, session management, and usage boundaries. Complete for effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description already covers the parameter with 100% coverage. Description adds context about 'current thinking step' but doesn't add significantly new semantics beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Add a numbered thought to your reasoning chain' with specific verb and resource. Distinguishes from sibling tools like branch and complete by focusing on adding thinking steps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use for any multi-step reasoning' and 'Do not use for simple, single-step answers', providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

visualizeA

Generate a visual diagram of the thinking chain showing thoughts, branches, branch points, and revisions. Read-only. Returns a single text block ready to display. Mermaid format produces a graph for rendering in GitHub, Obsidian, or markdown documentation. ASCII format produces a plain-text tree for terminal or inline display in conversation. Default format is mermaid. Use to share the reasoning structure or to orient in a long chain. Set showContent=true to include thought preview text in nodes (default false for compactness).

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format (default: mermaid)
`showContent`	No	Include thought content preview (default: false)

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explicitly declares 'Read-only,' which is critical for a tool that visualizes data. It describes output as a single text block, explains the two formats and their rendering contexts, and discloses default values for both parameters. No annotations are present, so the description fully carries the behavioral disclosure burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with the core purpose, then breaking down format choices and parameter effects. Every sentence adds value, though it is slightly verbose for the simple parameter set. Still, it remains clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully explains what the tool returns (single text block) and for what purposes. It covers both parameters, their defaults, and the output's nature. No gaps remain for an agent to successfully invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both parameters described in schema). The description adds substantial value beyond the schema: it explains the utility of each format (mermaid for markdown, ascii for terminal), sets defaults explicitly, and describes the effect of showContent. This helps the agent choose parameter values intelligently.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates a visual diagram of the thinking chain, covering thoughts, branches, branch points, and revisions. This distinctly separates it from sibling tools like 'branch' or 'think' which perform different actions on the chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context for use: 'Use to share the reasoning structure or to orient in a long chain.' This gives the agent a clear scenario for when to invoke. While it doesn't explicitly list when not to use, the purpose is straightforward enough that alternatives are not critical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with detailed descriptions explaining when to use it. Overlapping operations like branch management are partitioned into separate actions (create, switch, close, merge, list, get), preventing confusion.

Naming Consistency5/5

All tool names use lowercase with underscores for multi-word names, following either a verb_noun pattern (get_branch, session_list) or an imperative verb (think, revise, complete). No mixing of conventions or unusual patterns.

Tool Count3/5

With 20 tools, the server falls into the borderline heavy range (16-25). While each tool is justified by the complexity of managing thoughts, branches, sessions, and metadata, the count is slightly high for a focused reasoning tool.

Completeness4/5

The tool set covers core CRUD-like operations for thoughts (add, read, revise) and branches (create, read, close, merge), plus session management. Minor gaps exist: no delete operation for thoughts or sessions, but this aligns with an append-only preservation design.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Brains
io.github.brainsforai
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Knowledge & Memory Note Taking AI & Machine Learning
2
Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
26
agentbay-mcp A
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
writespace-mcp
io.github.write-space
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
Knowledge & Memory Note Taking
2

Related MCP Servers

DevFlow MCP
Knowledge & Memory Developer Tools Autonomous Agents
Takin-Profit
A
license
Not graded
quality
D
maintenance
Provides AI agents with persistent, searchable memory using a knowledge graph stored in SQLite. Features semantic search, temporal awareness, and workflow-aware prompts for development projects.
Updated 10 months ago (2025-11-03 16:28 UTC)
16
MIT
Think Strategies
Autonomous Agents Developer Tools Knowledge & Memory
aaronsb
A
license
B
quality
D
maintenance
Provides 10 structured reasoning strategies (Chain of Thought, ReAct, Tree of Thoughts, etc.) for complex problem-solving with session persistence, branching, and tool integration capabilities.
Updated a year ago (2025-09-15 02:28 UTC)
3
48
28
MIT
Engram
Knowledge & Memory Databases Developer Tools
Jacksini
A
license
Not graded
quality
D
maintenance
A persistent memory server for AI agents that stores structured notes in a local SQLite database with full-text search and graph-based relationships. It features 32 specialized tools for managing long-term context, including version history, automated TTL expiration, and complex filtering.
Updated 5 months ago (2026-04-12 00:23 UTC)
26
MIT
memoir-mcp
Knowledge & Memory Developer Tools Autonomous Agents
bighippoman
A
license
A
quality
D
maintenance
Structured session journals for AI agents. Persistent memory across sessions -- no more repeating dead ends.
Updated 6 months ago (2026-03-06 13:35 UTC)
8
64
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BAM-DevCrew/MAXential-Thinking-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MAXential Thinking MCP

Origin

Tools

Core Thinking

Branching

Navigation

Organization

Session Persistence

What the original provides vs. what MAXential provides

Browsing session history

Installation

Claude Desktop / Claude Code

From source

Configuration

Persistence

Logging

Usage

Development

License

Contributing

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API