How do I use Thinking Patterns MCP 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., "@Thinking Patterns MCP Server Use sequential thinking to analyze the root cause of the server outage." 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.

Thinking Patterns MCP Server

by emmahyde

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Thinking Patterns MCP Server

NPM Version

TL;DR

A comprehensive MCP server that provides AI systems with structured thinking frameworks that follow existing problem-solving paradigms. Transform abstract cognitive patterns into concrete, invocable tools. Enforces adherence to the paradigms through schema validation.

Related MCP server: Clear Thought Server

📚 Documentation

Quick Start - Get up and running in 2 minutes
TOOL_REFERENCE.md - Complete tool specifications and parameters
EXAMPLES.md - Detailed usage examples and patterns
SUMMARY.md - Executive summary and overview
SYSTEM_INTENT.md - System purpose and philosophy
TECHNICAL_ARCHITECTURE.md - Technical implementation details

Problem

LLMs struggle to maintain consistent reasoning patterns throughout extended conversations due to context window limitations and degrading adherence to initial instructions. Traditional approaches like "keep X in mind" or role-based prompting fail when:

Critical context passes out of the attention window
Models acknowledge constraints but don't consistently apply them
Reasoning structures decay over multi-turn interactions

thinking-patterns enforces structural consistency through interactive schema validation rather than passive instruction-following.

Solution

thinking-patterns works by implicitly encouraging good engineering behaviors and approaches:

Schema validation ensures reasoning patterns persist beyond context window limits
Structural requirements live in tool definitions rather than repeated prompt text, reducing token overhead
Tool interaction success/failure provides objective metrics for reasoning quality
- Indicates to the model that they are not following the pattern appropriately without additional user interaction
Reusable thinking structures across different problem domains

Reasoning Improvements

Attention Drift Prevention: Without structural anchors, models experience "goal drift" as new contextual information competes with original objectives. Schema validation creates persistent attention anchors.
State Crystallization: Explicit articulation of reasoning state (forced by tool parameters) appears to strengthen internal representation compared to implicit state maintenance. Models demonstrate measurably better state consistency when reasoning is externalized.
Error-Driven Learning: Schema validation errors create immediate, interactive corrective feedback loops within a single response, unlike instruction-based approaches where non-compliance often goes undetected until task completion.
Cognitive Load Distribution: Externalizing structural requirements to schemas allows models to allocate more processing capacity to problem-solving rather than format compliance, similar to how humans benefit from external memory aids.
Iterative Reinforcement: Repeated successful tool interactions strengthen adherence patterns through practice, creating compound consistency benefits over conversation length.

🚀 Quick Start

1. Install (Choose One)

Recommended: Smithery (for Cursor users)

npx -y @smithery/cli install @emmahyde/thinking-patterns --client cursor

NPM

npm install @emmahyde/thinking-patterns

NPX (no installation)

npx -y @emmahyde/thinking-patterns

2. Configure MCP Client

Add to your MCP client configuration:

{
  "mcpServers": {
    "thinking-patterns": {
      "command": "npx",
      "args": ["-y", "@emmahyde/thinking-patterns"]
    }
  }
}

3. Try Your First Tool

# Example: Use sequential thinking for planning
{
  "tool": "sequential_thinking",
  "arguments": {
    "thought": "Plan a product launch strategy",
    "thoughtNumber": 1,
    "totalThoughts": 5
  }
}

🧠 Available Thinking Tools

Core Systematic Thinking

sequential_thinking - Multi-step reasoning with revision support
problem_decomposition - Break complex problems into manageable parts
recursive_thinking - Apply recursive strategies to self-similar problems

Mental Models & Frameworks

mental_model - Apply proven frameworks (First Principles, Inversion, etc.)
decision_framework - Multi-criteria decision analysis
domain_modeling - Create conceptual models of problem domains

Scientific & Critical Analysis

scientific_method - Formal hypothesis testing and experimentation
critical_thinking - Systematic evaluation of arguments and assumptions
debugging_approach - Systematic troubleshooting methodologies

Collaborative & Dialectical

collaborative_reasoning - Multi-perspective problem solving with personas
structured_argumentation - Dialectical reasoning and argument analysis

Advanced Cognitive Patterns

metacognitive_monitoring - Self-assessment of reasoning quality
visual_reasoning - Diagram-based thinking and spatial reasoning
temporal_thinking - Time-based system analysis with state transitions

Probabilistic & Optimization

stochastic_algorithm - Decision-making under uncertainty [BETA]
- Markov Decision Processes (MDPs)
- Monte Carlo Tree Search (MCTS)
- Multi-Armed Bandit algorithms
- Bayesian Optimization
- Hidden Markov Models (HMMs)

💡 Recommended Starting Points

sequential_thinking & problem_decomposition - Perfect for planning and breaking down complex tasks
debugging_approach - Send error messages directly for systematic troubleshooting
collaborative_reasoning - Simulate team discussions to uncover blind spots

📋 Prerequisites

Node.js 18+ (for local installation)
MCP-compatible client (Claude, Cursor, etc.)
Optional: Docker for containerized deployment

🔧 Installation Options

Option 1: Smithery (Recommended for Cursor)

Automatically configures MCP client:

npx -y @smithery/cli install @emmahyde/thinking-patterns --client cursor

Option 2: NPM Package

For local development:

npm install @emmahyde/thinking-patterns

Option 3: NPX (Zero Installation)

Run without installing:

npx -y @emmahyde/thinking-patterns

Option 4: Docker

# Build image
docker build -t thinking-patterns .

# Run container
docker run -it thinking-patterns

Option 5: Development Setup

git clone https://github.com/emmahyde/thinking-patterns
cd thinking-patterns
npm install
npm run build
npm start

🎯 Use Cases

Software Development

Debug production issues systematically
Decompose complex features into user stories
Review code with multiple perspectives
Plan architecture changes step-by-step

Business Strategy

Make data-driven decisions with frameworks
Apply mental models to strategic planning
Model business processes over time
Optimize resource allocation

Research & Analysis

Test hypotheses with scientific method
Evaluate arguments critically
Model new domains systematically
Analyze temporal patterns

Creative Problem Solving

Use visual reasoning for design challenges
Apply recursive thinking to complex patterns
Optimize solutions with probabilistic algorithms
Generate innovative solutions with mental models

🔗 Integration Examples

`npx`

{
  "mcpServers": {
    "thinking-patterns": {
      "command": "npx",
      "args": ["-y", "@emmahyde/thinking-patterns"]
    }
  }
}

Local Development

{
  "mcpServers": {
    "thinking-patterns": {
      "command": "node",
      "args": ["/path/to/thinking-patterns/dist/index.js"]
    }
  }
}

📊 Tool Categories

Category	Tools	Best For
Systematic	sequential_thinking, problem_decomposition, recursive_thinking	Planning, breaking down complexity
Mental Models	mental_model, decision_framework, domain_modeling	Strategic thinking, decision making
Scientific	scientific_method, critical_thinking, debugging_approach	Analysis, troubleshooting, validation
Collaborative	collaborative_reasoning, structured_argumentation	Team thinking, debate, consensus
Advanced	metacognitive_monitoring, visual_reasoning, temporal_thinking	Self-reflection, design, process modeling
Probabilistic	stochastic_algorithm	Optimization, uncertainty, ML/AI

🤝 Contributing

Contributions welcome! Please see our Contributing Guide for details.

📄 License

MIT License - see LICENSE for details.

🙏 Acknowledgments

Built on the Model Context Protocol (MCP) by Anthropic
Mental Models framework inspired by cognitive science research
Stochastic algorithms based on reinforcement learning and decision theory

📞 Support

📖 Tool Reference - Complete API documentation
💡 Examples Guide - Usage examples and patterns
🐛 Report Issues
💬 Discussions

Give an AI thinking patterns, and it can solve any problem systematically.

Available Tools

15 tools

collaborative_reasoningC

Multi-perspective collaborative problem solving with diverse personas and structured contributions.

ParametersJSON Schema

Name	Required	Description
`stage`	Yes	The current stage of the collaborative reasoning process, guiding the nature of contributions.
`topic`	Yes	The central topic or problem being addressed in the collaborative session.
`personas`	Yes	The set of diverse personas participating in the reasoning process.
`iteration`	Yes	The turn number or iteration of the session, for tracking progress.
`sessionId`	Yes	A unique identifier for this collaborative reasoning session.
`keyInsights`	No	A list of significant insights that have emerged from the discussion.
`contributions`	Yes	A log of all contributions made during the session.
`disagreements`	No	A list of active or resolved disagreements that have occurred.
`nextPersonaId`	No	The ID of the persona designated to contribute next, guiding the conversation flow.
`openQuestions`	No	A list of unresolved questions that require further discussion or information.
`activePersonaId`	Yes	The ID of the persona who is currently expected to contribute.
`consensusPoints`	No	A list of key points or decisions on which all personas have reached agreement.
`finalRecommendation`	No	The final, synthesized recommendation or decision resulting from the session.
`nextContributionNeeded`	Yes	A flag indicating whether the session is awaiting another contribution to proceed.
`suggestedContributionTypes`	No	A list of suggested types for the next contribution to guide the active persona.

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, so the description is solely responsible for behavioral disclosure. It does not mention that the tool is iterative, stateful (using sessionId, iteration), or how it processes contributions. The description only gives a high-level characterization.

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 a single sentence with no superfluous content. It is concise and front-loaded with key terms, but could be slightly expanded for clarity.

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 the tool's complexity (15 parameters, nested structures, no output schema), the one-sentence description is insufficient. It fails to explain the collaborative process, the role of stages, or the expected return value, leaving significant gaps.

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?

Schema coverage is 100%, so the schema already documents all 15 parameters. The description does not add any additional meaning or examples beyond what the schema provides, thus meeting the baseline but not exceeding it.

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

Purpose3/5

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

The description states the tool is for 'multi-perspective collaborative problem solving with diverse personas and structured contributions', which indicates its purpose but is vague and does not distinguish it from sibling tools like 'structured_argumentation' or 'critical_thinking'.

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

Usage Guidelines1/5

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

No guidance is provided on when to use this tool over alternatives, nor any conditions or exclusions. The description lacks any usage context.

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

critical_thinkingC

Systematic evaluation of arguments, assumptions, and potential issues to improve reasoning quality.

ParametersJSON Schema

Name	Required	Description
`context`	No	The broader context or background relevant to the analysis.
`subject`	Yes	The code, design, requirement, or concept being critically analyzed.
`edgeCases`	Yes	A structured list of edge cases that might not be handled correctly.
`nextSteps`	No	Suggested next steps for addressing the findings.
`reviewers`	No	List of people who reviewed or contributed to this analysis.
`timeSpent`	No	Time spent on this analysis (e.g., '2 hours').
`analysisId`	No	A unique identifier for this critical thinking session.
`objectives`	No	The specific objectives or goals of this critical analysis.
`methodology`	No	The approach or framework used for the critical analysis.
`analysisDepth`	No	The depth level of the critical analysis performed.
`confidenceLevel`	No	Overall confidence (0-1) in the completeness of this analysis.
`potentialIssues`	Yes	A structured list of potential issues or flaws identified.
`followUpQuestions`	No	Questions that arose during analysis and need further investigation.
`overallAssessment`	No	An overall assessment or summary of the critical analysis.
`invalidAssumptions`	Yes	A structured list of assumptions that may be invalid or questionable.
`alternativeApproaches`	Yes	A structured list of alternative approaches or solutions.
`prioritizedRecommendations`	No	Prioritized list of recommendations based on the analysis.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose any behavioral traits (e.g., whether the tool stores or retrieves data, side effects, or required permissions). It is too abstract to inform safe invocation.

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 a single sentence of 12 words, which is concise. However, it could be expanded slightly to include more context without losing efficiency.

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 the tool's complexity (17 parameters, no output schema), the description is insufficient. It does not explain what the tool returns or how the structured outputs are used, leaving the agent without critical context.

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 covers all 17 parameters with descriptions (100%), so the baseline is 3. The description adds no additional meaning beyond the schema.

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 function: systematic evaluation of arguments, assumptions, and issues to improve reasoning. It uses specific nouns and verbs, though it does not differentiate from sibling tools.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'structured_argumentation' or 'debugging_approach'. No exclusions or context are mentioned.

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

debugging_approachC

Systematic debugging methodologies for troubleshooting and problem resolution.

ParametersJSON Schema

Name	Required	Description
`issue`	Yes	A detailed and specific description of the problem, including observed vs. expected behavior, and steps to reproduce if known.
`steps`	No	Debugging steps taken, either as simple strings or detailed step objects.
`tools`	No	Tools and technologies used during debugging.
`method`	No	Detailed information about the debugging method being used.
`endTime`	No	When the debugging session ended.
`evidence`	No	Evidence collected during the debugging process.
`findings`	No	The key observations, data points, or discoveries made during the debugging process.
`sessionId`	No	Unique identifier for this debugging session.
`startTime`	No	When the debugging session started.
`aiAnalysis`	No	AI-powered analysis results for enhanced debugging capabilities.
`hypotheses`	No	Hypotheses about potential causes of the issue.
`resolution`	No	A clear explanation of the final fix, including any code changes, configuration updates, or other actions taken.
`approachName`	Yes	The name of the systematic debugging method being applied (e.g., 'Log Analysis', 'Delta Debugging', 'Root Cause Analysis').
`participants`	No	People involved in the debugging process.
`documentation`	No	Documentation of the debugging process and resolution.
`effectiveness`	No	Metrics for evaluating the effectiveness of the debugging approach.
`totalDuration`	No	Total time spent debugging.
`classification`	No	Structured classification of the issue.
`lessonsLearned`	No	Key lessons learned from this debugging session.
`preventionMeasures`	No	Measures to prevent similar issues in the future.

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are present, so the description must convey behavioral traits. It does not mention that the tool likely creates/updates a debugging session, nor does it disclose side effects, required permissions, or whether it is read-only or write. The agent gets no insight into tool impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it lacks substance. It prioritizes brevity over informativeness. The structure is front-loaded with the purpose, but the content is too vague to be effective.

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 the tool has 20 parameters, nested objects, no output schema, and many siblings, the description is far too minimal. It does not explain the tool's role in the debugging workflow, what it returns, or how it complements related tools. The agent is left guessing about its integration.

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?

Schema description coverage is 100% with detailed parameter descriptions. The tool description adds no additional meaning beyond the schema. Baseline score of 3 applies as the description neither enhances nor detracts from parameter understanding.

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

Purpose3/5

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

The description 'Systematic debugging methodologies for troubleshooting and problem resolution' is generic. It indicates a debugging focus but lacks a specific verb or resource to distinguish what the tool actually does (e.g., record, apply, guide). Among sibling tools like scientific_method or decision_framework, the purpose is not well differentiated.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not state prerequisites, typical scenarios, or when not to use it. For a tool with many siblings, this omission reduces clarity.

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

decision_frameworkC

Structured decision analysis and rational choice frameworks for complex decisions.

ParametersJSON Schema

Name	Required	Description
`stage`	Yes	The current stage of the decision-making process.
`options`	Yes	A list of the options being considered.
`criteria`	No	A list of the criteria used to evaluate the options.
`iteration`	Yes	The iteration number of this decision-making process.
`decisionId`	Yes	A unique identifier for this decision.
`constraints`	No	A list of constraints on the decision.
`timeHorizon`	No	The time horizon for the decision.
`analysisType`	Yes	The type of analysis to be performed.
`stakeholders`	No	A list of stakeholders involved in the decision.
`riskTolerance`	No	The risk tolerance for the decision.
`expectedValues`	No	A record of the expected values for each option.
`recommendation`	No	The final recommendation.
`informationGaps`	No	A list of information gaps that need to be filled.
`nextStageNeeded`	Yes	A flag indicating whether another stage is needed.
`possibleOutcomes`	No	A list of possible outcomes for the decision.
`decisionStatement`	Yes	A clear and concise statement of the decision to be made.
`suggestedNextStage`	No	The suggested next stage in the decision-making process.
`criteriaEvaluations`	No	A list of evaluations of the options against the criteria.
`multiCriteriaScores`	No	A record of the multi-criteria scores for each option.
`sensitivityInsights`	No	A list of insights from sensitivity analysis.

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, state modifications, idempotency, or permission requirements. For a tool with 20 parameters and a multi-stage process, this is a critical omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but insufficiently informative. It lacks structure, front-loading, and does not highlight key aspects like stages or required inputs. Under-specification rather than efficient communication.

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

Completeness1/5

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

Given the tool's complexity (20 parameters, 7 required, nested objects, no output schema), the one-sentence description is wholly inadequate. It does not explain the workflow, iteration, stage transitions, or how to fill the required fields, leaving the agent without essential context.

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?

Schema description coverage is 100%, so each parameter is documented in the schema. The tool description adds no additional parameter context beyond what the schema provides, meeting the baseline for this dimension.

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

Purpose3/5

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

The description 'Structured decision analysis and rational choice frameworks for complex decisions' conveys the domain but is vague about specific actions. It distinguishes from sibling tools like 'structured_argumentation' by focusing on decision analysis, but lacks a clear verb-resource pairing such as 'evaluate options' or 'guide stages'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. It does not specify prerequisites, when not to use, or how it complements sibling tools like 'critical_thinking' or 'sequential_thinking'. The description offers no context for selection.

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

domain_modelingB

Creating and refining conceptual models of a domain, including entities, relationships, and rules.

ParametersJSON Schema

Name	Required	Description
`stage`	Yes	The current stage of the modeling process.
`entities`	Yes	A list of all entities in the domain.
`paradigm`	Yes	The modeling paradigm used.
`useCases`	No	A list of use cases for the domain.
`iteration`	Yes	The iteration number of this modeling session.
`boundaries`	No	The bounded context of the domain.
`domainName`	Yes	The name of the domain being modeled.
`modelingId`	Yes	A unique identifier for this modeling session.
`assumptions`	No	A list of assumptions made during the modeling process.
`description`	Yes	A detailed description of the domain.
`domainRules`	No	A list of all domain rules.
`stakeholders`	No	A list of stakeholders involved in the modeling process.
`modelingNotes`	No	A list of notes related to the modeling process.
`relationships`	No	A list of all relationships between entities.
`modelValidation`	No	Validation results for the model.
`nextStageNeeded`	Yes	A flag indicating whether another modeling stage is required.
`abstractionLevel`	Yes	The level of abstraction of the model.
`suggestedNextStage`	No	The suggested next stage in the modeling process.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the tool mutates state, persists, or requires authentication. It merely defines the modeling action without revealing side effects or limitations.

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 extremely concise: one sentence that clearly communicates the core purpose. It front-loads the action and key concepts with no wasted words.

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 the tool's complexity (18 parameters, nested objects, no output schema), the description is too brief. It fails to explain the modeling stages, process flow, or what the tool returns, making it incomplete for effective use.

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?

Schema coverage is 100%, so all parameters are documented. The description mentions 'entities, relationships, and rules' which correspond to schema fields, but adds no extra meaning. Baseline 3 is appropriate since the schema already does the work.

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

Purpose5/5

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

The description clearly states it is for 'creating and refining conceptual models of a domain, including entities, relationships, and rules.' This specific verb+resource combination distinguishes it from sibling tools like 'collaborative_reasoning' or 'problem_decomposition' which are general reasoning approaches.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It lacks explicit context, prerequisites, or when-not-to-use instructions. The description only states the tool's function without any usage pointers.

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

mental_modelD

Tool for creating and analyzing mental models to understand complex problems and systems.

ParametersJSON Schema

Name	Required	Description
`steps`	No	A sequential, logical breakdown of how the mental model is applied. Each step should be a clear action or point of analysis, demonstrating the model's framework.
`problem`	Yes	A clear, specific, and bounded description of the problem being analyzed. A good problem statement is crucial for effective model application. For example, 'How can we reduce user friction in our onboarding flow?' is better than 'Make the app better'.
`modelName`	Yes	The name of the mental model being used (e.g., 'Second-Order Thinking', 'First Principles'). This helps categorize the analysis.
`reasoning`	No	The core logic behind the analysis. Explain why this model is appropriate for this problem and how the steps connect to the model's principles. This is crucial for evaluating the application's quality.
`conclusion`	No	The final, actionable insight or decision. It should be a direct synthesis of the preceding steps and reasoning.

TDQS

D1.9/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or limitations. It merely restates the tool's purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It does not elaborate on key aspects like how to use or what to expect, making it underspecified.

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

Completeness1/5

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

With 5 parameters, no output schema, and no behavioral annotations, the description is too brief to provide complete context. It fails to explain return values or usage context.

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?

Schema description coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

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

Purpose3/5

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

The description states 'creating and analyzing mental models', which is specific but does not differentiate from sibling tools like 'critical_thinking' or 'problem_decomposition' that also involve analytical frameworks.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. The description lacks context for appropriate usage or prerequisites.

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

metacognitive_monitoringD

Self-assessment of knowledge and reasoning quality for improved metacognition.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	The overall task or problem being addressed.
`stage`	Yes	The current stage of the metacognitive process.
`claims`	No	A list of claims being made and assessed.
`iteration`	Yes	The iteration number of this monitoring session.
`monitoringId`	Yes	A unique identifier for this monitoring session.
`previousSteps`	No	A record of the steps that have already been completed.
`reasoningSteps`	No	A list of reasoning steps being assessed.
`remainingSteps`	No	A high-level list of the steps that are yet to be taken.
`toolUsageHistory`	No	A log of the tools that have been used so far, along with their effectiveness.
`uncertaintyAreas`	Yes	A list of areas where there is significant uncertainty.
`overallConfidence`	Yes	An overall confidence score (0-1) in the ability to complete the task successfully.
`knowledgeAssessment`	No	An assessment of the knowledge required for the task.
`recommendedApproach`	Yes	The recommended approach to address the task, given the metacognitive assessment.
`nextAssessmentNeeded`	Yes	A flag indicating whether another assessment is required.
`suggestedAssessments`	No	A list of suggested next assessments.

TDQS

D1.9/5.0

Behavior1/5

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

No annotations are present, so the description carries the full burden. The single sentence does not disclose any behavioral traits such as side effects, authorization requirements, or state changes. The schema hints at introspection, but the description adds no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) but is under-specified. For a tool with 15 parameters and nested objects, more detail is required. It is not appropriately sized and fails to front-load key information.

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

Completeness1/5

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

Given the complexity (15 parameters, nested objects, no output schema), the description is woefully incomplete. It provides no overview of the tool's behavior, usage context, or relationship to the detailed schema. The completeness is inadequate.

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?

Schema description coverage is 100%, so baseline is 3. The description does not add any meaning beyond the parameter schemas; it completely ignores the parameters. Since the schema already documents each parameter thoroughly, a score of 3 is appropriate.

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

Purpose3/5

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

The description states it is for 'self-assessment of knowledge and reasoning quality', which gives a general purpose. However, it lacks a specific action verb (e.g., 'perform', 'conduct') and does not differentiate from siblings like 'critical_thinking' or 'decision_framework'. The purpose is clear but vague.

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

Usage Guidelines1/5

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

No usage guidelines are provided. The description does not indicate when to use this tool versus any of the 14 sibling tools, nor does it mention when not to use it or what alternatives exist.

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

problem_decompositionC

Breaking down complex problems into manageable sub-problems and tasks.

ParametersJSON Schema

Name	Required	Description
`scope`	No	The scope and boundaries of this problem decomposition.
`metrics`	No	Metrics and analysis of the decomposition.
`problem`	Yes	A clear and comprehensive description of the problem to be decomposed.
`version`	No	Version of this decomposition.
`createdBy`	No	Who created this decomposition.
`objectives`	No	The main objectives to be achieved through this decomposition.
`createdDate`	No	When this decomposition was created.
`methodology`	No	The methodology or approach used for decomposition (e.g., 'Work Breakdown Structure', 'Feature-driven').
`reviewNotes`	No	Notes from reviews of this decomposition.
`lastModified`	No	When this decomposition was last modified.
`decomposition`	Yes	A hierarchical list of tasks that the problem is decomposed into.
`decompositionId`	Yes	A unique identifier for this decomposition session.
`completenessCheck`	No	Checklist items to verify completeness of the decomposition.
`alternativeApproaches`	No	Alternative ways the problem could have been decomposed.

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are present, and the description fails to disclose behavioral traits such as side effects, persistence, or prerequisites. The agent is left unaware of important details like whether this tool creates, reads, or modifies data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence), but it lacks necessary detail for a complex tool with 14 parameters and nested objects. It is under-specified rather than efficiently concise.

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 the tool's complexity (14 parameters, nested objects, no output schema) and many sibling tools, the description is grossly inadequate. It does not explain the decomposition structure, task hierarchy, or how to interpret the input, leading to high risk of misuse.

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?

Schema coverage is 100%, with all 14 parameters having descriptions. The tool description adds no parameter-specific information beyond what the schema already provides, so the baseline score of 3 applies.

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

Purpose3/5

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

The description states a clear purpose: breaking down complex problems into sub-problems and tasks. However, it is generic and does not differentiate from sibling tools like 'recursive_thinking' or 'structured_argumentation', which also involve decomposition. The verb phrase is present but lacks specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools focused on reasoning and problem-solving, the description offers no context about appropriate scenarios or when to avoid this tool.

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

recursive_thinkingC

Applying recursive strategies to solve problems with base and recursive cases, including optimizations.

ParametersJSON Schema

Name	Required	Description
`domain`	No	The domain or field this problem belongs to (e.g., 'algorithms', 'data structures').
`problem`	Yes	A clear and comprehensive description of the problem to be solved recursively.
`baseCases`	Yes	The base cases that terminate the recursion.
`problemId`	No	A unique identifier for this recursive problem analysis.
`testCases`	No	Key test cases for validating the recursive solution.
`invariants`	No	Properties that remain true throughout the recursive calls.
`optimizations`	No	Possible optimizations for the recursive solution.
`commonMistakes`	No	Common mistakes when implementing this recursive solution.
`inputSizeLimit`	No	Practical limit on input size before stack overflow.
`recursiveCases`	Yes	The recursive cases that break down the problem.
`similarProblems`	No	Other problems that use similar recursive patterns.
`recursionPattern`	No	The pattern of recursion used.
`stackOverflowRisk`	No	Risk of stack overflow for typical inputs.
`complexityAnalysis`	No	Detailed complexity analysis of the recursive solution.
`learningObjectives`	No	What can be learned from this recursive analysis.
`iterativeAlternatives`	No	Alternative iterative solutions.
`terminationConditions`	Yes	All conditions under which the recursion will terminate.
`tailRecursionOptimizable`	No	Whether the recursion can be optimized with tail recursion.

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It only says 'applying recursive strategies' and mentions optimizations, but does not explain what the tool actually does (e.g., mutate state, return analysis, require specific permissions) or any side effects or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is not verbose, but it lacks substance and does not earn its place by providing necessary information. It is underspecified rather than concise.

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 the complex input schema (18 parameters, nested objects) and no output schema, the description should explain how the tool processes inputs and what it returns. It only gives a high-level purpose, leaving significant gaps in 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?

Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds no additional meaning beyond the schema, which is acceptable at baseline 3.

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

Purpose3/5

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

The description states it applies recursive strategies to solve problems with base and recursive cases, including optimizations. This gives a general sense but lacks specifics about what the tool does (e.g., analyze, generate, or solve) and does not differentiate from sibling tools like sequential_thinking or problem_decomposition.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as collaborative_reasoning or critical_thinking. The description does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

scientific_methodC

Formal hypothesis testing and experimentation following the scientific method.

ParametersJSON Schema

Name	Required	Description
`stage`	Yes	The current stage in the scientific inquiry process.
`analysis`	No	The interpretation of the experimental results and statistical analysis.
`question`	No	A specific question that arises from the observation (e.g., 'Why is user engagement low?').
`inquiryId`	Yes	A unique identifier for the entire scientific inquiry from observation to conclusion.
`iteration`	Yes	The iteration number of the inquiry process, for tracking cycles of refinement.
`conclusion`	No	The final conclusion drawn from the analysis, stating whether the hypothesis was supported or refuted.
`experiment`	No	The design and details of the experiment to test the hypothesis.
`hypothesis`	No	The formal hypothesis being investigated.
`observation`	No	An initial observation that sparks inquiry (e.g., 'The new feature has lower engagement than expected').
`nextStageNeeded`	Yes	A flag indicating whether the inquiry requires a subsequent stage.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description fully bears the burden of behavioral disclosure. It only states the high-level purpose and does not describe what happens during the process (e.g., mutates state, requires certain stages to be set, or has side effects).

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 a single, concise sentence that efficiently conveys the core purpose. However, it may be too brief given the complexity of the tool.

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 the tool's complexity (10 parameters, nested objects, no output schema), the description is far too minimal. It does not explain the workflow of stages, how to use the tool effectively, or what constitutes valid input.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about the parameters beyond what the schema already provides.

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 it is for 'formal hypothesis testing and experimentation following the scientific method,' which is specific and aligns with the tool name. However, it does not distinguish this tool from sibling tools that also involve reasoning or structured thinking.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to avoid, or how it fits with sibling tools like 'problem_decomposition' or 'structured_argumentation'.

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

sequential_thinkingC

A detailed tool for dynamic and reflective problem-solving through thoughts. This tool helps analyze problems through a flexible thinking process that can adapt and evolve.

ParametersJSON Schema

Name	Required	Description
`thought`	Yes	The core thinking process or analysis at this stage, forming a coherent narrative.
`branchId`	No	A unique identifier for a specific branch of thought, allowing for parallel exploration.
`sessionId`	No	Optional session identifier for maintaining state across multiple thoughts.
`isRevision`	No	Indicates if this thought is a revision of a previous one.
`currentStep`	No	The detailed description of the immediate next step to be executed.
`previousSteps`	No	A record of the steps that have already been completed.
`thoughtNumber`	Yes	The sequential number of the current thought in the series.
`totalThoughts`	Yes	The total number of thoughts planned for this problem-solving session.
`remainingSteps`	No	A high-level list of the steps that are yet to be taken.
`revisesThought`	No	The number of the thought that this one revises, if applicable.
`toolUsageHistory`	No	A log of the tools that have been used so far, along with their effectiveness.
`branchFromThought`	No	The thought number from which a new branch of thinking emerges.
`needsMoreThoughts`	No	Indicates if the current plan needs more thoughts to be added.
`nextThoughtNeeded`	Yes	A flag indicating whether another thought is required to continue the process.

TDQS

C2.5/5.0

Behavior2/5

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

No annotations present; description fails to disclose behaviors like state management, branching, or revision handling beyond what is in the schema. It adds no extra behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences are concise but front-loaded with generic terms. The description lacks structure; it doesn't orient the agent efficiently despite brevity.

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?

The tool has 14 parameters and nested objects, yet the description is vague. It fails to explain the sequential call pattern (thoughtNumber, totalThoughts, nextThoughtNeeded) or usage context, leaving the agent underinformed.

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?

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond schemas, but the schema itself is detailed. No new parameter insights are provided.

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

Purpose3/5

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

The description states it's for 'dynamic and reflective problem-solving through thoughts' but does not specifically mention 'sequential' or 'step-by-step' nature. Among many reasoning siblings, it lacks differentiation, making it moderately clear.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'collaborative_reasoning' or 'critical_thinking'. The description provides no context for selection or exclusion.

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

stochastic_algorithmA

Probabilistic algorithms for decision-making under uncertainty, including MDPs, MCTS, and Bayesian optimization.

ParametersJSON Schema

Name	Required	Description
`result`	No	The output of the algorithm, which could be an optimal policy, a selected action, a predicted value, or a solution path.
`problem`	Yes	A formal description of the problem to be solved, including the state space, actions, and objective function if applicable.
`algorithm`	Yes	The name of the stochastic algorithm to be used (e.g., 'Monte Carlo Tree Search', 'Simulated Annealing').
`parameters`	No	Algorithm-specific parameters. For MCTS, this could be {'simulations': 1000, 'exploration_constant': 1.41}. For Simulated Annealing, {'initial_temp': 1000, 'cooling_rate': 0.995}.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations exist, so the description must fully disclose behavior. It only mentions the algorithms are probabilistic, but does not explain side effects, determinism, performance, or any constraints. Critical behavioral details are missing.

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 a single sentence, making it concise. However, it is a noun phrase fragment rather than a full imperative sentence, which slightly reduces clarity. Still, it is front-loaded with the core verb 'Probabilistic algorithms'.

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 the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain how to construct the problem string, list algorithm options, or describe return values. Comprehensive usage examples or constraints are absent.

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 input schema has 100% description coverage, providing clear definitions for each parameter. The description adds value by giving specific examples for the 'parameters' object (e.g., MCTS, Simulated Annealing), which helps the agent understand valid entries beyond the schema's generic 'additionalProperties'.

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

Purpose5/5

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

The description clearly states the tool applies probabilistic algorithms (MDPs, MCTS, Bayesian optimization) for decision-making under uncertainty. This is specific and distinguishes it from sibling reasoning tools, which focus on structured thinking rather than algorithmic execution.

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 when dealing with decision-making under uncertainty, but it does not explicitly state when to use this tool versus alternatives like collaborative_reasoning or scientific_method. No when-not or exclusion criteria are provided.

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

structured_argumentationC

Dialectical reasoning and argument analysis for structured debates and logical reasoning.

ParametersJSON Schema

Name	Required	Description
`claim`	Yes	The central claim or assertion being made.
`premises`	Yes	A list of reasons or evidence supporting the claim.
`supports`	No	A list of argument IDs that this argument supports.
`strengths`	No	A list of the argument's strengths.
`argumentId`	No	A unique identifier for this argument.
`conclusion`	Yes	The logical conclusion drawn from the premises.
`confidence`	Yes	A confidence score (0-1) in the validity of the argument.
`respondsTo`	No	The ID of the argument to which this one is responding.
`weaknesses`	No	A list of the argument's weaknesses.
`contradicts`	No	A list of argument IDs that this argument contradicts.
`argumentType`	Yes	The type of argument being made.
`nextArgumentNeeded`	Yes	A flag indicating whether another argument is needed to continue the debate.
`suggestedNextTypes`	No	A list of suggested types for the next argument.

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, required permissions, limitations, or what happens to existing data. The tool likely creates or retrieves argument structures, but this is not clarified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It does not front-load key information or separate usage context from details. It could be more informative without becoming verbose.

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 the tool has 13 parameters (6 required) and no output schema, the description is too brief to provide complete context. It does not explain how the argument types relate, the purpose of the arguments, or what the tool returns or creates.

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?

Schema description coverage is 100%, so each parameter has a description in the schema. The tool description adds no extra meaning beyond what the schema provides, such as explaining the dialectical flow or relationships between parameters like 'respondsTo' and 'contradicts'.

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

Purpose3/5

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

The description states 'dialectical reasoning and argument analysis for structured debates and logical reasoning,' which indicates the tool's domain but lacks a specific verb indicating what action the tool performs (e.g., 'generate', 'evaluate', 'analyze'). The purpose is somewhat clear but vague compared to sibling tools like 'debugging_approach' or 'scientific_method'.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or differentiate it from siblings like 'collaborative_reasoning' or 'critical_thinking'.

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

temporal_thinkingB

Modeling systems and reasoning across time using states, events, and transitions.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags for categorizing this model.
`domain`	No	The domain this model belongs to (e.g., 'business process', 'software system').
`events`	Yes	A comprehensive list of all possible events that can occur.
`states`	Yes	A comprehensive list of all possible states in the system.
`context`	Yes	A comprehensive description of the system or process being modeled.
`modelId`	No	A unique identifier for this temporal model.
`purpose`	No	The purpose or goal of creating this temporal model.
`version`	No	Version of this temporal model.
`analysis`	No	Analysis results of the temporal model.
`scenarios`	No	Test scenarios for the temporal model.
`complexity`	No	Complexity level of the temporal model.
`validation`	No	Validation results of the temporal model.
`finalStates`	No	A list of states that are considered terminal or final.
`transitions`	Yes	A comprehensive list of all possible transitions between states.
`completeness`	No	Completeness score of the model.
`initialState`	Yes	The name of the initial state of the system.
`lastModified`	No	When this model was last modified.
`sequenceDiagram`	No	Generated sequence diagram showing temporal interactions between actors.
`timeConstraints`	No	Time-based constraints on the system.
`globalConstraints`	No	Global constraints that apply to the entire system.
`generateSequenceDiagram`	No	Whether to automatically generate a sequence diagram from the temporal model.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description bears full burden for behavioral disclosure. It only states the tool's purpose without revealing any behavioral traits such as whether it creates a model, requires external state, or has side effects. The schema implies an input-heavy operation, but the description does not confirm this.

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 sentence that is front-loaded and concise. It communicates the core purpose without extraneous information. Every word earns its place.

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 the tool's complexity (21 parameters, nested objects, no output schema), the description is too minimal. It does not explain what the tool returns, how to structure the model, or provide any integration context. The schema is rich, but the description adds no overview or guidance.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level information beyond what the schema already provides, but it does not contradict or confuse. The description's brevity means it offers no additional semantic value for parameters.

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

Purpose5/5

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

The description clearly states the tool does 'modeling systems and reasoning across time' using states, events, and transitions. This distinguishes it from sibling tools like 'domain_modeling' or 'critical_thinking' by focusing specifically on temporal aspects.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There is no indication of context, prerequisites, or when not to use it, leaving the agent to infer suitability from name and schema alone.

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

visual_reasoningC

Diagram-based thinking and problem solving with visual elements and transformations.

ParametersJSON Schema

Name	Required	Description
`context`	No	Additional context relevant to the visual reasoning.
`insight`	No	An insight gained from the visual analysis.
`purpose`	No	The purpose or goal of this visual reasoning session.
`audience`	No	The intended audience for the diagram.
`elements`	No	The visual elements being operated on or analyzed.
`diagramId`	Yes	A unique identifier for the diagram.
`iteration`	Yes	The iteration number of this reasoning step.
`operation`	Yes	The operation to be performed on the visual elements.
`hypothesis`	No	A hypothesis formed from the insight.
`diagramType`	Yes	The type of diagram being reasoned about.
`observation`	No	An observation made about the diagram.
`reasoningChain`	No	Sequential steps in the visual reasoning process.
`diagramAnalysis`	No	Comprehensive analysis of the diagram structure and properties.
`recommendations`	No	Recommendations for improving the diagram.
`transformationType`	No	The type of transformation to be applied.
`nextOperationNeeded`	Yes	A flag indicating whether another operation is needed.
`suggestedOperations`	No	Suggested next operations.
`transformationDetails`	No	Detailed information about the transformation.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. The single sentence does not mention side effects (e.g., state changes), authentication needs, rate limits, or any other behavioral traits. For a complex tool with many operations, this is insufficient.

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 concise (one sentence, 10 words) and front-loaded with the key concept 'diagram-based.' However, given the tool's complexity, slightly more detail would improve utility without sacrificing conciseness.

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?

Despite the rich input schema, the description lacks context on output format (no output schema), workflow sequencing, or how this tool integrates with other reasoning steps. The absence of return value information and usage patterns makes it incomplete for effective agent use.

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 detailed explanations for all 18 parameters and nested objects. The tool description adds no further meaning beyond what the schema already provides, so the baseline score of 3 applies.

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 it is for 'diagram-based thinking and problem solving with visual elements and transformations.' This distinguishes it from sibling reasoning tools like 'critical_thinking' or 'sequential_thinking' by specifying the domain (visual/diagram). However, it lacks a specific verb-resource pairing and could be more precise.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, contexts, or situations where it should not be used. Given the extensive sibling set, this omission hinders an agent from making an informed selection.

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. Dates show when Glama detected each change.

15 tool updatesv1.0.3Jul 12, 2026
- First observedcollaborative_reasoning
- First observedcritical_thinking
- First observeddebugging_approach
- First observeddecision_framework
- First observeddomain_modeling
- First observedmental_model
- First observedmetacognitive_monitoring
- First observedproblem_decomposition
- First observedrecursive_thinking
- First observedscientific_method
- First observedsequential_thinking
- First observedstochastic_algorithm
- First observedstructured_argumentation
- First observedtemporal_thinking
- First observedvisual_reasoning

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool targets a distinct thinking pattern or reasoning approach, with clear definitions that prevent overlap. Even closely related tools like mental_model and domain_modeling are differentiated by focus on internal representations versus external conceptual models.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a descriptive prefix followed by a thinking-related noun (e.g., collaborative_reasoning, critical_thinking, debugging_approach). No mixing of conventions or ambiguous verb choices.

Tool Count4/5

With 15 tools, the set is comprehensive for a thinking patterns server, though some tools like recursive_thinking and stochastic_algorithm might be considered niche. However, each tool serves a distinct purpose and justifies its inclusion.

Completeness4/5

The tools cover a wide range of reasoning techniques including collaborative, critical, logical, temporal, and visual methods. Minor gaps exist (e.g., creative thinking or dialectical reasoning beyond structured_argumentation), but the set is largely complete for systematic problem-solving.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

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

agentstack-mcp A
io.github.inity13
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Autonomous Agents Agent Orchestration
241
Hive Consult A
io.github.srotzin
Agent-to-agent reasoning-as-a-service: chain-of-thought, analysis, and decision support.
AI & Machine Learning Autonomous Agents
42
SUBSTRATE
io.github.PKaldone
Persistent AI entity framework with causal memory, emotional state, and identity.
Knowledge & Memory Autonomous Agents AI & Machine Learning
2
meminal
ai.meminal
Memory for deep conversational context across any platform
Knowledge & Memory Autonomous Agents Communication
2

Related MCP Servers

MCP Think Tank
Knowledge & Memory Autonomous Agents Agent Orchestration
flight505
A
license
B
quality
D
maintenance
Provides AI assistants with enhanced reasoning capabilities through structured thinking, persistent knowledge graph memory, and intelligent tool orchestration for complex problem-solving.
Updated a year ago (2025-07-14 11:03 UTC)
20
25
61
MIT
Clear Thought Server
Developer Tools RAG Systems
ThinkFar
F
license
C
quality
F
maintenance
Provide systematic thinking, mental models, and debugging approaches to enhance problem-solving capabilities. Enable structured reasoning and decision-making support for complex problems. Facilitate integration with MCP-compatible clients for advanced cognitive workflows.
Updated a year ago (2025-05-31 20:21 UTC)
11
5
-
Clear Thought 1.5
Developer Tools Autonomous Agents Code Analysis
waldzellai
A
license
Not graded
quality
F
maintenance
Provides 30+ unified reasoning operations including systematic thinking, mental models, debugging approaches, statistical analysis, interactive notebooks, and advanced problem-solving frameworks for enhanced decision-making and complex reasoning tasks.
Updated a year ago (2025-10-20 23:53 UTC)
188
53
MIT
Clear Thought MCP Server
Developer Tools Knowledge & Memory Autonomous Agents
chirag127
A
license
C
quality
B
maintenance
Provides systematic thinking tools including mental models, design patterns, debugging approaches, and collaborative reasoning frameworks to enhance problem-solving and decision-making capabilities.
Updated 3 days ago (2026-09-03 21:44 UTC)
11
37
MIT

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/emmahyde/thinking-patterns'

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