Skip to main content
Glama
enesjakozh
marcopesani

think-mcp-server

by marcopesani
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

think-mcp-server

대장간 배지

Anthropic의 "생각" 도구 연구를 기반으로 한 최소 MCP 서버

개요

이 프로젝트는 Claude AI 모델에 "생각" 도구 기능을 제공하는 최소 메시지 제어 프로토콜(MCP) 서버를 구현합니다. 2025년 3월 20일에 발표된 Anthropic의 연구를 기반으로, 이 구현을 통해 Claude는 여러 단계의 도구 사용이 필요한 복잡한 추론 작업에서 더 나은 성능을 발휘할 수 있습니다.

Related MCP server: MCP Think Tool

"생각" 도구란 무엇인가요?

"생각하기" 도구는 클로드에게 최종 답변에 도달하는 과정에서 별도의 생각 단계를 포함할 수 있는 기능을 제공합니다. 확장된 생각(응답 생성 전에 수행되는)과는 달리, "생각하기" 도구는 클로드가 응답 생성 중에 잠시 멈춰서 진행에 필요한 모든 정보를 갖추었는지 고려할 수 있도록 합니다.

주요 이점:

  • 복잡한 문제 해결 성능을 향상시킵니다

  • 도구 사용에 대한 정책 준수를 강화합니다.

  • 의사결정의 일관성을 높입니다

  • 신중한 추론이 필요한 다단계 문제에 도움이 됩니다.

구현

이 서버는 다음 사양을 사용하여 "think" 도구를 구현합니다.

지엑스피1

"생각" 도구를 사용해야 하는 경우

Anthropic의 조사에 따르면 이 도구는 다음과 같은 경우에 가장 유용합니다.

  1. 도구 출력 분석 : Claude가 작업을 수행하기 전에 이전 도구 호출 출력을 처리해야 하는 경우

  2. 정책이 중요한 환경 : 클로드가 세부적인 지침을 따라야 할 때

  3. 순차적 의사 결정 : 각 작업이 이전 작업을 기반으로 구축되고 실수가 비용이 많이 드는 경우

구현 모범 사례

전략적 촉구

최상의 결과를 얻으려면 "생각하기" 도구를 언제 어떻게 사용해야 하는지에 대한 명확한 지침을 프롬프트에 포함하세요. 다음을 보여주는 분야별 예시를 제공하는 것도 좋습니다.

  • 추론에서 예상되는 세부 수준

  • 복잡한 지침을 단계로 나누는 방법

  • 일반적인 시나리오에 대한 의사 결정 트리

  • 정보 검증 프로세스

시스템 프롬프트 통합

복잡한 안내는 도구 설명 자체보다는 시스템 프롬프트에 넣는 것이 가장 효과적입니다.

작동 원리

서버는 Claude 및 유사한 AI 비서와 통신하기 위해 Model Context Protocol(MCP)을 사용합니다. 다음과 같은 기능을 합니다.

  • 통신을 위해 stdio를 사용하여 독립 실행형 프로세스로 실행됩니다.

  • 추론 중 클로드가 사용할 "생각" 도구를 등록합니다.

  • AI 어시스턴트가 처리할 수 있는 구조화된 응답을 반환합니다.

  • 외부 환경에 영향을 주지 않고 단계를 생각하는 로그

특징

도구

  • 생각하기 - Claude가 문제에 대해 생각하거나 정보를 분석할 수 있도록 합니다.

    • 필수: thought (Claude의 사고 과정을 담은 문자열)

개발

종속성 설치:

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

  • 윈도우: %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. Claude에게 보내는 메시지에 "생각" 도구 사용에 대한 지침을 포함하세요.

  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% 상대적 개선(통과^1 지표: 0.570 대 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