Skip to main content
Glama

think-mcp-server

A minimal MCP Server based on the Anthropic's "think" tool research

Overview

This project implements a minimal Message Control Protocol (MCP) server that provides Claude AI models with the "think" tool capability. Based on Anthropic's research published on March 20, 2025, this implementation enables Claude to perform better on complex reasoning tasks involving multi-step tool usage.

Related MCP server: MCP Think Tool

What is the "think" tool?

The "think" tool gives Claude the ability to include an additional thinking step—with its own designated space—as part of reaching a final answer. Unlike extended thinking (which happens before response generation), the "think" tool allows Claude to pause during response generation to consider whether it has all necessary information to proceed.

Key benefits:

  • Improves complex problem-solving performance

  • Enhances policy adherence in tool usage

  • Increases consistency in decision making

  • Helps with multi-step problems requiring careful reasoning

Implementation

This server implements the "think" tool with the following specification:

{
  "name": "think",
  "description": "Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.",
  "input_schema": {
    "type": "object",
    "properties": {
      "thought": {
        "type": "string",
        "description": "A thought to think about."
      }
    },
    "required": ["thought"]
  }
}

When to Use the "think" Tool

Based on Anthropic's research, this tool is most beneficial for:

  1. Tool Output Analysis: When Claude needs to process previous tool call outputs before acting

  2. Policy-Heavy Environments: When Claude must follow detailed guidelines

  3. Sequential Decision Making: When each action builds on previous ones and mistakes are costly

Implementation Best Practices

Strategic Prompting

For best results, include clear instructions in your prompts on when and how to use the "think" tool. Consider providing domain-specific examples that show:

  • Expected detail level in reasoning

  • How to break down complex instructions into steps

  • Decision trees for common scenarios

  • Information verification processes

System Prompt Integration

Complex guidance works best when placed in the system prompt rather than the tool description itself.

How It Works

The server operates using the Model Context Protocol (MCP) to communicate with Claude and similar AI assistants. It:

  • Runs as a standalone process using stdio for communication

  • Registers the "think" tool for Claude to use during reasoning

  • Returns structured responses that can be processed by AI assistants

  • Logs thinking steps without affecting the external environment

Features

Tools

  • think - Enables Claude to think about a problem or analyze information

    • Required: thought (string containing Claude's thinking process)

Development

Install dependencies:

npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Installation

Installing via Smithery

To install think-mcp-server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @marcopesani/think-mcp-server --client claude

Installing via npm

npm install -g think-mcp-server

Claude Desktop

Add the server config at:

  • MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "think": {
      "command": "npx",
      "args": ["-y", "think-mcp-server"]
    }
  }
}

Cline

  1. Open the Cline extension settings

  2. Open "MCP Servers" tab

  3. Click on "Configure MCP Servers"

  4. Add the server config:

{
  "mcpServers": {
    "github.com/marcopesani/think-mcp-server": {
      "command": "npx",
      "args": ["-y", "think-mcp-server"],
      "disabled": false,
      "autoApprove": ["think"]
    }
  }
}

Additional Cline configuration options:

  • disabled: Set to false to enable the server

  • autoApprove: List of tools that don't require explicit approval for each use

Cursor

  1. Open the Cursor settings

  2. Open "Features" settings

  3. In the "MCP Servers" section, click on "Add new MCP Server"

  4. Choose a name, and select "command" as "Type"

  5. In the "Command" field, enter the following:

npx -y think-mcp-server

Docker

You can also run the server using Docker. First, build the image:

docker build -t think-mcp-server .

Then run the container:

docker run -it think-mcp-server

For development, you might want to mount your source code as a volume:

docker run -v $(pwd):/app think-mcp-server

Getting Started

  1. Install the server using one of the methods above

  2. Configure your AI client to use the think-mcp-server

  3. In your prompts to Claude, include instructions for using the "think" tool

  4. For best results, add examples of effective thinking patterns in your system prompt

TypeScript Development Example

Here's an example prompt focused on TypeScript development to help Claude leverage the "think" tool effectively:

## Using the think tool for TypeScript Development

Before implementing any TypeScript code or responding to technical questions, use the think tool to:
- Analyze type definitions and interfaces that might be relevant
- Check for potential type errors or edge cases
- Reason through generics and type constraints
- Verify the correct usage of TypeScript features

Here's an example of TypeScript-specific reasoning with the think tool:

<think_tool_typescript_example>
User wants to implement a generic state management hook in React TypeScript
- Analysis of requirements:
  * Need to handle any data type (generic typing)
  * Must preserve type information throughout state lifecycle
  * Should provide typesafe update methods
  * Need to consider immutability patterns

- Type constraints to consider:
  * Should T extend object, or allow primitives?
  * Is Partial<T> appropriate for updates?
  * Should we use Record<string, unknown> as fallback?

- Implementation considerations:
  * useState<T> as foundation
  * Add typed setter methods that preserve generics
  * Consider callback pattern for atomic updates
  * Check for compatibility with React's rules of hooks

- Approach:
1. Define generic interface for the hook's return value
2. Implement useState with proper generic typing
3. Create typed update methods that maintain type safety
4. Add JSDoc comments for better developer experience
5. Return immutable state with properly typed methods
</think_tool_typescript_example>

When helping with TypeScript challenges:
1. First analyze the type system implications
2. Consider TypeScript-specific edge cases
3. Reason through type narrowing and widening
4. Check for compatibility with the TypeScript compiler version
5. Consider type inference and explicit type annotations

Performance Benefits

Anthropic's evaluations showed significant improvements when using the "think" tool:

  • 54% relative improvement on τ-Bench airline domain (pass^1 metric: 0.570 vs 0.370 baseline)

  • Improved performance on SWE-bench by 1.6% on average

  • Enhanced consistency across multiple trials

References

This implementation is based on Anthropic's research article "The 'think' tool: Enabling Claude to stop and think in complex tool use situations" published March 20, 2025.

Available Tools

1 tool
thinkA

Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
thoughtYesA thought to think about.

TDQS

A3.8/5.0
Behavior3/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 key behavioral traits: 'It will not obtain new information or change the database, but just append the thought to the log.' This clarifies it's a non-destructive, internal logging operation. However, it lacks details like rate limits, log format, or persistence, leaving some 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 concise and well-structured: two sentences that directly state the purpose, behavior, and usage guidelines. Every sentence adds value without redundancy, making it efficient and easy 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?

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, behavior, and usage context. However, it could benefit from more detail on the log's nature or output, but for a simple tool, this is adequate.

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 schema already documents the single parameter 'thought' with its description. The description doesn't add any meaning beyond this, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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: 'Use the tool to think about something' and 'append the thought to the log'. It specifies the verb ('think') and resource ('thought'), though it's somewhat abstract. Since there are no sibling tools, differentiation isn't needed, making this clear but not highly specific.

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 explicit usage guidance: 'Use it when complex reasoning or some cache memory is needed.' This gives clear context for when to invoke the tool. However, it doesn't mention when not to use it or alternatives, and with no siblings, this is less critical.

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

TDQS

A3.6/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'think' has a clearly defined and distinct purpose: to append thoughts to a log for reasoning or memory caching.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'think' is simple and descriptive, fitting the server's purpose without any conflicting patterns.

Tool Count2/5

One tool is too few for most practical server purposes, as it severely limits functionality and scope. While the tool's description suggests it's for reasoning and memory caching, a single tool feels thin and inadequate for handling complex tasks or interactions.

Completeness1/5

The server is severely incomplete, as it lacks any tools for obtaining information, changing data, or performing actions beyond logging thoughts. This creates significant gaps that will cause agent failures in real-world scenarios, as the tool surface does not support meaningful workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • 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.
    131
    MIT
  • 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.
    1
    2
  • A
    license
    B
    quality
    F
    maintenance
    An MCP server that provides a "think" tool enabling structured reasoning for AI agents, allowing them to pause and record explicit thoughts during complex tasks or multi-step tool use.
    1
    106
    MIT

Latest Blog Posts

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/marcopesani/think-mcp-server'

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