Skip to main content
Glama
manolaz

Emergency Medicare Planner MCP Server

by manolaz

sequentialthinking

Analyze and solve complex medical problems step-by-step using a flexible, adaptive thinking process. Plan, revise, and refine treatment approaches while maintaining context, exploring alternatives, and generating accurate clinical hypotheses.

Instructions

A detailed tool for dynamic and reflective medical problem-solving through thoughts. This tool helps analyze medical problems through a flexible thinking process that can adapt and evolve. Each thought can build on, question, or revise previous insights as understanding of the medical situation deepens.

When to use this tool:

  • Breaking down complex medical problems into steps

  • Planning and designing treatment approaches with room for revision

  • Clinical analysis that might need course correction

  • Medical problems where the full scope might not be clear initially

  • Healthcare decisions that require a multi-step solution

  • Medical evaluations that need to maintain context over multiple steps

  • Situations where irrelevant medical information needs to be filtered out

Key features:

  • You can adjust total_thoughts up or down as the diagnosis progresses

  • You can question or revise previous medical assessments

  • You can add more diagnostic thoughts as new information emerges

  • You can express clinical uncertainty and explore alternative approaches

  • Not every medical assessment needs to build linearly - you can branch or backtrack

  • Generates a clinical hypothesis

  • Verifies the hypothesis based on the Chain of Thought steps

  • Repeats the process until a satisfactory diagnosis or treatment plan is reached

  • Provides a correct medical assessment or recommendation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
branchFromThoughtNoBranching point thought number for alternative diagnosis
branchIdNoBranch identifier for the diagnostic path
isRevisionNoWhether this revises previous medical thinking
needsMoreThoughtsNoIf more clinical evaluation is needed
nextThoughtNeededYesWhether another medical assessment step is needed
revisesThoughtNoWhich medical assessment is being reconsidered
thoughtYesYour current clinical thinking step
thoughtNumberYesCurrent thought number
totalThoughtsYesEstimated total thoughts needed for complete evaluation

Implementation Reference

  • index.ts:94-138 (handler)
    The main handler method of the SequentialThinkingServer class that executes the core logic of the sequentialthinking tool: validates input, manages thought history and branches, formats and logs the thought, and returns structured JSON output.
    public processThought(input: unknown): { content: Array<{ type: string; text: string }>; isError?: boolean } {
      try {
        const validatedInput = this.validateThoughtData(input);
    
        if (validatedInput.thoughtNumber > validatedInput.totalThoughts) {
          validatedInput.totalThoughts = validatedInput.thoughtNumber;
        }
    
        this.thoughtHistory.push(validatedInput);
    
        if (validatedInput.branchFromThought && validatedInput.branchId) {
          if (!this.branches[validatedInput.branchId]) {
            this.branches[validatedInput.branchId] = [];
          }
          this.branches[validatedInput.branchId].push(validatedInput);
        }
    
        const formattedThought = this.formatThought(validatedInput);
        console.error(formattedThought);
    
        return {
          content: [{
            type: "text",
            text: JSON.stringify({
              thoughtNumber: validatedInput.thoughtNumber,
              totalThoughts: validatedInput.totalThoughts,
              nextThoughtNeeded: validatedInput.nextThoughtNeeded,
              branches: Object.keys(this.branches),
              thoughtHistoryLength: this.thoughtHistory.length
            }, null, 2)
          }]
        };
      } catch (error) {
        return {
          content: [{
            type: "text",
            text: JSON.stringify({
              error: error instanceof Error ? error.message : String(error),
              status: 'failed'
            }, null, 2)
          }],
          isError: true
        };
      }
    }
  • Input schema definition for the sequentialthinking tool, specifying properties like thought, thoughtNumber, totalThoughts, and optional branching/revision fields.
    inputSchema: {
      type: "object",
      properties: {
        thought: {
          type: "string",
          description: "Your current clinical thinking step"
        },
        nextThoughtNeeded: {
          type: "boolean",
          description: "Whether another medical assessment step is needed"
        },
        thoughtNumber: {
          type: "integer",
          description: "Current thought number",
          minimum: 1
        },
        totalThoughts: {
          type: "integer",
          description: "Estimated total thoughts needed for complete evaluation",
          minimum: 1
        },
        isRevision: {
          type: "boolean",
          description: "Whether this revises previous medical thinking"
        },
        revisesThought: {
          type: "integer",
          description: "Which medical assessment is being reconsidered",
          minimum: 1
        },
        branchFromThought: {
          type: "integer",
          description: "Branching point thought number for alternative diagnosis",
          minimum: 1
        },
        branchId: {
          type: "string",
          description: "Branch identifier for the diagnostic path"
        },
        needsMoreThoughts: {
          type: "boolean",
          description: "If more clinical evaluation is needed"
        }
      },
      required: ["thought", "nextThoughtNeeded", "thoughtNumber", "totalThoughts"]
    }
  • index.ts:294-296 (registration)
    Dispatch handler in CallToolRequestSchema that routes calls to 'sequentialthinking' to the processThought method.
    if (name === "sequentialthinking") {
      return thinkingServer.processThought(args);
    }
  • index.ts:284-287 (registration)
    Registration of the sequentialthinking tool in the ListToolsRequestSchema handler's tools array.
        // Add the sequential thinking tool
        SEQUENTIAL_THINKING_TOOL,
      ],
    }));
  • Helper method for input validation within the SequentialThinkingServer class.
    private validateThoughtData(input: unknown): ThoughtData {
      const data = input as Record<string, unknown>;
    
      if (!data.thought || typeof data.thought !== 'string') {
        throw new Error('Invalid thought: must be a string');
      }
      if (!data.thoughtNumber || typeof data.thoughtNumber !== 'number') {
        throw new Error('Invalid thoughtNumber: must be a number');
      }
      if (!data.totalThoughts || typeof data.totalThoughts !== 'number') {
        throw new Error('Invalid totalThoughts: must be a number');
      }
      if (typeof data.nextThoughtNeeded !== 'boolean') {
        throw new Error('Invalid nextThoughtNeeded: must be a boolean');
      }
    
      return {
        thought: data.thought,
        thoughtNumber: data.thoughtNumber,
        totalThoughts: data.totalThoughts,
        nextThoughtNeeded: data.nextThoughtNeeded,
        isRevision: data.isRevision as boolean | undefined,
        revisesThought: data.revisesThought as number | undefined,
        branchFromThought: data.branchFromThought as number | undefined,
        branchId: data.branchId as string | undefined,
        needsMoreThoughts: data.needsMoreThoughts as boolean | undefined,
      };
    }
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses key behavioral traits like adaptability ('can adjust total_thoughts'), revision capabilities ('question or revise previous medical assessments'), and iterative nature ('Repeats the process until a satisfactory diagnosis'). However, it lacks details on error handling, performance limits, or authentication needs, leaving gaps for a tool with 9 parameters.

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 front-loaded with purpose and usage guidelines, but becomes verbose in 'Key features' with repetitive points (e.g., multiple lines on revision and branching). Sentences like 'Generates a clinical hypothesis' and 'Verifies the hypothesis' could be condensed. Overall, it's informative but could be more streamlined.

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

Completeness3/5

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

Given no annotations and no output schema, the description provides good usage context and behavioral hints. However, for a complex tool with 9 parameters involving medical decision-making, it lacks details on output format, error cases, or security considerations, making it incomplete for full agent 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 description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantic context beyond the schema, such as implying 'total_thoughts' is adjustable and 'thought' represents 'clinical thinking step,' but doesn't elaborate on parameter interactions or usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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 enables 'dynamic and reflective medical problem-solving through thoughts' and 'helps analyze medical problems through a flexible thinking process.' It specifies the domain (medical) and core function (problem-solving via sequential thoughts). However, it doesn't explicitly differentiate from sibling tools like 'check_medicare_coverage' or 'find_nearby_medical_facilities,' which serve different purposes rather than overlapping in medical analysis.

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

Usage Guidelines5/5

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

The description provides explicit 'When to use this tool' guidance with seven specific scenarios, such as 'Breaking down complex medical problems into steps' and 'Clinical analysis that might need course correction.' It clearly outlines appropriate contexts without mentioning alternatives, which is sufficient given the siblings are unrelated (e.g., coverage checks, facility finding).

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

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/manolaz/emergency-medicare-planner-mcp-server'

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