How do I use DiffMind?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DiffMind document changes for user authentication implementation" 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.

DiffMind

by akay1121

Overview Schema Related Servers Score Discussions

TypeScript

Local

DiffMind

Your AI writes the code. DiffMind makes sure it explains why.

License: MIT MCP Claude Code

English · 简体中文

Vibe coding lets AI ship features fast. DiffMind makes sure you still own the project.

When you tell your AI agent "add user authentication", it writes the code and the feature works. Three weeks later you want to change the logout flow, but you don't know where sessions are stored, how token refresh works, or why it didn't use OAuth. You've become a stranger to your own codebase.

This is the hidden cost of vibe coding: you know what features exist, but not why they were designed this way, what trade-offs were made, or how to safely change them. You lose ownership. Maintenance becomes archaeology. Technical debt piles up because you're afraid to touch code you don't understand.

DiffMind closes this gap. It's an MCP server for Claude Code that forces AI agents to explain every decision — not just "what I did", but "why this approach", "what I rejected", and "what trade-offs I accepted". You get the speed of AI-assisted development with the deep understanding of hand-written code.

You: "Add email/password login with session-based authentication"

Claude (via DiffMind):

Calls start_session("实现用户登录功能：邮箱+密码，带会话保持")
Writes code across three files...
Calls explain_change():
- Why: "Passwords are hashed with bcrypt (cost 12) rather than stored in plaintext, so a database leak doesn't hand over usable credentials. Auth state is kept in a server-side session keyed by an httpOnly cookie instead of a JWT: for an MVP with a single backend we don't need statelessness, and sessions let us revoke a login instantly."
- Rejected: JWT (stateless is a benefit we don't need yet), OAuth (overkill for MVP), SHA-256 with static salt (fast hashes are wrong tool for passwords)
- Trade-offs: "Sessions require server-side storage, so the backend is no longer stateless — horizontal scaling later needs Redis, not the in-memory store"
- Verification: "npm test -- auth/login → 4 passing; manual POST /login with seeded user returns 200 + Set-Cookie"

You: (end conversation)

DiffMind Stop hook displays:

● created  ◐ modified  ⊗ deleted  ○ unchanged

○ Express                         [unchanged]
├─● loginHandler                  [created]
│  ├─● validateInput              [created]
│  ├─● User.findByEmail           [created]
│  ├─○ bcrypt.compare             [unchanged]
│  └─● SessionService.create      [created]
└─● sessionMiddleware             [created]

Three weeks later:

You: "Why didn't we use JWT for auth?"

Claude: (calls list_changes() and then recall_change(id) → recalls the stored explanation)

"Sessions over JWT because for an MVP with a single backend we don't need statelessness, and sessions let us revoke a login instantly by deleting a row — JWT would require building token refresh/blacklist machinery. The trade-off: the backend now holds state, so horizontal scaling later needs Redis."

Result: You understand past decisions without archaeology.

Related MCP server: codex-fusion-mcp

Keeps your context clean

DiffMind keeps documentation costs out of your main conversation. Your coding agent delegates explanation writing to a subagent: the subagent reads the diff, composes the full explanation, and calls explain_change itself, so the prose, diff reading, and quality-gate revisions never touch your context—you get back one line. Session digests display straight to your terminal via the Stop hook, which never enters model context at all.

What stays out of your context:

Explanation prose (150-800 tokens each)
Diff reading for explanations (varies)
Quality-gate retry loops (unpredictable)
Digest markdown (500-2,000 tokens)

What still costs context:

Task delegation call + rationale seed (50-150 tokens)
One-line result (10-20 tokens)

Token economics

DiffMind saves tokens in realistic usage (4+ explanations per session, or any recall/onboarding). After 4-5 explanations or a single recall query, you're net positive on tokens; for onboarding to an unfamiliar codebase, the project overview saves 10k-30k tokens of cold exploration.

Why existing tools fall short

	Git commits	Chat history	Code review	DiffMind
What changed	✅	partial	✅	✅
Why this approach	❌	buried	sometimes	✅ enforced
Rejected alternatives	❌	lost	rarely	✅ required
Trade-offs accepted	❌	❌	sometimes	✅ required
Maintains ownership after AI coding	❌	❌	❌	✅
Quality enforced at write	❌	❌	human effort	✅ blocked
Searchable + commitable	✅	❌	❌	✅

Git history tells you what changed. Chat logs record a conversation that's forgotten next session. Code review catches problems after the fact, when changing course is expensive.

DiffMind is the only tool that captures the AI's reasoning before the code is saved — and rejects it if the reasoning is vague.

Why DiffMind?

The Problem: Vibe Coding Amnesia

You tell Claude "add user authentication" and boom — feature done. Three weeks later you need to modify the logout flow, but:

Where are sessions stored? (Redis? Memory? Database?)
Why didn't we use OAuth? (Security? Complexity? Time?)
How does token refresh work? (Auto? Manual? Interval?)

You've become a stranger to your own codebase. The AI knew the answers when it wrote the code. You never did.

The Solution: Structured Decision Documentation

DiffMind forces the AI to explain:

Why this approach — rationale with substance, not filler
What was rejected — alternatives considered and why they didn't fit
What trade-offs — nothing is free, what did we sacrifice?
How it was verified — testing, edge cases, confidence level

And it enforces quality:

Blocks explanations with filler phrases ("better maintainability", "cleaner code")
Detects when rationale just repeats the summary
Requires alternatives for structural changes
Demands verification for "verified" confidence claims

Result: You get AI speed + human understanding. Maintenance becomes informed decision-making, not archaeology.

An Evolving CLI That Learns You

Unlike static documentation tools, DiffMind builds a profile of what you don't know:

Detects knowledge gaps from patterns: custom requirements with "step by step" / "eli5" / "basic explanation", or recalling the same topic 3+ times
Tracks topics you repeatedly struggle with (not your strengths)
Remembers your preferred explanation style

Result: Over time, explanations become increasingly tailored to fill your gaps, not generic ones.

Example: You struggle with Redis caching. DiffMind notices you've recalled "Redis" explanations 4 times. Next time a change involves caching, the explanation includes:

"Redis is an in-memory data store (like a super-fast database in RAM)"
Step-by-step: how the cache invalidation works
Visual analogy: "Think of it like a notepad next to your desk vs. a filing cabinet"

The more you use it, the better it gets at explaining to you.

How it works

Developer starts a session → AI writes code → AI calls explain_change()
       ↓                                              ↓
  goal recorded                    rationale + rejected alternatives + trade-offs
                                   pass quality gate → saved to .diffmind/
                                   ↓
                              session closed → digest Markdown generated
                                              call chain diff (Mermaid)
                                              commit message drafted

Every explanation lives in .diffmind/ — plain JSON + Markdown, commitable alongside your code, diffable in PRs, readable without any tooling.

Quick start

From the root of the Git repository where you use Claude Code:

npx -y --package diffmind diffmind init
npx -y --package diffmind diffmind doctor

init safely merges the Claude Code hooks, writes the project-scoped .mcp.json, creates .diffmind/, and installs the DiffMind instructions into CLAUDE.md. Existing JSON files are backed up once as *.bak, and rerunning the command is safe.

Restart Claude Code in the repository, then make a code change. Rerun doctor at any time to verify MCP, hooks, storage, and agent instructions.

Optional Git commit-message integration:

npx -y --package diffmind diffmind install-git-hook

Commit the useful decision records

echo "/.diffmind/sessions/" >> .gitignore   # optional: exclude raw session files
# explanations/ and digests/ are worth committing — that's the point
git add .diffmind/

Usage Examples

Example 1: First-time setup walkthrough

cd /path/to/your-project
npx -y --package diffmind diffmind init
npx -y --package diffmind diffmind doctor
# Restart Claude Code in this repository

Example 2: A typical session walkthrough

You: "Add JWT refresh token support to the authentication system"

Claude (via DiffMind):

Calls start_session("Add JWT refresh token support")
Calls get_conventions() to read your project rules
Writes code...
Calls explain_change():
- Intent: "Add JWT refresh logic to prevent session expiration"
- Rationale: "Users were getting logged out every 15min. JWT refresh extends sessions by issuing new tokens before expiry. Checked existing AuthGuard, added interceptor to catch 401 responses and trigger refresh flow automatically."
- Rejected: ["OAuth flow (overkill for internal app)", "Server-side sessions (stateful, breaks horizontal scaling)"]
- Trade-offs: ["Slightly more complex client logic vs. better UX", "Extra network request on refresh vs. seamless experience"]
- Verification: ["Tested with expired token → refresh triggers automatically", "Confirmed refresh endpoint returns new token with extended expiry"]

Result:

.diffmind/explanations/x-20260730-abc123.json created
Quality gate passed (no filler phrases, sufficient detail)
Session logged

You: (end conversation)

DiffMind Stop hook triggers:

╔══════════════════════════════════════════════════════╗
║  Choose explanation types (↑↓ move, Space select,   ║
║  Enter confirm):                                     ║
║                                                      ║
║  > [✓] Natural language (why/what/tradeoffs)         ║
║    [ ] Architecture diagram                          ║
║    [✓] Call chain diff (mermaid)                     ║
║    [ ] Git commit message only                       ║
╚══════════════════════════════════════════════════════╝

╔══════════════════════════════════════════════════════╗
║  Custom explanation requirements (optional):         ║
║  e.g., "explain in Chinese", "focus on performance"  ║
╚══════════════════════════════════════════════════════╝
> explain in Chinese, focus on security implications

Result:

.diffmind/digests/s-20260730-xyz.md generated with Chinese explanation
Call chain Mermaid diagram showing AuthGuard → TokenService → RefreshAPI

Example 3: Git commit with auto-generated message

$ git add .
$ git commit

# prepare-commit-msg hook runs diffmind git-message
# Your commit message is pre-filled:

Add JWT refresh token support

Session: s-20260730T143022-abc123
Closed: 2026-07-30T14:45:00Z

Changes (DiffMind):
- Add JWT refresh logic to prevent session expiration (structural)
  Why: Users were getting logged out every 15min. JWT refresh extends sessions...
- Update AuthGuard to handle token refresh flow (local)
  Why: Need to intercept 401 responses and trigger refresh before retrying...

Trade-offs:
- Slightly complex client logic vs. better UX
- Extra network request on refresh vs. seamless experience

Verification:
- Tested with expired token → refresh triggers automatically
- Confirmed refresh endpoint returns new token with extended expiry

Open threads: None

See: .diffmind/digests/s-20260730T143022-abc123.md

Example 4: Querying past decisions

# Via MCP tools (in Claude Code)
recall_change("x-20260730-abc123")
list_changes(limit=10, scale="architectural")

# Via CLI
diffmind --help

Example 5: User profile evolution

After 10 sessions:

$ diffmind profile show

User Profile
────────────
Knowledge Level: intermediate
Preferred Language: zh (Chinese)
Preferred Explanation Types:
  - natural_language: 8 times
  - call_chain_diff: 6 times
  - git_commit_message: 10 times
  - architecture_diagram: 2 times

Focus Areas: security, performance, error-handling

Quality Metrics:
  - Violation rate: 5% (healthy)
  - Avg rationale length: 180 chars (good)

Last updated: 2026-07-30T16:00:00Z

Example 6: Project overview

# Generate initial overview
$ diffmind overview init

Analyzing 47 explanations...
Generated:
  - .diffmind/overview/README.md (project purpose, key modules)
  - .diffmind/overview/architecture.md (call chains, trade-offs)
  - .diffmind/overview/decisions/jwt-refresh.md
  - .diffmind/overview/decisions/redis-cache.md

# Enable auto-updates
$ diffmind overview enable

# Now on every commit, the overview updates automatically

Real-world workflow

Morning: Start new feature

Open Claude Code
"Add email verification to signup flow"
DiffMind auto-starts session
Claude reads conventions, writes code, explains changes
Quality gate blocks: "Rationale contains filler phrase: 'better security'"
Claude revises: "Email verification prevents bot signups and ensures valid contact info for password resets. Checked existing UserService, added SendGrid integration with 6-hour token expiry."
Explanation saved

Afternoon: Review what was done

Check .diffmind/digests/s-20260730-morning.md
See: why email verification, what alternatives (SMS, phone), trade-offs
Understand the decisions without re-reading code

Evening: Commit work

git commit
Commit message auto-populated with DiffMind digest
User profile evolves in background
Overview docs updated

Next week: New developer joins

They read .diffmind/overview/README.md
Understand project architecture in 5 minutes
Check .diffmind/overview/decisions/ for past architectural choices
Start contributing with context

MCP tools

Tool	When to call
`start_session(goal)`	Before making any changes
`get_conventions()`	Before touching existing code
`explain_change(...)`	After every meaningful edit
`close_session(sessionId, summary)`	When done for this conversation
`recall_change(id)`	Look up a past explanation
`list_changes(...)`	Browse recent history
`start_convention_interview()`	First time on a new project
`save_conventions(...)`	Persist project conventions

Quality gate

DiffMind blocks or warns when explanations are vague. You can't save:

A rationale under the minimum length for the change scale
A rationale that just repeats the summary (Jaccard similarity > 0.7)
Filler phrases: "better maintainability", "cleaner code", "improved readability"
A structural or architectural change with no rejected alternatives
confidence: "verified" with no verification steps listed

Warnings (non-blocking) catch things like missing call chain on structural changes, suspiciously many files for a "local" scale, or opening the rationale with an action verb.

Git integration

DiffMind automatically enhances your commit messages with session context:

diffmind install-git-hook

Now when you commit after a DiffMind session, the commit message includes:

Session summary
Key explanations and their rationale
Trade-offs and verification steps
Link to the full digest

This makes git log a searchable knowledge base of why decisions were made (git log --grep "DiffMind session"). The hook only touches ordinary commits — it leaves merges, squashes, amends, and -m messages alone, and does nothing when there's no closed session or DiffMind isn't installed.

See it in action

Want the full picture before installing? A worked walkthrough of implementing login takes a single request — "帮我完成登录功能" — through the whole DiffMind workflow: session start, three explain_change calls with genuine trade-offs (bcrypt over plaintext, sessions over JWT, a deliberately vague 401 to block email enumeration), the generated digest with its Mermaid call chain diff, the terminal box, the drafted commit message, and — three weeks later — recall_change handing the reasoning back just as the developer needs it to add OAuth.

Storage layout

.diffmind/
├── conventions.json        project coding conventions
├── sessions/               one JSON per session (start → close)
├── explanations/           one JSON per explain_change call
└── digests/                Markdown digest per session, with Mermaid call chain diff

All files are plain text (JSON + Markdown) that you can Read directly or grep. digests/ is the main artifact for code review.

Roadmap

Phase 1 — MCP server, 9 tools, quality gate, session model
Phase 1.5 — diffmind CLI, Claude Code hook auto-trigger, terminal explanation picker
Phase 2 — Call chain diff visualization (Mermaid, changed nodes in red)
Phase 2.5 — Git commit message injection (prepare-commit-msg)
Phase 3 — Web UI for browsing sessions and explanation history

Contributing

Issues and PRs welcome. This project follows its own conventions — run start_convention_interview() in DiffMind before contributing code.

License

MIT

Available Tools

10 tools

close_sessionClose a sessionA

Call this when the work is done or the conversation is ending. Writes a human-readable digest to .diffmind/digests/.md that the user can read to catch up on what happened.

ParametersJSON Schema

Name	Required	Description
`summary`	Yes	Narrative wrap-up: what was accomplished, in plain English. This is what the human reads first. Write it for them, not for you.
`sessionId`	Yes	The id returned by start_session.
`openThreads`	Yes	Things left undone — bugs not fixed, features not implemented, assumptions not validated. Honest accounting, not spin.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses the primary side effect (writing a digest file to a specific location), which is valuable. However, it does not mention whether the session is marked as closed in any backend state, whether the operation is idempotent, or any permission requirements. The single disclosed side effect is helpful but incomplete for a mutation-like closing action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, immediately front-loaded with the usage trigger, then the primary effect. Every word earns its place; no fluff.

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 is simple with all parameters required and well-documented in the schema. The description explains the key output side effect and usage context, which is sufficient for an agent to call it correctly. No output schema exists, but the return value is likely trivial. Losing a point because no annotations exist and the description does not cover state mutation or post-conditions, but overall it is complete for the operation's purpose.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides (e.g., sessionId from start_session, summary narrative, openThreads list). The schema descriptions are sufficient, so no deduction is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Call this when...' + 'Writes a human-readable digest to .diffmind/digests/<sessionId>.md'), describing a specific verb (close) and resource (session digest path). It does not explicitly name sibling tools like start_session, but the trigger phrase 'when the work is done or the conversation is ending' implies the distinction. Thus it is clear but lacks explicit sibling differentiation.

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?

Provides explicit when-to-use guidance: 'Call this when the work is done or the conversation is ending.' It does not explicitly discuss when not to use or name alternatives, so it misses the top score, but the context is unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_changeExplain a code changeA

Record an explanation for a change you just made. Call this after every meaningful code edit — before moving on to the next task. The explanation is quality-checked and rejected if it does not genuinely transfer understanding. "I fixed a bug" or "refactored for clarity" will be rejected. You need a session open (call start_session first).

ParametersJSON Schema

Name	Required	Description
`files`	Yes	Every file changed, with per-file what/why.
`scale`	Yes	trivial: whitespace, rename, one-liner. local: one function/class, no external contracts changed. structural: module boundaries or data shapes changed, callers affected. architectural: cross-cutting concerns, deployment topology, system contracts.
`intent`	Yes	The user-facing goal this change serves, in the user's own framing. Not your framing.
`diagram`	No	Optional Mermaid source code that illustrates the change.
`summary`	Yes	One-line summary. Reads like a good git commit subject.
`rejected`	Yes	Approaches you considered and did not take. Empty is valid for trivial/local changes; structural+ changes must have at least one.
`callChain`	No	Call graph nodes for this change. Include modified/created nodes and their direct callers. Required for structural and architectural changes to visualize impact.
`followUps`	Yes	Work this change implies but does not do.
`rationale`	Yes	The reasoning: WHY this shape of solution. State the constraint, failure mode, or alternative it beats. Do NOT restate what you changed — that is what summary and files are for.
`sessionId`	Yes	The session id returned by start_session.
`tradeoffs`	Yes	Costs knowingly accepted: what got slower, more complex, or harder to change. An honest empty array is fine for trivial changes.
`confidence`	Yes	verified: you ran something (build, test, manual check) and it passed — list it in verification. likely: you reasoned it through but did not run it. unverified: you are unsure.
`verification`	Yes	How a reviewer can check this: commands run, test names, manual steps. Required when confidence is "verified".
`conventionsApplied`	Yes	Convention ids checked against while making this change. Pass [] if no conventions exist yet.
`implementationFlow`	No	Optional step-by-step, method-level breakdown showing how this feature runs end-to-end. Format each step as: "MethodName(args) — what it does and why it matters". Example: "POST /login → validateInput(email, password) — checks format, rejects injection → UserRepo.findByEmail(email) — queries DB, returns record or null → bcrypt.compare(input, hash) — constant-time comparison, prevents timing attacks → SessionService.create(userId) — generates token, writes to Redis → 200 {token, expiresAt}". For structural/architectural changes, include an `implementationFlow` field with a step-by-step method-level breakdown showing how the feature works end-to-end.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that explanations are 'quality-checked and rejected if they do not genuinely transfer understanding,' including specific rejection examples. It also discloses the session requirement, adding valuable context beyond what the schema shows. There is no mention of side effects or return values, but the key behavior is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences with no wasted words. It front-loads the purpose, then provides usage timing, quality expectations, and a prerequisite. Each sentence earns its place, and the structure is clear and efficient.

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 a complex schema (15 params, 12 required) which is fully documented. The description adds workflow context: when to call, quality bar, and session prerequisite. Since there is no output schema, it could explain return values, but the description adequately covers what a caller needs to know to use the tool correctly, given the schema richness.

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 schema has 100% parameter description coverage with detailed descriptions for all 15 parameters, so the baseline is 3. The description adds general quality guidance (e.g., 'I fixed a bug' will be rejected) that informs fields like summary and rationale, but it does not provide parameter-specific semantics beyond what the schema already offers.

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 clearly states the tool's purpose with a specific verb and resource: 'Record an explanation for a change you just made.' It also distinguishes from siblings by emphasizing recording after edits, which contrasts with recall/list tools. The title 'Explain a code change' aligns with the description.

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?

The description explicitly says when to use the tool: 'Call this after every meaningful code edit — before moving on to the next task.' It also provides a prerequisite: 'You need a session open (call start_session first).' However, it does not mention alternatives or when-not-to-use scenarios, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_conventionsGet coding conventionsA

Read the project coding conventions. Call this BEFORE writing or changing code, so the change matches the team rules rather than your defaults.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

Without annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation, which implies non-mutating behavior, but does not add further detail such as return format or edge cases. The 'Call this BEFORE' instruction provides useful contextual behavior beyond a simple read, but more depth would be needed for a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with only two sentences. It front-loads the action with 'Read the project coding conventions' and the second sentence provides valuable usage guidance without any waste.

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?

Given the tool's simplicity (no parameters, no output schema), the description is largely complete: it states the action and when to use it. It does not explicitly describe what the tool returns, which would be expected without an output schema, but the word 'Read' reasonably implies the conventions are the output. A brief mention of the return value would make it fully complete.

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?

There are zero parameters, so the baseline score of 4 applies. The description adds an implicit 'project' context but does not need to explain parameters because none exist in the schema.

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 clearly states the tool reads project coding conventions, using the specific verb 'Read' and a distinct resource. It is not a tautology and is distinguishable from sibling tools like save_conventions.

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?

The description explicitly instructs to call this tool before writing or changing code, providing clear timing context. However, it does not explicitly mention when not to use it or name alternatives, though the instruction implies when it is necessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_changesList recent changesA

List changes recorded in DiffMind, newest first. Use this to orient yourself at the start of a new session, or to answer "what has been done so far?"

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return. Default 20.
`scale`	No	Filter to a specific change scale.
`sessionId`	No	Narrow to a specific session.

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It does state the sort order (newest first) and the source (DiffMind), which is useful. But it omits any mention of filtering behavior, default limits, or what fields are returned, leaving the agent to infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and resource, and adds a clear use case without any fluff. Every word earns its place.

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?

For a list tool with all-optional parameters and no output schema, the description provides enough context for an agent to successfully invoke it. It could mention default limit or return shape, but the schema and purpose cover the essentials. Slight gap is the absence of any note about pagination or result details.

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?

Schema description coverage is 100%, so all three parameters already have meaningful descriptions. The tool description itself does not add further parameter details, but it is not required to; the baseline of 3 applies.

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 clearly identifies the tool as the one that lists changes recorded in DiffMind, ordered newest first. It distinguishes itself from siblings like recall_change by framing itself as an orientation tool rather than a detail lookup.

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?

It explicitly says to use this at the start of a new session or to answer 'what has been done so far?' This gives clear context for when to use it. However, it does not name alternative tools or explicitly state when not to use it, but the guidance is still strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mark_gap_filledA

Mark a knowledge gap as filled when the user demonstrates understanding

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	The topic the user now understands
`evidence`	Yes	Evidence that they understand (e.g., "successfully explained it back")

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Mark a knowledge gap as filled' without explaining side effects, persistence, permissions, return values, or any state changes. The mutation-like nature is implied but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that avoids redundant wording. It is front-loaded with the action and condition, with no unnecessary details.

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

Completeness2/5

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

Given the lack of an output schema and annotations, the description should explain what happens when marking a gap as filled, such as return behavior or side effects. It only states the action and condition, leaving important behavioral context missing.

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 fully describes both parameters (topic and evidence) with clear descriptions. The tool description adds no additional parameter information beyond what the schema already provides, so the baseline of 3 applies.

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 clearly states the tool's action: 'Mark a knowledge gap as filled' with a specific resource 'knowledge gap' and a condition 'when the user demonstrates understanding'. It is distinct from sibling tools like 'explain_change' or 'save_conventions', 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 Guidelines4/5

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

The description provides a clear usage context: use this tool when the user demonstrates understanding. It does not explicitly mention alternatives or when not to use it, but the condition is sufficient for guiding basic usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recall_changeRecall a specific changeA

Fetch the full explanation for a change by its id. Use this when you need to understand WHY code looks the way it does, before modifying it.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The explanation id (e.g. x-20260730T131204-a3f2b1).

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. 'Fetch' clearly implies a read operation, and the 'why code looks the way it does' context adds purpose, but it does not disclose behavior like error handling, idempotency, or any permissions needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every phrase earns its place. It is appropriately sized with no filler.

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 is simple with one required parameter and no output schema. The description conveys the main purpose and usage context, making it sufficiently complete for an agent, though it does not describe the exact return structure.

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?

Input schema coverage is 100% and the id parameter already includes a descriptive example. The description adds context about retrieving a full explanation but does not meaningfully expand on the parameter semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches the full explanation for a change by id, using a specific verb and resource. It distinguishes itself from list_changes and mark_gap_filled, but does not explicitly differentiate from the sibling explain_change, which may also provide explanations.

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?

The description provides explicit when-to-use guidance: use it to understand why code looks the way it does before modifying. It does not mention exclusions or alternatives, so it falls just short of a top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_conventionsSave coding conventionsA

Record the coding conventions the human described. Also use this to add or amend rules later. Rules are merged by category+rule text; existing rules are preserved unless replace is true.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Anything the human said that does not fit a single rule.
`replace`	No	True to replace the whole set instead of merging. Use only when the human asks for a reset.
`conventions`	Yes	The rules to record.
`projectName`	Yes	Name of the project.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It effectively explains the merge semantics: 'Rules are merged by category+rule text; existing rules are preserved unless replace is true.' This reveals non-obvious behavior that prevents data loss and clarifies how updates work. It could add more (e.g., return values or side effects), but the key behavioral detail is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, front-loaded with the primary action. Every sentence earns its place: the first defines the main use, the second covers amendment, and the third clarifies merge/replace behavior. No filler or redundancy.

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?

Given no output schema and no annotations, the description plus schema provide solid coverage. The description addresses the most critical ambiguity (merge vs replace) and the schema covers parameter formats. It omits minor details like confirmation of inferred rules, but the schema notes that. Overall, sufficient for an agent to invoke the tool correctly.

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?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the merge key ('category+rule text') and the meaning of 'replace' in context, which informs how to use the conventions and replace parameters correctly. This goes beyond what the schema alone states, earning a 4.

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 clearly states the tool's primary function: 'Record the coding conventions the human described.' It also specifies the extendable use case ('add or amend rules later'), which differentiates it from siblings like get_conventions and start_convention_interview. The verb 'record' and resource 'coding conventions' are explicit and unambiguous.

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?

The description provides clear usage context: record new conventions and amend existing ones later. It does not explicitly list alternatives or when not to use, but sibling context (e.g., start_convention_interview, get_conventions) implies distinctions. The phrase 'Also use this to add or amend rules later' gives direct guidance for repeat usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_convention_interviewStart convention interviewA

Call this ONCE at the start of work on a new project, before writing code. Returns the questions to ask the human about their coding standards. Ask them conversationally — do not dump all questions at once. Then call save_conventions with their answers.

ParametersJSON Schema

Name	Required	Description	Default
`projectName`	Yes	Name of the project being set up.

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description takes on the full burden of behavioral disclosure. It reveals that the tool returns questions, advises to ask them conversationally rather than all at once, and instructs a follow-up action. It does not disclose potential side effects like duplicate calls, but the guidance to call 'ONCE' implies idempotency concerns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the most critical instruction ('Call this ONCE at the start'), and every sentence provides actionable guidance. No fluff or repetition of existing schema data.

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

Completeness5/5

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

For a simple tool with a single parameter and no output schema, the description fully covers what the agent needs: when to invoke, what it returns (questions), how to interact with the human (conversationally), and what to do next. It is complete within its scope and compared to sibling tools.

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 schema already provides 100% coverage for the single parameter projectName ('Name of the project being set up'). The description adds minimal semantic value beyond the schema, only indirectly referencing a 'new project'. Per the baseline rule, schema covers the parameter so a score of 3 is appropriate.

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 clearly states the tool's purpose: to start a convention interview at the beginning of a new project and return questions to ask the human. It uses a specific verb ('start') and resource ('convention interview'), and distinguishes itself from siblings by its explicit tie to saving conventions via save_conventions.

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

Usage Guidelines5/5

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

Provides explicit usage instructions: call ONCE at the start of work on a new project, before writing code. It also gives a follow-up step (call save_conventions with answers), which clarifies the tool's role in the workflow. This effectively differentiates when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_sessionStart a sessionA

Call this at the very beginning of work on a task. Returns a sessionId to pass to every subsequent explain_change call. If an open session already exists you get it back — no duplicate opens.

ParametersJSON Schema

Name	Required	Description	Default
`goal`	Yes	What the user asked for, in their own words. Not your paraphrase. This is the anchor that makes the session digest legible later.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals key behaviors: returns a sessionId, reuses an existing session, and establishes ordering. Minor gaps, such as side effects or persistence details, are not important for this simple initializer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the key instruction ('Call this at the very beginning'), and every word adds value without repetition.

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?

For a one-parameter tool with no output schema, the description is adequately complete. It explains when, what, and the idempotent behavior. Sibling tools are not confused with this one, and no additional context is necessary.

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?

Schema coverage is 100% for the single 'goal' parameter, and the schema description adds rich detail about how to provide the goal (in the user's own words, as an anchor). The tool description itself adds no extra parameter meaning, so the baseline of 3 applies.

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 clearly states the tool's purpose: starting a session and returning a sessionId. It distinguishes itself from sibling tools by explicitly mentioning that the sessionId is passed to every subsequent explain_change call.

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

Usage Guidelines5/5

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

Explicitly instructs to call this tool at the very beginning of a task, providing clear timing. Also gives an alternative scenario: if an open session already exists, the existing session is returned, avoiding duplicate opens.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_notifyTest MCP notificationsA

Sends a test notification via the MCP server to verify how Claude Code handles notifications. Used for debugging and testing the notification system.

ParametersJSON Schema

Name	Required	Description	Default
`message`	No	The message to send in the notification	Test notification from DiffMind

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the action (sending a notification) and the intent (debugging/testing), but it does not describe side effects, who sees the notification, or whether it is reversible. For a simple test tool this is marginally adequate, but lacks richer behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the action ('Sends a test notification') and efficiently provides purpose. No wasted words; every sentence adds value.

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?

For a tool with one optional parameter and no output schema, the description adequately covers what the tool does and when to use it. It could mention the return value or the fact that it's safe, but given the simplicity, the description is sufficiently complete.

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 covers 100% of parameters with a description for 'message'. The tool description adds no additional parameter details, so it does not go beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states a specific verb and resource: 'Sends a test notification via the MCP server'. It also explains the purpose ('verify how Claude Code handles notifications'), and this tool is uniquely positioned among siblings (which deal with conventions, sessions, and changes) as the only notification-related tool.

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?

The description provides clear usage context by stating 'Used for debugging and testing the notification system.' It does not explicitly name alternatives or exclusions, but given the siblings are unrelated, no alternative is needed. This meets the 'clear context, no exclusions' level.

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.

10 tool updatesv0.1.1Aug 8, 2026
- First observedclose_session
- First observedexplain_change
- First observedget_conventions
- First observedlist_changes
- First observedmark_gap_filled
- First observedrecall_change
- First observedsave_conventions
- First observedstart_convention_interview
- First observedstart_session
- First observedtest_notify

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Tools are mostly distinct: conventions, sessions, changes, and notifications are separate concerns. However, mark_gap_filled and test_notify do not clearly fit the established workflow, creating minor ambiguity about their role.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (e.g., save_conventions, explain_change). Exceptions like mark_gap_filled and test_notify deviate slightly but remain readable and consistent in style.

Tool Count4/5

At 10 tools, the server is well-scoped for its purpose, but test_notify feels like an auxiliary utility that doesn't belong to the core domain, making the count slightly higher than necessary.

Completeness3/5

The core change and convention workflows are covered, but the knowledge gap feature only has a 'mark filled' action with no way to create or list gaps, and there is no update/delete for changes or conventions, leaving some lifecycle gaps.

Maintenance

ActivitySlowing

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214

Related MCP Servers

mcp-agent-review
Code Analysis AI & Machine Learning
lzx1413
A
license
Not graded
quality
C
maintenance
An MCP server that provides agentic code review powered by OpenAI-compatible models, designed for use with Claude Code.
Updated 4 months ago (2026-04-29 01:52 UTC)
1
MIT
codex-fusion-mcp
AI & Machine Learning Developer Tools Code Analysis
Tritlo
A
license
Not graded
quality
B
maintenance
MCP server enabling Claude to consult Codex (GPT-5.x) mid-task for second opinions, plan/diff review, brainstorming, and codebase exploration via structured debates and permission-controlled interactions.
Updated 2 months ago (2026-07-06 16:11 UTC)
2
MIT
paranoia-local
Code Analysis Testing & QA Tools Autonomous Agents
subvertnormality
A
license
Not graded
quality
B
maintenance
A local MCP server that provides adversarial code review by having one frontier agent (Claude Code or Codex) critique code changes using the other agent (Codex or Claude Code) with full repository access, enabling a genuine second opinion on code and plans.
Updated a day ago (2026-09-04 22:56 UTC)
13
MIT
ArchMemory MCP
Software Architecture Developer Tools
IWill29
A
license
Not graded
quality
C
maintenance
An MCP server that gives AI coding agents structured access to a project's architecture, rules, modules, and technical decisions.
Updated 2 months ago (2026-07-15 20:35 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/akay1121/DiffMind'

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

DiffMind

A complete login walkthrough

Keeps your context clean

Token economics

Why existing tools fall short

Why DiffMind?

The Problem: Vibe Coding Amnesia

The Solution: Structured Decision Documentation

An Evolving CLI That Learns You

How it works

Quick start

Commit the useful decision records

Usage Examples

Example 1: First-time setup walkthrough

Example 2: A typical session walkthrough

Example 3: Git commit with auto-generated message

Example 4: Querying past decisions

Example 5: User profile evolution

Example 6: Project overview

Real-world workflow

Morning: Start new feature

Afternoon: Review what was done

Evening: Commit work

Next week: New developer joins

MCP tools

Quality gate

Git integration

See it in action

Storage layout

Roadmap

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API