Skip to main content
Glama
chirag127
by chirag127

mentalmodel

Apply structured mental models like First Principles Thinking and Pareto Principle to systematically break down and solve complex problems.

Instructions

A tool for applying structured mental models to problem-solving. Supports various mental models including:

  • First Principles Thinking

  • Opportunity Cost Analysis

  • Error Propagation Understanding

  • Rubber Duck Debugging

  • Pareto Principle

  • Occam's Razor

Each model provides a systematic approach to breaking down and solving problems.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNameYes
problemYes
stepsNo
reasoningNo
conclusionNo

Implementation Reference

  • The `processModel` method acts as the primary handler for the `mentalmodel` tool, coordinating validation, formatting, and result execution.
    public processModel(input: unknown): any {
        try {
            const validatedInput = this.validateModelData(input);
            const formattedOutput = this.formatModelOutput(validatedInput);
            console.error(formattedOutput);
    
            return {
                modelName: validatedInput.modelName,
                status: "success",
                hasSteps: validatedInput.steps.length > 0,
                hasConclusion: !!validatedInput.conclusion,
            };
        } catch (error) {
            return {
                error: error instanceof Error ? error.message : String(error),
                status: "failed",
            };
        }
    }
  • Input validation logic ensuring the required fields for the mental model are present and correctly typed.
    private validateModelData(input: unknown): MentalModelData {
        const data = input as Record<string, unknown>;
    
        if (!data.modelName || typeof data.modelName !== "string") {
            throw new Error("Invalid modelName: must be a string");
        }
        if (!data.problem || typeof data.problem !== "string") {
            throw new Error("Invalid problem: must be a string");
        }
    
        return {
            modelName: data.modelName as string,
            problem: data.problem as string,
            steps: Array.isArray(data.steps) ? data.steps.map(String) : [],
            reasoning:
                typeof data.reasoning === "string"
                    ? (data.reasoning as string)
                    : "",
            conclusion:
                typeof data.conclusion === "string"
                    ? (data.conclusion as string)
                    : "",
        };
  • src/index.ts:1046-1056 (registration)
    The `mentalmodel` tool is registered and invoked within the main MCP tool execution switch case in `src/index.ts`.
    case "mentalmodel": {
        const result = modelServer.processModel(request.params.arguments);
        return {
            content: [
                {
                    type: "text",
                    text: JSON.stringify(result, null, 2),
                },
            ],
        };
    }

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.2

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 the full burden of behavioral disclosure. It describes the tool's function but lacks critical behavioral details: it doesn't specify whether this is a read-only analysis tool or if it modifies data, what the output format might be (e.g., structured analysis, recommendations), or any constraints like rate limits or authentication needs. The description is functional but misses key operational context.

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 and well-structured: it starts with a clear purpose statement, lists supported models in a bulleted format for readability, and ends with a summary sentence. Every sentence adds value without redundancy. Minor improvement could be made by front-loading key usage details, but it's efficient overall.

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 complexity (5 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It covers the tool's purpose and model examples but fails to address parameter meanings, output expectations, or behavioral traits. For a tool with multiple undocumented inputs and no structured output, more context is needed to guide 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 description coverage is 0%, so the description must compensate for undocumented parameters. It lists six mental models by name, which clarifies the 'modelName' enum values, adding meaningful context beyond the raw enum list. However, it doesn't explain the semantics of other parameters like 'steps,' 'reasoning,' or 'conclusion,' leaving them ambiguous. The partial compensation justifies a baseline score.

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: 'applying structured mental models to problem-solving' with a specific verb ('applying') and resource ('mental models'). It lists six concrete examples of supported models, making the purpose concrete. However, it doesn't explicitly differentiate from sibling tools like 'decisionframework' or 'structuredargumentation', which likely have overlapping problem-solving applications.

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. It mentions 'systematic approach to breaking down and solving problems,' but this is generic and doesn't help an agent choose between this and sibling tools like 'collaborativereasoning' or 'scientificmethod.' No explicit when/when-not scenarios or prerequisites are stated.

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