thinking
Structured problem-solving session with persistent investigation memory across tool calls.
DESCRIPTION
This tool is not a code reader. It is a reasoning layer for complex debugging, multi-step investigations, and high-risk changes where you need to track what you checked, what you concluded, and what to do next.
WHEN TO USE
GOOD FIT
- Debugging a hard issue across multiple files or services.
- Before high-risk changes like auth refactors or billing logic edits.
- When an attempted fix failed and you need a structured re-evaluation.
- During long sessions where context drift is likely.
AVOID IT WHEN
- The task is straightforward and you can go directly to scope_task or read_code.
- You only need to read code, not manage an investigation.
- You do not intend to carry context across multiple steps.
PARAMETERS
| Name | Type | Required | Description |
|---|---|---|---|
| operation | "generate" | "cleanup" | Yes | Creates a new reasoning session or clears expired ones. |
| task_description | string | No | Problem statement when generating a new session. |
| project_path | string | No | Project root to anchor the session context. |
EXAMPLE
tools-call.json
{ "jsonrpc": "2.0", "id": 10, "method": "tools/call", "params": { "name": "thinking", "arguments": { "operation": "generate", "task_description": "Investigate intermittent unauthorized responses on the MCP endpoint", "project_path": "/workspace/repo" } }}OUTPUT
response.json
{ "jsonrpc": "2.0", "id": 10, "result": { "content": [ { "type": "text", "text": "Session created\nVerified state: auth failures appear after key rotation\nInvestigation plan: inspect key validation, cache invalidation, retry behavior\nRecommended next tool: read_code" } ] }}TOKEN EFFICIENCY
Thinking spends tokens intentionally to reduce rework. It is most useful when losing context would cost more than the session overhead.