Skip to main content
Glama
arben-adm

Sequential Thinking MCP Server

process_thought

Structure problem-solving by recording sequential thoughts with metadata, supporting revisions and branching to explore alternative solution paths.

Instructions

Add a sequential thought with its metadata.

Args:
    thought: The content of the thought
    thought_number: The sequence number of this thought
    total_thoughts: The total expected thoughts in the sequence
    next_thought_needed: Whether more thoughts are needed after this one
    stage: The thinking stage (Problem Definition, Research, Analysis, Synthesis, Conclusion)
    tags: Optional keywords or categories for the thought
    axioms_used: Optional list of principles or axioms used in this thought
    assumptions_challenged: Optional list of assumptions challenged by this thought
    is_revision: Whether this thought revises an earlier thought
    revises_thought_number: The number of the earlier thought being revised (required if is_revision is true)
    branch_from_thought: The thought number this thought branches from, to explore an alternative path
    branch_id: Identifier for the branch (letters, digits, '-', '_'; max 64 chars; requires branch_from_thought)
    ctx: Optional MCP context object

Returns:
    dict: Analysis of the processed thought

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctxNo
tagsNo
stageYes
thoughtYes
branch_idNo
axioms_usedNo
is_revisionNo
thought_numberYes
total_thoughtsYes
branch_from_thoughtNo
next_thought_neededYes
assumptions_challengedNo
revises_thought_numberNo
Behavior2/5

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

No annotations are present, so the description must disclose all behavioral traits. It details what the tool does but omits side effects, permission requirements, error handling, or the state modifications (e.g., appending to a thought list). The return value is only vaguely described as 'dict: Analysis of the processed thought.'

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 front-loaded with a one-line summary, then structured as a docstring with Args and Returns. It is reasonably concise, though the parameter list is lengthy. Every sentence adds value, but could be more compact.

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 the tool's complexity (13 parameters, no output schema, no annotations), the description explains each parameter but lacks guidance on the overall workflow (e.g., sequential numbering, when to set 'next_thought_needed'). The stage values are enumerated, but the return value and error conditions are unspecified.

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 no property descriptions (0% coverage), so the description must compensate. The Args list provides brief explanations for each parameter, but these mostly restate the parameter names (e.g., 'thought: The content of the thought') without adding deeper semantics, constraints, or examples.

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 opens with 'Add a sequential thought with its metadata,' which clearly states the action and resource. This distinguishes it from sibling tools (clear_history, export_session, generate_summary, import_session) which serve different purposes.

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 does not explicitly state when to use this tool versus alternatives. The usage is implied by the tool name and sibling context, but no exclusion criteria or when-not scenarios are provided.

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

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/arben-adm/mcp-sequential-thinking'

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