Skip to main content
Glama
enesjakozh
marcopesani

think-mcp-server

by marcopesani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

think-mcp-server

鍛冶屋のバッジ

Anthropicの「think」ツール研究に基づいた最小限のMCPサーバー

概要

このプロジェクトは、Claude AIモデルに「考える」ツール機能を提供する最小限のメッセージ制御プロトコル（MCP）サーバーを実装します。2025年3月20日に公開されたAnthropicの調査結果によると、この実装により、Claudeは複数段階のツール使用を伴う複雑な推論タスクにおいて、より優れたパフォーマンスを発揮できるようになります。

Related MCP server: MCP Think Tool

「考える」ツールとは何ですか?

「考える」ツールは、クロードに最終的な答えに至る過程において、専用のスペースを設けた追加の思考ステップを組み込む能力を与えます。（回答を生成する前に行われる）拡張思考とは異なり、「考える」ツールは、クロードが回答生成中に一時停止し、先に進むために必要な情報がすべて揃っているかどうかを検討することを可能にします。

主な利点:

  • 複雑な問題解決能力を向上

  • ツールの使用におけるポリシー遵守を強化

  • 意思決定の一貫性を高める

  • 慎重な推論を必要とする多段階の問題の解決に役立ちます

実装

このサーバーは、次の仕様で「think」ツールを実装します。

{
  "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"]
  }
}

「考える」ツールを使うべき時

Anthropic の調査によると、このツールは次のような場合に最も効果的です。

  1. ツール出力分析: クロードが行動を起こす前に以前のツール呼び出し出力を処理する必要がある場合

  2. ポリシー重視の環境: クロードが詳細なガイドラインに従わなければならない場合

  3. 逐次的な意思決定：各アクションが前のアクションに基づいており、間違いが大きなコストをもたらす場合

実装のベストプラクティス

戦略的プロンプト

最良の結果を得るには、「考える」ツールをいつ、どのように使用するかについて、明確な指示をプロンプトに含めることをお勧めします。以下の点を示す分野固有の例を挙げることを検討してください。

  • 推論における期待される詳細レベル

  • 複雑な指示をステップに分解する方法

  • 一般的なシナリオの決定木

  • 情報検証プロセス

システムプロンプト統合

複雑なガイダンスは、ツールの説明自体ではなく、システム プロンプトに配置すると最も効果的です。

仕組み

サーバーは、モデルコンテキストプロトコル（MCP）を使用して、ClaudeなどのAIアシスタントと通信します。MCPは以下の機能を提供します。

  • 通信にstdioを使用してスタンドアロンプロセスとして実行されます

  • クロードが推論中に使用できる「考える」ツールを登録します

  • AIアシスタントが処理できる構造化された応答を返す

  • 外部環境に影響を与えずに思考ステップを記録する

特徴

ツール

  • 考える- クロードが問題について考えたり、情報を分析したりできるようにする

    • 必須: thought (クロードの思考プロセスを含む文字列)

発達

依存関係をインストールします:

npm install

サーバーを構築します。

npm run build

自動リビルドを使用した開発の場合:

npm run watch

デバッグ

MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。MCP Inspectorの使用をお勧めします。

npm run inspector

インスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。

インストール

npm経由でインストール

npm install -g think-mcp-server

クロードデスクトップ

次の場所にサーバー設定を追加します:

  • 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"]
    }
  }
}

クライン

  1. Cline拡張機能の設定を開く

  2. 「MCPサーバー」タブを開く

  3. 「MCPサーバーの構成」をクリックします

  4. サーバー設定を追加します:

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

追加のCline構成オプション:

  • disabled : サーバーを有効にするには false に設定します

  • autoApprove : 使用ごとに明示的な承認を必要としないツールのリスト

カーソル

  1. カーソル設定を開く

  2. 「機能」設定を開く

  3. 「MCPサーバー」セクションで、「新しいMCPサーバーを追加」をクリックします。

  4. 名前を選択し、「タイプ」として「コマンド」を選択します

  5. 「コマンド」フィールドに次のように入力します。

npx -y think-mcp-server

ドッカー

Dockerを使ってサーバーを実行することもできます。まずはイメージをビルドします。

docker build -t think-mcp-server .

次にコンテナを実行します。

docker run -it think-mcp-server

開発の場合、ソース コードをボリュームとしてマウントする必要がある場合があります。

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

はじめる

  1. 上記のいずれかの方法でサーバーをインストールします

  2. think-mcp-server を使用するように AI クライアントを構成する

  3. クロードへのプロンプトには、「考える」ツールの使い方の説明を含めてください

  4. 最良の結果を得るには、システムプロンプトに効果的な思考パターンの例を追加します。

TypeScript開発例

以下は、Claude が「think」ツールを効果的に活用できるようにするための、TypeScript 開発に焦点を当てたプロンプトの例です。

## 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

パフォーマンス上の利点

Anthropic の評価では、「think」ツールの使用により大幅な改善が見られました。

  • τ-Bench エアラインドメインで 54% の相対改善 (pass^1 メトリック: 0.570 vs 0.370 ベースライン)

  • SWEベンチでのパフォーマンスが平均1.6%向上

  • 複数の試験にわたる一貫性の向上

参考文献

この実装は、2025 年 3 月 20 日に公開された Anthropic の研究記事「 「考える」ツール: 複雑なツール使用状況でクロードが立ち止まって考えることを可能にする」に基づいています。

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.9/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 will not obtain new information or change the database' clarifies it's a read-only, non-destructive operation, and 'just append the thought to the log' explains the action. This covers safety and basic behavior, though it could add details like log format or persistence.

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 appropriately sized with two sentences that efficiently convey purpose and usage. It is front-loaded with the core action and avoids unnecessary details. Every sentence adds value, though minor improvements in clarity could enhance conciseness further.

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 annotations, no output schema), the description is reasonably complete. It covers purpose, usage, and behavioral traits adequately. However, it could be more specific about what 'think' involves or the log's nature, which would improve completeness for an agent's understanding.

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 input schema has 100% description coverage, with the 'thought' parameter documented as 'A thought to think about.' The description adds no additional parameter semantics beyond this, such as format or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema already provides adequate parameter information.

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 log'), though it doesn't distinguish from siblings since none exist. The purpose is clear but could be more specific about what 'think' entails operationally.

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 guidance on when to use the tool: 'Use it when complex reasoning or some cache memory is needed.' This gives clear context for its application. However, it lacks exclusions or alternatives, which is acceptable since no sibling tools are present to differentiate from.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • First observedthink
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 1 tool

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

Related MCP Connectors

Related MCP Servers

  • MCP Think Tool

    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.
    130
    MIT

  • MCP Think Tool

    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.
    1
    2
    -

  • Think MCP Tool

    Rai220
    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
    107
    MIT

Appeared in Searches