hypernmnesia-mcp-viz
This server is a read-only visualization layer for Cortex that renders memories, sessions, code, and knowledge into six interactive browser views — it never writes Cortex memories, only reads them.
Launch the browser UI via open_visualization (opens at 127.0.0.1:3458) with six reading angles:
Trace (default): Live drill-down of domains → sessions → prompts → actions → files, with per-file diffs and git history. Works fully from
~/.claudeJSONL logs and git — no Cortex or PostgreSQL required.Graph (galaxy): Force-directed 2D map with 6 concentric levels (setup, tools, files, discussions, memories, AST code symbols) and edges like
defined_in,calls,imports, andmember_of.Brain: 3D anatomical cortical mesh placing 278k+ nodes by neuroscience memory regions (MNI152 atlas), streamed progressively via NDJSON.
Board: Consolidation kanban with five columns (
labile,early_ltp,late_ltp,consolidated,reconsolidating), live stage counts, and advancement rules.Knowledge: Curated memory cards with meaning lines, feeling (word + valence/arousal), stage/domain badges, and measured meters (heat, importance, valence, arousal).
Wiki: Per-project knowledge base with a tree browser, dossier-style reader, and export to PDF, TEX, DOCX, or HTML.
Retrieve graph data as JSON via get_methodology_graph — returns {nodes, edges, meta} (capped at 200 nodes / 500 edges, highest-quality first) covering domains, concepts, memories, and entities with cross-domain bridges and semantic relationships. Suitable for programmatic use in custom visualizers — no browser launched.
No-DB mode: When PostgreSQL is unreachable or CORTEX_VIZ_NO_DB=1 is set, Trace remains fully live while the five DB-backed views grey out gracefully.
Host-neutral activity: Accepts POST /api/activity events (versioned JSON Schema) from any MCP host (Codex, Gemini, Cursor, etc.) to feed real-time tool calls, file accesses, and session actions into the graph.
Filtering: Both tools accept an optional domain parameter to scope results; open_visualization also accepts view to launch directly to a specific reading angle. Graph views support grouped filters by level (L1–L6), kind, AST edge kind, and cross-domain.
Auto-shutdown: The HTTP server shuts down after 10 minutes of idle; the call returns in ~200ms with lazy graph construction behind it.
Reads local git history to provide per-file diffs against HEAD, commit history, and codebase node graphs for files touched, read, searched, or referenced in sessions.
Reads Cortex's shared PostgreSQL memory store to power five database-backed visualization views including graph, 3D brain, knowledge browser, wiki, and consolidation board, while writing derived graph/layout caches to the same database.
The server is implemented in Python and runs as a stdio MCP process, but Python language symbols are one of 10 languages parsed into the AST symbol graph (L6).
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., "@hypernmnesia-mcp-vizopen the trace visualization for my last Claude Code session"
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.
Hypermnesia MCP Viz
Hypermnesia MCP Viz is published as hypermnesia-mcp-viz everywhere:
Python, MCP Registry, Claude Code, Codex, Gemini, and the console command.
The cross-platform visualization layer for Cortex. Codex, Gemini CLI, Claude Code, and any stdio MCP host can launch the same read-only server and browser UI. It turns Cortex's memory store, a host-neutral live activity stream, Claude Code's historical session archive, and your codebase graph into six live reading angles: a project galaxy, a 3D anatomical brain, an execution trace, a consolidation kanban, a curated knowledge browser, and a wiki. It never writes a memory: it renders, it never remembers. (It does keep its own derived graph/layout caches in the Cortex database, listed under Boundary.)
Launch with the open_visualization tool (or /cortex-visualize). One launcher opens six reading angles; the default landing view is Trace.
The whole UI ships on the AI Architect design system: a paper-first reading surface with a persistent ink (night) toggle, greyscale chrome, and a data palette resolved from design tokens at runtime, flipping the surface re-inks every view in place without disturbing a settled layout, and every count on screen is exact and streamed, never rounded.
Getting Started
Claude Code users can install Hypermnesia MCP Viz from the same
cortex-plugins marketplace as Cortex:
claude plugin marketplace add cdeust/Cortex
claude plugin install hypermnesia-mcp-viz@cortex-pluginsThis install name becomes available in the Cortex marketplace only when this
repository and the matching marketplace change in
cdeust/Cortex#351 are released
together. Maintainers must not publish either half of the rename on its own.
Migrating from cortex-viz
Existing Claude Code installs are not aliases for the new plugin identity. Remove the old install, refresh the marketplace after the coordinated release, and install the canonical plugin:
claude plugin uninstall cortex-viz@cortex-plugins
claude plugin marketplace update cortex-plugins
claude plugin install hypermnesia-mcp-viz@cortex-pluginsClaude composes plugin tool names from the plugin manifest name, the
mcpServers key, and the tool name. Update both old full names wherever they
appear in permission allowlists, hooks, skills, or agents:
mcp__plugin_cortex-viz_cortex-viz__open_visualizationbecomesmcp__plugin_hypermnesia-mcp-viz_hypermnesia-mcp-viz__open_visualization.mcp__plugin_cortex-viz_cortex-viz__get_methodology_graphbecomesmcp__plugin_hypermnesia-mcp-viz_hypermnesia-mcp-viz__get_methodology_graph.
The removed cortex-viz console command is not retained as an alias, so
Cursor, Windsurf, VS Code, and other direct-process configurations must invoke
hypermnesia-mcp-viz instead.
Hypermnesia MCP Viz is a companion to Cortex that never writes a memory. Install Cortex first (
claude plugin install hypermnesia-mcp@cortex-plugins): the visualizer reads its shared PostgreSQL store, and writes only its own derived caches there (Boundary). Point both at the same database: thedatabase_urlplugin setting defaults topostgresql://127.0.0.1:5432/cortex; set it to the same value you gave Cortex.
Restart your Claude Code session, then launch the visualizer:
/cortex-visualizeCodex, Gemini CLI, and other MCP hosts launch the same server as a plain stdio process; see Other MCP hosts for the exact configuration.
One launcher opens all six reading angles (Graph · Brain · Trace · Knowledge · Wiki · Board) in the browser, served live from the Cortex store, your session JSONL, the code graph, and git.
Works without Cortex
No Cortex, no PostgreSQL, no setup: Hypermnesia MCP Viz is still useful on its own. The Trace view (the default landing view) reads only ~/.claude/projects/*.jsonl and your local git: every Claude Code session becomes a navigable domain → session → prompt → action → file chain, with per-file diffs and commit history. If you use Claude Code, the data is already on your disk.
Just install the plugin and run
/cortex-visualize. When Cortex's database isn't reachable, the server logs one line and starts in no-DB mode automatically: Trace is fully live; the five DB-backed views (Graph, Brain, Knowledge, Wiki, Board) appear greyed out with an install pointer instead of erroring.To skip the database probe entirely, set
CORTEX_VIZ_NO_DB=1(or pass--no-dbwhen running the standalone server directly).
Installing Cortex later lights up the other five views against the same UI (no reconfiguration).
Clone + run from source:
git clone https://github.com/cdeust/cortex-viz.git && cd cortex-viz
pip install -e .
DATABASE_URL=postgresql://127.0.0.1:5432/cortex python3 -m cortex_viz
# Without Cortex/Postgres (Trace view only):
CORTEX_VIZ_NO_DB=1 python3 -m cortex_vizRelated MCP server: memora
The views
Graph: the Claude workflow map
Each project becomes a cloud of nodes around one gold domain hub. Inside every cloud, nodes sit in six concentric levels by the Claude surface (or the code itself) that produced them:
Level | What's there | Click through to |
L1 · Setup | Skills · Commands · Hooks · Agents · MCPs | File paths; which domains share an MCP (thin indigo bridges) |
L2 · Tools | One hub per Claude tool per domain (Edit · Write · Read · Grep · Glob · Bash · Task) | Files touched + total uses |
L3 · Files | Every file Claude opened, read, edited, searched, or referenced, colored by primary tool |
|
L4 · Discussions | One node per Claude Code session |
|
L5 · Memories | Persistent memories, colored by consolidation stage | Full content, tags, every scientific measurement |
L6 · AST symbols | The code itself: functions, methods, classes, modules, constants parsed from 10 languages (Rust, Python, TypeScript, Java, Kotlin, Swift, Objective-C, C, C++, Go) | Qualified name, symbol type, parent file, and named |
Why L6 matters. L5 and below tell you what Claude did; L6 tells you what the code is. Three things become visible for free: shared code (any symbol referenced by two projects drifts into the inter-project gap), impact (clicking a symbol surfaces every caller, importer, and member: "what breaks if I change this?" is a graph neighbourhood, not a grep), and the shape of the codebase itself (a dense petal around a file means a fat internal API; a thin one means a leaf module). A grouped filter (L1–L6 / by kind / by AST edge kind / Cross-domain) isolates any slice.
Brain: the galaxy inside a real cortex
The same graph, on a second surface: every node placed inside an anatomical cortical mesh by the neuroscience of memory systems rather than by force-direction. Episodic memories sit in the medial temporal lobe and migrate outward to neocortex along a hot→consolidated depth gradient (the complementary-learning-systems consolidation model); semantic entities in temporal neocortex; code symbols in association cortex; procedural skills in the striatum and cerebellum; domains at the connectome's rich-club hubs. Region centres are registered from real MNI152 atlas coordinates (affine fit, not vertex-exact; the mesh is a single unlabeled surface). Every synapse routes along a major white-matter tract (fornix, uncinate, SLF, corpus callosum). Node colour is the same semantic palette as the galaxy (memories by consolidation stage, entities/symbols by type), and a live Memory science panel mirrors the store's system vitals (consolidation pipeline, skills, source-monitoring, extinction, sleep phases, and every mechanism Cortex exposes).
Because the full graph (278k+ nodes, 5.5M edges) is far larger than a browser can take in one payload, the brain streams it in progressively through a bounded-queue, frame-budgeted NDJSON loader: the cloud fills in as you watch. Clicking any node opens the same rich detail card as the galaxy (content, tags, live heat, relations, git diff, impact). Open it from the Brain button in the view bar, directly at /brain, or programmatically via open_visualization(view="brain").
Board: consolidation as a kanban
Five columns by consolidation stage (labile · early_ltp · late_ltp · consolidated · reconsolidating). Each header states the stage's live count (server-side truth, not the loaded page) above its reference stage physics (decay ×, vulnerability %, plasticity %) and the stage's advancement rule (e.g. replays ≥ 1 or imp > 0.3 at labile, replays ≥ 3 at early_ltp). Those physics rows and advance rules are constants from the DD-02 stage spec, not per-bucket medians recomputed live. Cards carry live heat, importance, surprise, valence, arousal, and the exact tool that created the memory.
Detail panel: every measurement explained. Clicking any node opens a panel with the raw value and a one-line plain-language explanation. Consolidation stage, activity (heat), importance, surprise, emotional tone and intensity, confidence, plasticity, stability: each a labeled bar with a sentence like "How unexpected this memory was when it arrived. Surprises stick better than routine events."
Trace · Knowledge · Wiki
Trace (default): the live execution-trace drill: collapsed domain hubs → sessions → the ordered prompt → action → file chain of what actually happened → a file's AST symbols, impact neighbourhood, and git history. Discussions and Cortex
remember/recallops are woven into the chain. Served live from session JSONL, the code graph, and git on every request (no snapshots, always current).Knowledge: curated memory cards with the feeling (word + signed valence/arousal, never colour alone), the MEANING line and verbatim excerpt, stage/domain/HOT badges, and four measured meters in fixed order (heat · importance · valence · arousal; a zero shows an empty track, never hides); filter by domain, stage, or feeling with exact facet counts.
Wiki: the per-project knowledge base as a browsable Project → Kind → Pages tree with a dossier-style page reader: serif prose with numbered section heads and mono identifier chips, boxed status and kind badges, dated provenance, and an Edit · PDF · TEX · DOCX · HTML export strip. A CodeMirror split-pane editor with live preview sits behind Edit. (The wiki content is authored autonomously by Cortex; Hypermnesia MCP Viz is its reading + editing surface.)
Install
Hypermnesia MCP Viz is a cross-platform MCP server with a Claude Code plugin. Point it at the same database as your Cortex install: it reads Cortex's memories from that store and never writes them.
As a plugin: ships the MCP server, the /cortex-visualize skill, and the live session-activity hooks. The bundled scripts/launcher.py bootstraps its own dependencies on first launch (no manual pip needed). Configure the DB via the plugin's database_url user-config (defaults to postgresql://127.0.0.1:5432/cortex).
As a raw MCP (v3.1.0 and later):
pip install "hypermnesia-mcp-viz[data,viz-tile]" # optional PG and large-graph extras
hypermnesia-mcp-viz # or: python -m cortex_viz (stdio MCP transport)The published 2.8.0 hypermnesia-mcp-viz distribution owned the legacy
cortex-viz console shim; there was no separate Python distribution by that
name. Upgrade with the same interpreter/environment that installed it, and the
installer removes the old distribution-owned shim while installing 3.1.0
(the distribution-identity rename that removes the shim was cut into the tree
as 3.0.0, but that version was never tagged or published — see the
CHANGELOG's [3.0.0] entry — so 3.1.0 is the first published release that
carries it):
python3 -m pip install --upgrade "hypermnesia-mcp-viz>=3.1.0"If cortex-viz still resolves, first locate every shim and ask Python which
installed distribution owns that console entry point:
type -a cortex-viz
python3 - <<'PY'
from importlib import metadata
owners = []
for distribution in metadata.distributions():
if any(
entry.group == "console_scripts" and entry.name == "cortex-viz"
for entry in distribution.entry_points
):
owners.append((distribution.metadata["Name"], distribution.version))
print(owners or "no Python distribution owns cortex-viz in this interpreter")
PYUninstall the reported distribution with that same interpreter, or remove a manually installed shell/file shim through the tool that created it when no distribution owns it. Do not guess a distribution name from the executable.
Set DATABASE_URL to the shared Cortex database. open_visualization launches the galaxy UI in the browser, bound to 127.0.0.1.
Other MCP hosts
Any MCP host can launch the server: it is a plain stdio process. Install it with pip install hypermnesia-mcp-viz, then register hypermnesia-mcp-viz as both the server name and command in your host's MCP config (Gemini CLI ~/.gemini/settings.json, Cursor .cursor/mcp.json, Windsurf ~/.codeium/windsurf/mcp_config.json, VS Code .vscode/mcp.json under "servers", or Codex CLI: codex mcp add hypermnesia-mcp-viz -- hypermnesia-mcp-viz). The equivalent Python module form is python3 -m cortex_viz. The open_visualization tool opens the UI in the browser. The historical Trace archive still reads Claude Code JSONLs under ~/.claude/projects/, but live activity is host-neutral: a Codex, Gemini, or generic MCP adapter can POST the versioned schema below to the local /api/activity endpoint. The galaxy/brain/knowledge/wiki/board views still need a Cortex store to read.
Host-neutral live activity
POST /api/activity accepts the JSON Schema contract in
docs/host-event-v1.schema.json alongside
the existing Claude hook payload. Producers identify their host explicitly;
tool names are provenance and are not reinterpreted as Claude tools.
{
"schema_version": "1",
"host": "codex",
"session_id": "01J...",
"timestamp": "2026-08-02T12:34:56Z",
"event": "tool_call",
"tool": "read_file",
"input_summary": "Read the authentication module",
"artifact": "src/auth.ts",
"result": "success",
"cwd": "/workspace/project"
}The endpoint normalizes the event into the same session/action/target graph as
Claude activity. Producers can report mcp_call, api_call, db_read and
db_write explicitly in addition to prompts, tools, files, terminal commands,
skills, subagents and web access. API/database targets come from the producer's
artifact; input/result summaries are displayed as observed and are never
inferred from a tool name. Host-specific hook or telemetry adapters can be
added independently without changing the graph or database schema.
Boundary
Hypermnesia MCP Viz consumes Cortex's artifacts on disk + PostgreSQL, never Cortex's live Python objects:
Data | Source |
Memories, entities, relationships (graph nodes) | Cortex PG store (shared |
Wiki pages + thermodynamic state |
|
Sessions / execution traces |
|
Cognitive profiles |
|
Codebase graph (AST symbols, impact) |
|
PRD document/section nodes |
|
Written by Hypermnesia MCP Viz (its own tables, in the same PG database) |
|
No import mcp_server.* is permitted anywhere in cortex_viz/: that invariant is the extraction's correctness check.
MCP tools
open_visualization (launch the browser UI: pass view="brain" for the 3D anatomical brain, view="galaxy" or omit for the 2D graph) and get_methodology_graph (graph data). The six views are served over HTTP by the server open_visualization launches; a live session-activity stream (every tool call, MCP call, file access, skill, and command) feeds the graph in real time via the activity-capture hooks.
Project
Document | What it answers |
How to contribute, the coding style, and the test requirement | |
Who decides, who has which role, and how a fork can continue the project without original credentials | |
Expected behaviour and how to report a problem | |
What Hypermnesia MCP Viz accesses, the supply-chain assurance, and how to report a vulnerability | |
What is read, what is written, and what leaves your machine | |
The layers, the read contract, and the trust boundaries | |
The threat model and why the security requirements are met, including where the argument is incomplete | |
Direction, known gaps, and what is explicitly not planned | |
What changed in each release |
Achievements
OpenSSF Best Practices Silver: project 13846 earned Silver on 2026-08-03. Answers for every passing and Silver criterion are committed in
.bestpractices.jsonand audited against this repository rather than copied.OpenSSF Scorecard: runs weekly (
scorecard.yml). Current score 7.4 (2026-08-03), including the Silver badge and zero known vulnerabilities.Build provenance: all four v2.8.0 artifacts — wheel, source archive, CycloneDX SBOM, and UI manifest — have independently verified Sigstore-backed attestations. Verify any downloaded artifact with
gh attestation verify <file> --repo cdeust/cortex-viz.
Status
The visualization stack was extracted from Cortex (which is now a focused memory engine) so the graphics ship and scale on their own. Standalone MCP boots over stdio; all six views are bridged to live data; the galaxy builds end-to-end at 75k+ nodes; the 3D brain streams the full graph into a cortical mesh; the whole UI sits on the AI Architect design system (paper/ink surfaces, token-resolved palette); the suite passes.
Available Tools
2 toolsget_methodology_graphGet methodology graphARead-onlyIdempotent
Build the methodology map as JSON graph data {nodes, edges, meta} suitable for force-directed visualization. Nodes: domains, concepts, memories, entities. Edges: cross-domain bridges, co-activation strengths, semantic relationships. Output is capped (200 nodes / 500 edges, highest-quality first) so the payload stays embeddable in a single MCP response. Use this to feed a CUSTOM client visualizer. Distinct from open_visualization (launches the bundled browser UI on 127.0.0.1:3458, no JSON returned), list_domains (text-only domain overview), and get_causal_chain (entity-graph BFS, not the unified methodology map). Read-only on profiles.json + memories. Latency <100ms. Returns {nodes, edges, meta, truncated_nodes?, truncated_edges?}.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover safety. The description adds valuable behavioral detail beyond annotations: output caps (200 nodes/500 edges), highest-quality-first truncation, latency <100ms, and read-only on profiles.json + memories. It doesn't note any side effects or error conditions, but the read-only nature plus caps is solid coverage given 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?
Four dense sentences, each earning its place: purpose, output structure, safety, and performance/cap limits. The truncation detail and latency are front-loaded with the purpose. No fluff, no repetition. Highly 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?
Despite having an output schema, the description thoroughly explains the return shape ({nodes, edges, meta}, with optional truncation fields), the caps, and the visualization use case. With annotations covering safety and idempotency, and the description covering purpose, alternatives, caps, latency, and read-only scope, there is nothing significant left unexplained.
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?
There is only 1 parameter (domain, optional, nullable) with 0% schema description coverage. The description mentions 'domains' as node types but does not explicitly explain what the 'domain' parameter filters or how null vs a value changes behavior. Since the parameter is optional and there's only one, the baseline expectation is that the description explains its effect—it doesn't, though the tool works without it.
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 the tool builds a methodology map as JSON graph data for force-directed visualization, listing node and edge types specifically. It explicitly distinguishes from three sibling tools with specific differentiators, making the purpose 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 explicitly names three alternatives (open_visualization, list_domains, get_causal_chain) and explains what each does differently, giving the agent clear when-to-use and when-not-to-use guidance. It also states this feeds a custom client visualizer, establishing the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_visualizationOpen visualizationARead-onlyIdempotent
Open the bundled Cortex visualization in the user's default browser — a force-directed neural graph combining methodology profiles, memory nodes, and the knowledge graph, plus the Wiki, Atlas, Emotion, Board, Pipeline, and Knowledge views. Starts the local HTTP server on 127.0.0.1:3458 if not already running and auto-shuts-down after 10 minutes of idle. Use this for visual exploration, screenshots, or presenting Cortex state. Distinct from get_methodology_graph (returns JSON for a CUSTOM client, no browser launched, no auxiliary views) and list_domains (text overview, no graph). Side effects: spawns an HTTP server process and opens a browser tab. The CALL itself returns in ~200 ms (server warmup + browser launch); the GRAPH build is lazy — kicked when the page polls /api/graph/progress (i.e. when the user opens the Graph view). First paint of the skeleton lands in ~1 s; the full graph fills in behind it and depends on the DB size (seconds for typical, ~1-3 min on a 100k+ memory store). Works WITHOUT Cortex too: when its PostgreSQL is unreachable (or CORTEX_VIZ_NO_DB=1 / --no-db is set) the server starts in no-DB mode — the Trace view is fully live from ~/.claude session logs + git, and the five DB-backed views (Graph, Brain, Knowledge, Wiki, Board) appear greyed out with an install pointer instead of erroring. Returns {url, message, dev_source, bootstrap, layout}.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | galaxy | |
| domain | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing side effects (HTTP server process, browser tab, idle auto-shutdown), lazy graph build, performance timelines, and the no-DB degradation mode. It also states the returned fields and the nature of the call, all without contradicting the readOnly/openWorld/idempotent hints.
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 long but well-organized, front-loaded with the core purpose and then detailing side effects, performance, and fallback. While every sentence adds value, the length could be trimmed slightly without losing essential information.
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?
It covers purpose, usage context, side effects, performance characteristics, fallback behavior, and return value shape. Given the tool's complexity and the presence of an output schema, this description provides complete contextual coverage for an agent to select and invoke the tool confidently.
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?
The schema has 0% coverage (no parameter descriptions), and the description does not explain what `view` or `domain` expect. It mentions several visualization views (e.g., Wiki, Atlas, Graph) but never maps them to the `view` parameter values, and `domain` is entirely unaddressed. This is a clear gap for correct invocation.
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 the tool opens the bundled Cortex visualization in the user's default browser and enumerates the included views. It also explicitly distinguishes it from sibling tools `get_methodology_graph` and `list_domains`, making the purpose 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?
It provides explicit usage guidance: 'Use this for visual exploration, screenshots, or presenting Cortex state.' It also names alternatives and contrasts them, and explains the no-DB fallback scenario, giving the agent clear conditions for when to use this tool.
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.
2 tool updates
v0.0.0- First observed
get_methodology_graph - First observed
open_visualization
TDQS
With only one tool exposed in this server, the ambiguity risk is with tools referenced in the description (open_visualization, list_domains, get_causal_chain) that may or may not actually exist in other servers. The single tool is well-described and clearly distinguished from the referenced alternatives, but the actual tool set provides no way to verify these distinctions.
The single tool 'get_methodology_graph' uses a clear get_noun_graph pattern, which is readable and consistent. However, with only one tool, there is no pattern to evaluate across the set, and the referenced tools (open_visualization, list_domains, get_causal_chain) suggest mixed conventions that cannot be assessed in this server alone.
A single tool feels extremely thin for what appears to be a visualization-oriented MCP server. The description references multiple related tools (open_visualization, list_domains, get_causal_chain) that would be natural companions in the same server, making the lone tool seem like an incomplete surface.
The server only exposes graph-export functionality for visualization. Based on the description's references to browser launching, domain listing, and causal chain traversal, there are clear gaps: no way to launch the visualizer, no text overview, and no entity-graph traversal from this server. The JSON export alone is a fragmented piece of a larger intended workflow.
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
Native Clarity decision mapping, MindScan episode reflection, and read-only evidence tools.
A self-improving memory layer. Your memory, notes, tasks and goals, remembered everywhere.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides screen capture, OCR text extraction, and visual language model scene understanding capabilities with continuous monitoring and automatic memory storage integration.-
- AlicenseAqualityAmaintenancePersistent memory with knowledge graph visualization, semantic/hybrid search, importance scoring, and cloud sync (S3/R2) for cross-session context management.43715MIT
- AlicenseBqualityCmaintenancePersistent 4-tier AI memory (episodic, semantic, project, procedural) with temporal scoring, contradiction detection, entity tracking, and real-time desktop visualization orb.722MIT
- FlicenseBqualityDmaintenanceTransforms markdown documents into immersive 3D visualizations using semantic analysis and spatial layout, enabling navigable knowledge structures.72-
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/cdeust/cortex-viz'
If you have feedback or need assistance with the MCP directory API, please join our Discord server