code-failures-mcp
Click on "Deploy 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., "@code-failures-mcp search for past bugs with 'connection timeout'"
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.
code-failures-mcp
MCP server that indexes your code_failures/ knowledge base and makes it searchable from Claude Code (or any MCP client). Uses BM25 via MiniSearch for fast, relevant keyword search with fuzzy matching.
Why
Every bug you debug for hours becomes institutional knowledge. This MCP server makes that knowledge automatically available to Claude Code so it searches your past fixes before attempting a new solution.
Related MCP server: conversation-history-mcp
Tools
Tool | Purpose |
| Search bugs by symptom, error message, or library name |
| Search canonical working patterns and version guides |
| Search everything with relevance scores |
| Retrieve full content of a specific document |
| List all indexed documents |
Setup
cd /Users/tk/Desktop/code-failures-mcp
npm install
npm run buildConfigure Claude Code
CLI + Manual Config (recommended)
The claude mcp add CLI doesn't support environment variables via flags, so you need to add the server first, then manually edit the config:
# Step 1: Add the server (global)
claude mcp add code-failures -- node /Users/tk/Desktop/code-failures-mcp/dist/index.js
# Step 2: Edit ~/.claude.json and add the env object to the code-failures server config:
# "env": {
# "BRAIN_PATH": "/Users/tk/Desktop/brain/code_failures"
# }
# For project-scoped:
claude mcp add -s project code-failures -- node /Users/tk/Desktop/code-failures-mcp/dist/index.js
# Then edit the project's section in ~/.claude.jsonVerify with:
claude mcp listJSON config (alternative)
Manually add to ~/.claude.json (find your project section):
{
"projects": {
"/your/project/path": {
"mcpServers": {
"code-failures": {
"type": "stdio",
"command": "node",
"args": ["/Users/tk/Desktop/code-failures-mcp/dist/index.js"],
"env": {
"BRAIN_PATH": "/Users/tk/Desktop/brain/code_failures"
}
}
}
}
}
}Or for Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"code-failures": {
"command": "node",
"args": ["/Users/tk/Desktop/code-failures-mcp/dist/index.js"],
"env": {
"BRAIN_PATH": "/Users/tk/Desktop/brain/code_failures"
}
}
}
}CLAUDE.md Integration
Add this to your project's CLAUDE.md to make Claude Code automatically use the knowledge base:
# Global Preferences
- Implement only what's explicitly requested. Prefer minimal changes. No unnecessary features, files, or abstractions.
- Check all related functionality before modifying code — update or verify dependents.
- Before writing a script, check what tools are available via MCP or plugins. Prefer existing tools over bash scripts.
- Always use Context7 MCP (resolve-library-id → get-library-docs) before writing code involving external libraries or frameworks.
- ALWAYS call `search_past_bugs` before debugging any error. Call `search_references` before writing integration code. These check your verified fixes first — prioritize over Context7 and web search.
- After solving a bug that took >15 min: draft Symptom/Root Cause/Fix/Prevention, show me for review, then call `file_bug` to save it.
## Git Workflow
- Commit after each logical unit of work with conventional commit messages (feat:, fix:, refactor:, chore:).
- Do not push unless explicitly asked.
- Work on feature branches, never commit directly to main.
## Self-Improving Project CLAUDE.md
When I correct you on something that represents a recurring pattern or architectural decision (not a one-off typo), propose an update to the project's CLAUDE.md. Follow these rules:
**Before writing, check the existing file.** If a similar rule exists, replace or refine it — never duplicate. If the file exceeds 80 lines, identify a lower-value rule to remove before adding.
**How to write rules:**
1. Use absolute directives — start with NEVER or ALWAYS when appropriate
2. Lead with why (1 sentence max), then the concrete rule
3. Include actual commands or file:line references, not abstract descriptions
4. One code example max per rule. No example if the rule is obvious
5. Bullets over paragraphs. No "Warning Signs" sections for trivial rules
**When to update:** Only for corrections that would apply to future sessions — patterns, conventions, architectural decisions, recurring tool preferences. Not for one-off fixes, typos, or task-specific context.
**Two-tier structure:** If the project CLAUDE.md has a summary section at the top, add a one-line summary there and the detailed rule in the appropriate section below.
If the correction is about a library bug or integration pattern (not project-specific), use `file_bug` or `file_reference` instead of updating CLAUDE.md.
After proposing the update, wait for my approval before writing to the file.Test with MCP Inspector
npm run inspectThis opens the MCP Inspector UI where you can test each tool interactively.
How Indexing Works
On startup, the server:
Recursively finds all
.mdfiles underBRAIN_PATHParses YAML frontmatter for metadata (type, library, tags, severity, status)
Extracts structured sections (Symptom, Root Cause, Fix, Prevention) from bug files
Builds a BM25 index with field boosting:
symptom× 3.0 (highest — you search by what you see)title× 2.5library× 2.0rootCause× 1.5tags× 1.5fix× 1.0fullText× 1.0 (fallback for anything else)
Enables fuzzy matching (0.2 edit distance) and prefix search
Watches the directory for changes and auto-rebuilds
Adding New Bugs
Follow the format in your existing knowledge base:
# Create a new bug file
touch /Users/tk/Desktop/brain/code_failures/bugs/<library>-<short-description>.mdTemplate:
---
type: bug
library: <library name>
versions_affected: "<version range>"
status: confirmed
severity: critical|high|medium|low
tags:
- tag1
- tag2
---
# BUG: Short Description
## Symptom
What you see (error messages, behavior)
## Root Cause
Why it happens
## Fix
Working code
## Prevention
How to avoid itThe index auto-rebuilds when files change.
Available Tools
4 toolsfile_bugA
Save a newly discovered bug to the knowledge base. Call this AFTER solving a hard bug to capture the knowledge for future sessions. The file is written to code_failures/bugs/ and auto-indexed.
IMPORTANT: Show the user the generated content and get confirmation before calling.
Inputs: fix (required), title (required), library (required), symptom (required), +6 more.
file_referenceA
Save a reference document (canonical pattern, version guide, architecture notes) to the knowledge base. Use this for working integration patterns, version compatibility matrices, and architectural decisions.
Inputs: title (required), content (required), filename (required), tags.
search_past_bugsA
Search your code_failures knowledge base for bugs you've already solved. Query with error messages, symptoms, library names, or keywords. Currently indexing 8 documents.
USE THIS TOOL BEFORE debugging any integration issue — your past self may have already spent hours finding the fix.
Inputs: query (required), maxResults.
search_referencesA
Search your code_failures knowledge base for canonical working patterns, version guides, and integration references.
USE THIS for questions like 'what's the correct CopilotKit + AG-UI setup?' or 'which versions are compatible?'
Inputs: query (required), maxResults.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: search_past_bugs targets bug records, search_references targets reference documents, and the two file tools similarly split between bugs and references. The descriptions explicitly define the boundary, so an agent should not confuse them.
All tools follow a verb_noun snake_case pattern with 'search' and 'file' as verbs. Minor inconsistency exists between 'past_bugs' (with modifier) and 'bug'/'reference' without modifiers, but the pattern is predictable.
Four tools is well-scoped for a knowledge base MCP: two search operations and two save operations covering the two content types. Each tool earns its place without redundancy or bloat.
The tool surface covers the core lifecycle: saving and searching both bugs and references. Missing update/delete operations are minor gaps that agents can work around by filing new entries, and the domain is simple enough that this does not cause failures.
Maintenance
Related MCP Connectors
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
An MCP server that gives your AI access to the source code and docs of all public github repos
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Related MCP Servers
- AlicenseAqualityCmaintenanceAn MCP server that makes Claude Code conversation history searchable and proactively useful by indexing past sessions with hybrid BM25+TF-IDF search, extracting decisions and solutions, and auto-injecting relevant project context at session start.93 npm69MIT
- AlicenseNot gradedqualityDmaintenanceA local MCP server that indexes and searches your Claude Code conversation history with both keyword and semantic search, fully private and running locally.MIT
- AlicenseNot gradedqualityDmaintenanceMCP server providing RAG context and failure capture for Claude Code, enabling semantic search across project knowledge and storing/analyzing failures.1MIT
- FlicenseNot gradedqualityDmaintenanceMCP server that provides persistent long-term memory for Claude Code, enabling storage, search, and retrieval of project knowledge across sessions.-