Skip to main content
Glama
AiDimag

AI Dimag

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AIDIMAG_REPOYesThe absolute or relative path to the repository that AI Dimag should use as its memory scope. This is required for the MCP server to know which codebase to operate on.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
memory_searchA

Search the repo's verified memory for decisions, conventions, gotchas, failed approaches, and invariants. Use BEFORE exploring the codebase — past sessions may already know the answer.

memory_get_for_filesA

Get all memories relevant to specific files before editing them — conventions, gotchas, and invariants that apply to those paths.

memory_writeA

Persist a new memory about this codebase. Write the claim as a FALSIFIABLE statement (something that could be checked against the code). Attach evidence whenever possible. For kind=GUARDRAIL, set guardrail_level (never|always|ask-first).

memory_refuteA

Mark a memory as REFUTED when you discover it no longer holds. Optionally provide the id of a new memory that supersedes it. Refuted memories are kept as negative knowledge.

memory_statusA

Get a summary of the repo's memory store: counts by verification status and kind.

scratchpad_writeA

Jot a SHORT-TERM working note for the current session: intermediate findings, plans, hypotheses, task state. Auto-expires (default 24h) and is never synced. NOT durable memory — use memory_write/memory_propose for knowledge that should persist across sessions.

scratchpad_readA

Read short-term working notes from the current session's scratchpad (newest first). Use at session start or when resuming a task to recover in-flight state. Expired notes are purged automatically.

scratchpad_clearA

Clear scratchpad working notes (one session key, or everything). Use when a task completes and its intermediate state is no longer needed.

memory_verifyA

Re-run cheap evidence checks (STATIC_CHECK, COMMIT_REF) and update memory statuses. Use before relying on VERIFIED memories if the repo may have changed, or to verify specific memories by id.

memory_proposeA

Propose a memory for the human review queue. Use at SESSION END for learnings that should persist but warrant review before becoming active memory. Prefer this over memory_write for inferred/uncertain knowledge.

memory_check_changeA

Pre-edit safety check: given a diff or a short description of a change you're about to make, return any FAILED_APPROACH, GUARDRAIL, INVARIANT, or CONVENTION memories that match. Call this BEFORE editing code when the task touches an area with known historical failures or explicit rules. Returns a decision: proceed, ask_first, or stop.

memory_pre_editA

Pre-edit guardrail check for a specific file and code snippet. Given a file path and the code you're about to write, check whether it violates any NEVER guardrails or triggers FAILED_APPROACH warnings. Returns a clear STOP/PROCEED decision. Call this before writing to files in protected areas.

context_noteA

Capture a durable fact the USER just stated in chat. Call this IMMEDIATELY when the user shares codebase knowledge — don't wait for session end. ALWAYS trigger on: 'we use X because Y' (DECISION), 'never do X' (GUARDRAIL), 'we always X' (CONVENTION), 'we tried X, it failed' (FAILED_APPROACH), 'the architecture is...' (ARCHITECTURE). Skip task-specific requests like 'fix this bug'. User-stated facts are queued for review with high trust (HUMAN_ATTESTED evidence).

chat_harvestA

Harvest the CURRENT chat session on the fly: pass the messages the USER typed this session (verbatim) and durable facts are extracted and queued for human review — the live, tool-agnostic equivalent of dim harvest. Works from ANY IDE/agent (Copilot, Cursor, Codex, Claude, Devin, …), including cloud tools with no local transcripts. Call at session end, or after a long exchange rich in project knowledge. Secrets are redacted server-side before any LLM sees the text. For single facts stated in passing, prefer context_note instead.

aidimag_helpA

Show what aidimag offers: available tools, prompts (slash commands), resources, and the companion dim CLI commands. Call this when the user asks what aidimag can do, how to use it, or types 'aidimag help' — then relay the overview to them.

memory_critiqueA

Review what you just did (or plan to do) against the project's VERIFIED memory and guardrails — a 'second critic' grounded in real, falsifiable beliefs rather than another model's opinion. Call BEFORE committing or proposing memories. Resolve guardrail violations and contradictions first.

ticket_getA

Fetch the ticket behind the current work (title, description, type, status) from the connected ticketing app. Use at session end: the ticket carries the WHY that commits lack. Omit the id to auto-detect it from the current branch name.

commits_mineA

Mine git commit history for memory-worthy candidates (same as dim mine). Queues proposals for dim review — never writes active memory directly. Use after meaningful commits, or with full=true to rescan all history.

proposals_pendingA

List memory proposals awaiting human review.

knowledge_pendingA

List documents waiting in the knowledge inbox to be summarized into pinned-on-approve memory proposals. Use with the knowledge_ingest prompt to process them in-session.

knowledge_ingest_submitA

Submit the FALSIFIABLE claims you extracted from a pending knowledge doc (see the knowledge_ingest prompt). Queues them as proposals (source knowledge:), writes the durable summary, backs up the original, and clears the inbox copy. Claims become PINNED memory only after dim review (unless the repo opted out).

Prompts

Interactive templates invoked by user choice

NameDescription
knowledge_ingestProcess the knowledge inbox in-session: read each pending doc, extract durable falsifiable claims, and submit them with knowledge_ingest_submit (queued for `dim review`).
session_end_extractionRun at the end of a coding session to extract durable codebase knowledge into the memory proposal queue.
helpShow everything aidimag offers in this session: tools, prompts (slash commands), resources, and companion `dim` CLI commands.
session_startRun at the START of a coding session: surfaces in-scope memory, guardrails, stale warnings, and clarifying questions to ask the user before writing any code.

Resources

Contextual data attached and managed by the client

NameDescription
help
instructions
session-briefing
digest

TDQS

A3.9/5.0

Scored across 21 tools

Disambiguation3/5

Most tools have distinct actions and detailed use-case descriptions, but there are overlapping clusters: memory_check_change vs memory_pre_edit both serve as pre-edit guardrails, and memory_write/memory_propose/context_note/chat_harvest/knowledge_ingest_submit all create or propose memory through different paths. An agent can usually pick correctly with careful reading, but the boundaries are not always crisp.

Naming Consistency4/5

Tool names overwhelmingly use snake_case verb_noun or noun_verb patterns within clear families (memory_*, scratchpad_*, knowledge_*). Minor deviations like ticket_get (reversed order), memory_status, knowledge_pending, and proposals_pending break the otherwise predictable pattern but remain readable.

Tool Count3/5

21 tools sits in the borderline-heavy range for an MCP server. The breadth is somewhat justified by the memory lifecycle, scratchpad, review queue, and external capture sources, but the surface could be tightened by merging the two pre-edit checks and consolidating capture tools.

Completeness4/5

The tool set covers the core memory lifecycle well: search, write, propose, verify, refute, and pre-edit checking, plus scratchpad and review queue visibility. Minor gaps exist—there is no direct update/edit tool for an existing memory and no in-MCP approval path, but these are workable through refute/supersede and the companion dim review flow.

Maintenance

ActivityActive
ResponsivenessNo issues