cortex-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@cortex-mcpAnalyze the pros and cons of remote work at expert depth"
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.
Cortex MCP
Multi-level reasoning MCP server with configurable depth levels, session-based state management, structured thought input, and real-time trace resources.
Overview
Cortex MCP is a stdio-only MCP server for stateful, depth-controlled reasoning. The runtime entrypoint in src/index.ts connects createServer() to StdioServerTransport, and the server surface in src/server.ts enables tools, prompts, completions, logging, and subscribable resources around a single session-based reasoning engine.
The live MCP surface confirmed by Inspector is 1 tool, 6 concrete resources, 4 resource templates, and 7 prompts. Sessions are stored in memory, exposed as MCP resources, and cleared on process restart.
Related MCP server: CRASH - Cascaded Reasoning with Adaptive Step Handling
Key Features
reasoning_thinksupports step-by-step sessions,run_to_completionbatches, rollback, early conclusion, and structuredobservation/hypothesis/evaluationinput.Four depth levels are built into the engine:
basic,normal,high, andexpert, each with bounded thought ranges and token budgets.Prompt helpers expose
reasoning.basic,reasoning.normal,reasoning.high,reasoning.expert,reasoning.continue,reasoning.retry, andget-help.Resource endpoints expose internal docs plus live session lists, per-session JSON views, full markdown traces, and individual thought documents.
Completions are wired for levels, session IDs, and thought names through
completable()and resource-template completion hooks.
Requirements
Node.js
>=24for localnpxornpmusage.An MCP client that supports
stdiotransport.Optional: Docker if you want to build or run the container image defined by
Dockerfile.
Quick Start
Use this standard MCP client configuration:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}Client Configuration
Add to .vscode/mcp.json:
{
"servers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}Or install via CLI:
code --add-mcp '{"name":"cortex-mcp","command":"npx","args":["-y","@j0hanz/cortex-mcp@latest"]}'For more info, see VS Code MCP docs.
Add to .vscode/mcp.json:
{
"servers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}Or install via CLI:
code-insiders --add-mcp '{"name":"cortex-mcp","command":"npx","args":["-y","@j0hanz/cortex-mcp@latest"]}'For more info, see VS Code Insiders MCP docs.
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Cursor MCP docs.
Add to mcp.json (VS integrated):
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Visual Studio MCP docs.
Add to Goose extension registry:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Goose MCP docs.
Add to LM Studio MCP config:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see LM Studio MCP docs.
Add to claude_desktop_config.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Claude Desktop MCP docs.
Add to Claude Code CLI:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}Or install via CLI:
claude mcp add cortex-mcp -- npx -y @j0hanz/cortex-mcp@latestFor more info, see Claude Code MCP docs.
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Windsurf MCP docs.
Add to Amp MCP config:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}Or install via CLI:
amp mcp add cortex-mcp -- npx -y @j0hanz/cortex-mcp@latestFor more info, see Amp MCP docs.
Add to cline_mcp_settings.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Cline MCP docs.
Add to ~/.codex/config.yaml or codex CLI:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Codex CLI MCP docs.
Add to .vscode/mcp.json:
{
"servers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see GitHub Copilot MCP docs.
Add to Warp MCP config:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Warp MCP docs.
Add to .kiro/settings/mcp.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Kiro MCP docs.
Add to ~/.gemini/settings.json:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Gemini CLI MCP docs.
Add to ~/.config/zed/settings.json:
{
"context_servers": {
"cortex-mcp": {
"settings": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}
}For more info, see Zed MCP docs.
Add to VS Code settings.json:
Add to your VS Code
settings.jsonunderaugment.advanced.
{
"augment.advanced": {
"mcpServers": [
{
"id": "cortex-mcp",
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
]
}
}For more info, see Augment MCP docs.
Add to Roo Code MCP settings:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Roo Code MCP docs.
Add to Kilo Code MCP settings:
{
"mcpServers": {
"cortex-mcp": {
"command": "npx",
"args": ["-y", "@j0hanz/cortex-mcp@latest"]
}
}
}For more info, see Kilo Code MCP docs.
Use Cases
Start bounded reasoning at the right depth
Use reasoning.basic, reasoning.normal, reasoning.high, or reasoning.expert when the client wants a prompt-first entrypoint, or call reasoning_think directly with query, level, and the first thought. Each response returns the current session state plus a summary string that tells the client how to continue.
Relevant tool: reasoning_think
Related prompts: reasoning.basic, reasoning.normal, reasoning.high, reasoning.expert
Continue, retry, or batch an active session
Reuse sessionId to continue a prior trace, switch to runMode="run_to_completion" when you already have the remaining thought inputs, or use the continuation and retry prompts to generate the next call payload. The handler also supports rollbackToStep and isConclusion for revising or ending a trace early.
Relevant tool: reasoning_think
Related prompts: reasoning.continue, reasoning.retry
Inspect live traces without re-running the tool
Read reasoning://sessions for the active session list, reasoning://sessions/{sessionId} for the JSON detail view, reasoning://sessions/{sessionId}/trace for the markdown transcript, or reasoning://sessions/{sessionId}/thoughts/{thoughtName} for a single thought. This lets a client present progress or audit a session independently from the next tool call.
Relevant resources: reasoning://sessions, reasoning://sessions/{sessionId}, reasoning://sessions/{sessionId}/trace, reasoning://sessions/{sessionId}/thoughts/{thoughtName}
Architecture
[MCP Client]
|
| stdio
v
[src/index.ts]
createServer()
-> new StdioServerTransport()
-> server.connect(transport)
|
v
[src/server.ts]
McpServer("cortex-mcp")
capabilities:
- tools
- prompts
- completions
- logging
- resources { subscribe: true, listChanged: true }
|
+--> tools/call
| -> reasoning_think
| -> src/tools/reasoning-think.ts
| -> ReasoningThinkInputSchema / ReasoningThinkToolOutputSchema
| -> src/engine/reasoner.ts
| -> SessionStore
|
+--> prompts/get
| -> src/prompts/index.ts
|
+--> resources/read
| -> src/resources/index.ts
| -> internal://* and reasoning://sessions/*
|
+--> notifications
-> logging messages
-> resources/list_changed
-> resources/updated
-> notifications/progressRequest Lifecycle
[Client] -- initialize --> [Server]
[Server] -- serverInfo + capabilities --> [Client]
[Client] -- notifications/initialized --> [Server]
[Client] -- tools/call {name: "reasoning_think", arguments} --> [Handler]
[Handler] -- validate args --> [Reasoner + SessionStore]
[Reasoner] -- progress/resource events --> [Server notifications]
[Handler] -- structuredContent + optional trace resource --> [Client]MCP Surface
Tools
reasoning_think
Stateful reasoning tool for creating and continuing multi-step sessions. It supports one-step interactive calls, run_to_completion batches, structured observation/hypothesis/evaluation input, rollback, and early conclusion while returning structured session state.
Parameter | Type | Required | Description |
|
| no | Question or problem to analyze. |
|
| no | Depth level. Required for new sessions. basic (1–3 steps, 2K budget), normal (4–8 steps, 8K budget), high (10–15 steps, 32K budget), expert (20–25 steps, 128K budget). |
|
| no | Exact step count. Must fit level range. |
|
| no | Session ID to continue. |
|
| no | "step" (default) or "run_to_completion". |
|
| no | Reasoning text. Stored verbatim. String for step mode, string[] for batch. |
|
| no | End session early at final answer. |
|
| no | 0-based index to rollback to. Discards later thoughts. |
|
| no | One-sentence step summary. |
|
| no | Known facts at this step. |
|
| no | Proposed next idea. |
|
| no | Critique of hypothesis. |
1. [Client] -- tools/call {name: "reasoning_think", arguments} --> [Server]
Transport: stdio
2. [Server] -- dispatch("reasoning_think") --> [Handler: src/tools/reasoning-think.ts]
3. [Handler] -- validate(ReasoningThinkInputSchema) --> [src/engine/reasoner.ts]
4. [Reasoner] -- create/update session --> [src/engine/session-store.ts]
5. [Handler] -- structuredContent + optional embedded trace resource --> [Client]Resources
Resource | URI or Template | MIME Type | Description |
|
|
| Usage instructions for the MCP server. |
|
|
| Runtime limits and level configurations for the reasoning server. |
|
|
| Tool reference: models, params, outputs, data flow. |
|
|
| Per-tool contract details. |
|
|
| Contract details for |
|
|
| Recommended workflows and tool sequences. |
|
| application/json | List of active reasoning sessions with summaries. Updated in real-time as sessions progress. |
|
|
| Detailed view of a single reasoning session, including all thoughts and metadata. |
|
|
| Markdown trace of a reasoning session (full content). |
|
|
| Markdown content of a single thought (for example |
Prompts
Prompt | Arguments | Description |
| none | Return server usage instructions. |
|
| Basic-depth reasoning (1-3 thoughts). |
|
| Normal-depth reasoning (4-8 thoughts). |
|
| High-depth reasoning (10-15 thoughts). |
|
| Expert-depth reasoning (20-25 thoughts). |
|
| Continue an existing session. Optional follow-up query. |
|
| Retry a failed reasoning task with modified parameters. |
MCP Capabilities
Capability | Status | Evidence |
| confirmed |
|
| confirmed |
|
| confirmed |
|
| confirmed |
|
| confirmed |
|
| confirmed |
|
| confirmed |
|
Tool Annotations
Annotation | Value | Evidence |
|
|
|
|
|
|
|
|
|
|
|
|
Structured Output
reasoning_thinkdeclaresoutputSchemaand returnsstructuredContent, with an embedded trace resource when the trace is small enough. Evidence:src/tools/reasoning-think.ts:498,src/lib/mcp.ts:97-114.
Configuration
Variable | Default | Required | Evidence |
|
| no |
|
|
| no |
|
|
| no |
|
|
| no |
|
|
| no |
|
The source does not define any HTTP host/port configuration. The only other environment-related signal isNODE_ENV=production in the Docker image and --env-file=.env in the local dev:run script.
Security
Control | Status | Evidence |
input validation | confirmed |
|
stdout-safe logging fallback | confirmed |
|
main-thread-only runtime | confirmed |
|
non-root container user | confirmed |
|
No auth, OAuth, HTTP origin checks, or rate-limiting controls are implemented in the current source because the server only exposes stdio transport.
Development
Script | Command | Purpose |
|
| Watch and compile source during development. |
|
| Run the built server in watch mode with an optional local |
|
| Clean |
|
| Run ESLint across the repository. |
|
| Run source and test TypeScript checks concurrently. |
|
| Run the TypeScript test suites with the configured loader. |
|
| Rebuild first, then run tests against the built output. |
|
| Run the fast direct test command without the task wrapper. |
|
| Format the repository. |
|
| Build the server and open it in the MCP Inspector. |
|
| Enforce release checks before publishing. |
Additional helper scripts for diagnostics, coverage, asset copying, and knip are defined in package.json.
Build and Release
.github/workflows/release.ymlbumpspackage.jsonandserver.json, then runsnpm run lint,npm run type-check,npm run test, andnpm run buildbefore tagging and creating a GitHub release.The same workflow publishes the package to npm with Trusted Publishing, publishes to the MCP Registry with
mcp-publisher, and pushes a multi-arch Docker image toghcr.io.Dockerfileuses a multi-stage Node 24 Alpine build, prunes dev dependencies, and runs the released container as themcpuser.
Troubleshooting
Sessions are in memory and expire after 30 minutes by default. If you receive
E_SESSION_NOT_FOUND, start a new session or increaseCORTEX_SESSION_TTL_MS.runMode="run_to_completion"requires enoughthoughtentries to cover the remaining steps. If you want the server to return after each step, keep the defaultstepmode.For stdio transport, do not add custom stdout logging around the server process. This server routes logs through MCP logging and falls back to
stderron failures.
Credits
Dependency | Registry |
npm | |
npm |
Contributing and License
License: MIT
Contributions are welcome via pull requests.
Available Tools
1 toolreasoning_thinkReasoning ThinkA
Structured multi-step reasoning tool. Decomposes analysis into sequential thought steps stored in a persistent session trace.
USAGE PATTERN:
Start: { query: "...", level: "basic"|"normal"|"high"|"expert", thought: "your analysis..." }
Continue: { sessionId: "", thought: "next step..." } — level is optional; session level is used
Repeat until status: "completed" — the summary field contains the exact next call to make
IMPORTANT: Pass the returned sessionId on every continuation call. The thought parameter stores YOUR reasoning verbatim — write thorough analysis in each step. Use stepSummary for a 1-sentence conclusion per step — these accumulate in the summary field for navigation.
Levels: basic (1–3 steps, 2K budget), normal (4–8 steps, 8K budget), high (10–15 steps, 32K budget), expert (20–25 steps, 128K budget). Alternatives: runMode="run_to_completion" (batch, basic level only), or observation/hypothesis/evaluation fields (structured). Errors: E_SESSION_NOT_FOUND (expired — start new), E_INVALID_THOUGHT_COUNT (check level ranges).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Question or problem to analyze. | |
| level | No | Depth level. Required for new sessions. basic (1–3 steps, 2K budget), normal (4–8 steps, 8K budget), high (10–15 steps, 32K budget), expert (20–25 steps, 128K budget). | |
| targetThoughts | No | Exact step count. Must fit level range. | |
| sessionId | No | Session ID to continue. | |
| runMode | No | "step" (default) or "run_to_completion" (basic level only). | |
| thought | No | Reasoning text. Stored verbatim. String for step mode, string[] for batch. | |
| isConclusion | No | End session early at final answer. | |
| rollbackToStep | No | 0-based index to rollback to. Discards later thoughts. | |
| stepSummary | No | One-sentence step summary. | |
| observation | No | Known facts at this step. | |
| hypothesis | No | Proposed next idea. | |
| evaluation | No | Critique of hypothesis. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| result | No | |
| error | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, and the description adds extensive behavioral context: thought is stored verbatim, sessionId must be passed on continuation, levels have step and budget ranges, and the summary field contains the next call. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (usage pattern, levels, alternatives, errors) and front-loaded with the main purpose. It is fairly long but each section earns its place. Slightly verbose, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, 100% schema coverage, output schema exists), the description covers all necessary aspects: workflow, levels, budgets, errors, and alternatives. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. However, the description adds significant workflow context (e.g., usage of sessionId, thought, stepSummary, and the difference between step and batch modes) that enhances understanding beyond the schema. This justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Structured multi-step reasoning tool' and explains it decomposes analysis into sequential thought steps stored in a persistent session trace. There are no sibling tools, so differentiation is not needed. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed usage pattern with start/continue/repeat steps, explicitly mentions alternatives like runMode='run_to_completion' and structured fields (observation/hypothesis/evaluation), and lists error codes. This gives clear guidance on when to use the tool and how to proceed.
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.
1 tool update
v1.11.0- First observed
reasoning_think
TDQS
With only one tool, there is no risk of confusing it with other tools. The tool's purpose is clearly defined as structured multi-step reasoning.
The single tool name 'reasoning_think' follows a clear verb_noun pattern (verb 'think' with noun 'reasoning' as modifier), and consistency is not an issue with only one tool.
One tool is minimal but appropriate given the focused domain of reasoning. The tool is complex with multiple levels and modes, so it earns its place, but the count feels slightly thin for a general MCP server.
The tool covers the full lifecycle of multi-step reasoning: start, continue, complete, with support for different levels and modes. No obvious gaps for a reasoning-only server.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Agent-to-agent reasoning-as-a-service: chain-of-thought, analysis, and decision support.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Memory for deep conversational context across any platform
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides AI assistants with enhanced reasoning capabilities through structured thinking, persistent knowledge graph memory, and intelligent tool orchestration for complex problem-solving.202561MIT
- AlicenseAqualityAmaintenanceEnables structured, iterative reasoning for complex problem-solving with features like confidence tracking, revision mechanisms, and branching support. Provides flexible validation and multiple output formats for systematic analysis and decision-making tasks.12272MIT
- AlicenseBqualityNot gradedmaintenanceEnables AI assistants to perform structured, step-by-step reasoning by breaking down complex problems into numbered thoughts, with support for revising previous steps and exploring alternative reasoning paths.5-
- AlicenseAqualityBmaintenanceEnables structured step-by-step reasoning with branching, revisions, and self-critique to help break down complex problems into manageable steps with confidence tracking and thought history search.7197MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/j0hanz/cortex-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server