Skip to main content
Glama
AbdulAziz001

crash-mcp

by AbdulAziz001

crash

Record structured reasoning steps to break down complex problems, track confidence, revise decisions, and explore alternative branches for systematic problem-solving.

Instructions

Record a structured reasoning step for complex problem-solving.

Use this tool to break down multi-step problems into trackable reasoning steps. Each step captures your current thinking, expected outcome, and planned next action.

WHEN TO USE:

  • Multi-step analysis, debugging, or planning tasks

  • Tasks requiring systematic exploration of options

  • Problems where you need to track confidence or revise earlier thinking

  • Exploring multiple solution paths via branching

WORKFLOW:

  1. Start with step_number=1, estimate your total steps

  2. Describe your thought process, expected outcome, and next action

  3. Continue calling for each reasoning step, adjusting estimated_total as needed

  4. Use confidence (0-1) when uncertain about conclusions

  5. Use revises_step to correct earlier reasoning when you find errors

  6. Use branch_from to explore alternative approaches

  7. Set is_final_step=true when reasoning is complete

Returns JSON summary with step count, completion status, and next action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextYesWhat is already known or has been completed. Include relevant findings from previous steps to avoid redundant work.
outcomeYesThe expected or actual result from this step. What did you learn or accomplish?
purposeYesCategory of this reasoning step. Standard values: analysis (examining information), action (taking an action), reflection (reviewing progress), decision (making a choice), summary (consolidating findings), validation (checking results), exploration (investigating options), hypothesis (forming theories), correction (fixing errors), planning (outlining approach). Custom strings allowed in flexible mode.
thoughtYesYour current reasoning process. Express naturally - describe what you are thinking and why.
branch_idNoUnique identifier for this branch. Auto-generated if not provided.
rationaleYesWhy you chose this next action. Explain your reasoning for the approach.
confidenceNoYour confidence in this step (0-1 scale). Use lower values when uncertain: 0.3 = low confidence, 0.5 = moderate, 0.8+ = high confidence.
session_idNoSession identifier for grouping related reasoning chains. Sessions expire after configured timeout.
tools_usedNoList of tools you used during this step for tracking purposes.
branch_fromNoStep number to branch from for exploring an alternative approach. Creates a new solution path.
branch_nameNoHuman-readable name for this branch (e.g., "Alternative A: Use caching")
next_actionYesWhat you will do next. Can be a simple string or structured object with tool details.
step_numberYesSequential step number starting from 1. Increment for each new reasoning step.
dependenciesNoStep numbers this step depends on. Validated against existing steps in history.
revises_stepNoStep number you are revising or correcting. The original step will be marked as revised.
is_final_stepNoSet to true to explicitly mark this as the final reasoning step. The reasoning chain will be marked complete.
estimated_totalYesCurrent estimate of total steps needed. Adjust as you learn more about the problem.
revision_reasonNoWhy you are revising the earlier step. What was wrong or incomplete?
external_contextNoExternal data or tool outputs relevant to this step. Store important results here.
uncertainty_notesNoDescribe specific uncertainties or doubts. What assumptions are you making? What could be wrong?
Behavior4/5

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

With no annotations, the description carries the transparency burden. It explains the recording behavior, revision marking, branching, and finalization, and explicitly discloses the return format: 'Returns JSON summary with step count, completion status, and next action.' It also notes session expiration via the schema. This is sufficient for an agent to understand the tool's 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 well-structured with a clear intro, 'WHEN TO USE' bullets, and a numbered workflow, making it scannable despite its length. It is front-loaded with the purpose statement. Some redundancy exists between workflow steps and schema descriptions, but for 20 parameters the level of detail is appropriate.

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

Completeness4/5

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

The tool has 20 parameters, no output schema, and no annotations. The description provides the essential context: purpose, use cases, a step-by-step workflow, and a description of the return value. It covers branching, revision, confidence, and completion status. While examples are not provided, the combination of description and schema is sufficient for correct invocation.

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 schema already provides 100% parameter descriptions, giving a baseline of 3. The description adds value by explaining how parameters are used together in the workflow: 'Start with step_number=1', 'Use confidence (0-1)', 'Use revises_step to correct', 'Use branch_from to explore', and 'Set is_final_step=true'. This inter-parameter guidance goes beyond the standalone schema descriptions.

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 first line states the tool's function precisely: 'Record a structured reasoning step for complex problem-solving.' It uses a clear verb ('Record') and resource ('structured reasoning step'), and the 'WHEN TO USE' section further clarifies its scope. Despite the misleading tool name 'crash', the description leaves no doubt about the tool's purpose.

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

Usage Guidelines4/5

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

A dedicated 'WHEN TO USE' section lists concrete scenarios: multi-step analysis, debugging, planning, systematic exploration, and branching. It also provides a numbered workflow for how to invoke the tool across a reasoning session. However, it does not explicitly state when not to use the tool or mention alternatives, though no sibling tools exist.

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/AbdulAziz001/mcp-local'

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