What can you do with this server?

The MCP Think Tool Server enhances Claude's complex reasoning and decision-making capabilities by providing structured thinking tools: * Use think to record structured reasoning during complex problem-solving, policy adherence, or sequential decision-making * Retrieve reasoning processes with get_thoughts * Reset thinking with clear_thoughts * Analyze reasoning patterns with get_thought_stats

How do I use MCP Think Tool Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Think Tool Server help me solve this complex physics problem step by step" 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.

en es ja ko zh

MCP Think Tool Server

by cgize

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP Think Tool Server

A Model Context Protocol (MCP) server implementing the "think" tool for improving Claude's complex reasoning capabilities.

Overview

This MCP server implements Anthropic's "think" tool, which provides Claude with a dedicated space for structured thinking during complex problem-solving tasks. As described in Anthropic's blog post, the think tool has been shown to significantly improve performance in complex tasks requiring policy adherence and reasoning in long chains of tool calls.

Related MCP server: Think Tool MCP Server

Custom Instructions

Add these custom instructions to Claude to optimize its use of the think tool:

You have access to a "think" tool that provides a dedicated space for structured reasoning. Using this tool significantly improves your performance on complex tasks. 

## When to use the think tool 
Before taking any action or responding to the user after receiving tool results, use the think tool as a scratchpad to: 
- List the specific rules that apply to the current request 
- Check if all required information is collected 
- Verify that the planned action complies with all policies 
- Iterate over tool results for correctness 
- Analyze complex information from web searches or other tools 
- Plan multi-step approaches before executing them 

## How to use the think tool effectively 
When using the think tool: 
1. Break down complex problems into clearly defined steps 
2. Identify key facts, constraints, and requirements 
3. Check for gaps in information and plan how to fill them 
4. Evaluate multiple approaches before choosing one 
5. Verify your reasoning for logical errors or biases

Key Use Cases

Complex Tool Chains: When Claude needs to call complex tools and analyze outputs carefully
Policy Adherence: For navigating policy-heavy environments with detailed guidelines
Sequential Decision Making: When each step builds on previous ones and mistakes are costly
Multi-step Analysis: Breaking down complex problems into manageable steps

Installation

Installing via Smithery

To install Think Tool Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @cgize/claude-mcp-think-tool --client claude

Manual Installation

npm install -g @cgize/mcp-think-tool

Configuration

Add this configuration to your MCP configuration file:

{
  "mcpServers": {
    "think-tool": {
      "command": "npx",
      "args": [
        "-y",
        "@cgize/mcp-think-tool"
      ],
      "type": "stdio",
      "pollingInterval": 30000,
      "startupTimeout": 30000,
      "restartOnFailure": true
    }
  }
}

Configuration file location:

C:\Users\[username]\AppData\Roaming\Claude\claude_desktop_config.json

If installed globally, you can also use:

{
  "mcpServers": {
    "think-tool": {
      "command": "claude-mcp-think-tool",
      "args": [],
      "type": "stdio",
      "pollingInterval": 30000,
      "startupTimeout": 30000,
      "restartOnFailure": true
    }
  }
}

Available Tools

think: Record structured reasoning during problem-solving
get_thoughts: Retrieve all recorded thoughts
clear_thoughts: Reset the thinking process
get_thought_stats: Analyze thinking patterns

Example Prompt

Using the think tool, solve this multi-step problem:

A train travels at a constant speed of 60 km/h. It departs from station A at 9:00 AM and arrives at station B at 11:30 AM. What is the distance between stations A and B?

License

MIT

Available Tools

4 tools

clear_thoughtsA

Clear all thoughts recorded in the current session. Use this to start fresh if the thinking process needs to be reset.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool clears 'all thoughts' (implying a destructive operation) and specifies scope ('in the current session'), which is useful behavioral context. However, it doesn't mention potential side effects (e.g., irreversible deletion, no confirmation prompt) or response behavior, leaving gaps in 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?

The description is two sentences, front-loaded with the core action ('Clear all thoughts...') followed by usage guidance. Every sentence adds value without redundancy, making it appropriately sized and efficient.

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

Completeness3/5

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

Given the tool's complexity (destructive operation with 0 parameters), no annotations, and no output schema, the description is minimally adequate. It explains what the tool does and when to use it but lacks details on behavioral traits (e.g., confirmation, error handling) and output expectations, leaving room for improvement in completeness.

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?

The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it naturally meets expectations. A baseline of 4 is appropriate as no parameter information is required, and the description focuses on tool behavior instead.

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

Purpose4/5

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

The description clearly states the action ('Clear all thoughts') and the target resource ('thoughts recorded in the current session'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_thoughts' (which retrieves thoughts) or 'think' (which presumably creates thoughts), missing the opportunity for full sibling distinction.

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 clear context on when to use this tool ('to start fresh if the thinking process needs to be reset'), which implies a reset scenario. However, it doesn't explicitly state when not to use it or name alternatives (e.g., using 'get_thoughts' to review instead of clear), falling short of full explicit guidance.

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

get_thoughtsB

Retrieve all thoughts recorded in the current session to review your reasoning process.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves all thoughts, but doesn't disclose behavioral traits such as whether it returns a list or single object, pagination, rate limits, or error conditions. The description is minimal and lacks operational details.

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 a single, efficient sentence that front-loads the purpose ('Retrieve all thoughts...') and adds context ('to review your reasoning process') without waste. Every word contributes to understanding the tool's function.

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

Completeness2/5

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

Given no annotations, no output schema, and a read operation with potential complexity (retrieving 'all thoughts'), the description is incomplete. It doesn't explain return values, format, or any behavioral aspects like ordering or limits, leaving gaps for an AI 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.

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit parameters (like session context) are involved. Baseline is 4 for zero parameters.

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

Purpose4/5

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

The description clearly states the verb 'retrieve' and resource 'thoughts recorded in the current session' with the purpose 'to review your reasoning process.' It distinguishes from siblings like 'clear_thoughts' (deletion) and 'think' (creation) by focusing on retrieval, though it doesn't explicitly contrast with 'get_thought_stats' (statistics).

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

Usage Guidelines3/5

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

The description implies usage context ('current session,' 'review reasoning process') but doesn't explicitly state when to use this tool versus alternatives like 'get_thought_stats' for statistics or 'think' for creating thoughts. No exclusions or prerequisites are mentioned.

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

get_thought_statsB

Get statistics about the thoughts recorded in the current session to analyze your thinking process.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions 'statistics' and 'analyze your thinking process', which gives some behavioral context, but lacks details on what statistics are returned (e.g., counts, trends, metrics), whether it's read-only or has side effects, or any limitations (e.g., session scope). For a tool with zero annotation coverage, this is a significant gap in 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?

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and usage context. It is front-loaded with the core action ('Get statistics') and avoids unnecessary words. Every part of the sentence earns its place by adding value.

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

Completeness3/5

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

Given the tool's complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does and its context, but lacks details on behavioral aspects (e.g., what statistics are returned, any side effects) that would be needed for full understanding. Without annotations or output schema, the description should do more to compensate, but it meets a basic threshold.

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?

The tool has 0 parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description does not need to add parameter semantics, and it appropriately does not mention any. With no parameters, the baseline is 4, as there is nothing to compensate for.

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

Purpose4/5

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

The description clearly states the verb ('Get statistics') and resource ('thoughts recorded in the current session'), and specifies the purpose ('to analyze your thinking process'). It distinguishes from 'get_thoughts' (likely listing thoughts) and 'think' (likely generating thoughts), though not explicitly. It avoids tautology by providing meaningful context beyond the tool name.

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

Usage Guidelines3/5

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

The description implies usage context ('recorded in the current session') and purpose ('analyze your thinking process'), suggesting when to use this tool. However, it does not explicitly state when to use it versus alternatives like 'get_thoughts' or 'clear_thoughts', nor does it provide exclusions or prerequisites. The guidance is implied rather than explicit.

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

thinkA

Use this tool to think about something. It will not obtain new information or change anything, but just append the thought to the log. Use it when complex reasoning or cache memory is needed, especially during long chains of tool calls, policy adherence scenarios, or sequential decision making.

ParametersJSON Schema

Name	Required	Description	Default
`thought`	Yes	A thought to think about. This can be structured reasoning, step-by-step analysis, policy verification, or any other mental process that helps with problem-solving.

TDQS

A4.2/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 full burden of behavioral disclosure. It effectively describes key traits: it's a non-destructive operation ('will not... change anything'), doesn't fetch external data ('not obtain new information'), and has a logging effect ('append the thought to the log'). However, it lacks details on rate limits, authentication needs, or error handling.

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 and front-loaded, with two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value without redundancy, making it easy for an AI agent to parse quickly.

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 the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and behavioral traits adequately. However, it doesn't explain the log's format or how thoughts are stored/retrieved, which might be relevant for sibling tools like 'get_thoughts'.

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?

The schema description coverage is 100%, so the parameter 'thought' is well-documented in the schema. The description adds minimal value beyond this, mentioning 'structured reasoning, step-by-step analysis' which aligns with but doesn't significantly expand on the schema's description. Baseline 3 is appropriate given high schema coverage.

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

Purpose4/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 think about something' and 'append the thought to the log.' It specifies the verb ('think') and resource ('thought log'), but doesn't explicitly differentiate from sibling tools like 'clear_thoughts' or 'get_thoughts' beyond mentioning it 'appends' thoughts.

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 provides explicit guidance on when to use this tool: 'when complex reasoning or cache memory is needed, especially during long chains of tool calls, policy adherence scenarios, or sequential decision making.' It also clarifies when not to use it: 'It will not obtain new information or change anything,' though it doesn't name specific alternatives.

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/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: clear_thoughts resets the session, get_thoughts retrieves thoughts, get_thought_stats provides analytics, and think adds new thoughts. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern (clear_thoughts, get_thoughts, get_thought_stats, think), with 'think' being a slight exception but still fitting as a verb. The naming is predictable and readable throughout the set.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of managing a thinking process. Each tool earns its place by covering essential operations: adding, retrieving, analyzing, and clearing thoughts, without being overly sparse or bloated.

Completeness5/5

The tool set provides complete lifecycle coverage for the domain of thought management: create (think), read (get_thoughts), analyze (get_thought_stats), and delete (clear_thoughts). There are no obvious gaps, and agents can perform all necessary operations without dead ends.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

StudioMeyer Crew
io.studiomeyer
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Autonomous Agents Agent Orchestration
2
Wauldo
com.wauldo
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
Knowledge & Memory Autonomous Agents
2
Threadminder
ai.threadminder
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Knowledge & Memory Project Management
2
Taproot
com.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Knowledge & Memory Note Taking
2

Related MCP Servers

MCP Think Tool
Autonomous Agents Developer Tools
DannyMac180
A
license
Not graded
quality
D
maintenance
An MCP server that implements the 'think' tool, providing Claude with a dedicated space for structured thinking during complex problem-solving tasks to improve reasoning capabilities.
Updated a year ago (2025-04-01 02:13 UTC)
131
MIT
Think Tool MCP Server
Autonomous Agents Coding Agents
PhillipRt
A
license
A
quality
D
maintenance
Official implementation of Anthropic's 'think' tool that provides Claude with a dedicated space for structured reasoning, improving performance by up to 54% on complex tasks requiring multi-step problem solving.
Updated a year ago (2025-04-02 16:13 UTC)
1
39
126
MIT
MCP Think Tool
Autonomous Agents Developer Tools
piotrpalek
F
license
A
quality
D
maintenance
An MCP server implementation of Anthropic's Think Tool prompt engineering technique that enables Claude to break down complex problems and enhance its reasoning capabilities by providing a simple tool that echoes back thoughts.
Updated a year ago (2025-03-25 12:36 UTC)
1
2
Scratchpad MCP Server
RAG Systems Documentation Access Autonomous Agents
JoshuaOliphant
A
license
Not graded
quality
D
maintenance
Provides a 'think' tool that allows Claude and other LLMs to add dedicated thinking steps during complex tool use scenarios, creating space for structured reasoning and improving problem-solving capabilities.
Updated a year ago (2025-07-04 16:29 UTC)
MIT

Appeared in Searches

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/cgize/claude-mcp-think-tool'

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