Purpose: Deep code understanding through semantic analysis, indexing, and persistent memory.
Why Serena matters: Claude Code has no built-in indexation (unlike Cursor). Serena fills this gap by indexing your codebase for faster, smarter searches. It also provides session memory — context that persists across conversations.
Key Features:
Feature
Description
Indexation
Pre-indexes your codebase for efficient symbol lookup
Project Memory
Stores context in .serena/memories/ between sessions
Purpose: Privacy-first semantic code search with call graph analysis.
Why grepai is recommended: It’s fully open-source, runs entirely locally using Ollama embeddings (no cloud/privacy concerns), and offers call graph analysis — trace who calls what function and visualize dependencies. This combination makes it the best choice for most semantic search needs.
Key Features:
Feature
Description
Semantic search
Find code by natural language description
Call graph
Trace callers, callees, and full dependency graphs
Privacy-first
Uses Ollama locally (no cloud)
Background indexing
grepai watch daemon keeps index fresh
Example:
Terminal window
# Semantic search (finds code by meaning, not exact text)
grepaisearch"user authentication flow"
# Who calls this function?
grepaitracecallers"createSession"
# → Lists all 23 files that call createSession with context
Before modifying any widely-used function, run a dependency query to enumerate all affected call sites — then decide whether to proceed. This named workflow prevents cascading breakage in large codebases.
Terminal window
# Step 1: Map all callers before touching a function
grepaitracecallers"processPayment"
# → Returns: 14 call sites across 7 files
# Step 2: Check callees (what it depends on)
grepaitracecallees"processPayment"
# → Returns: 3 downstream dependencies
# Step 3: Decide scope before writing a single line
# 14 callers + 3 deps = significant blast radius → plan the refactor first
Run this before starting any refactor touching a function used in 3+ places — not after hitting compile errors.
Purpose: Automatic persistent memory across Claude Code sessions via AI-compressed capture of tool usage and observations. Solves context loss without manual write_memory() calls.
Feature
Value
Capture
Hooks into SessionStart, PostToolUse, Stop, SessionEnd
AGPL-3.0 + PolyForm Noncommercial (check for commercial use)
Stars
26.5K (v10.6.3, 2026-03-30)
Security warning: GET /api/settings exposes API keys in plain text — set host: "127.0.0.1", never "0.0.0.0".
Hook coexistence gotcha: claude-mem installation overwrites existing settings.json hooks arrays. Back up before installing, then manually merge.
Cost: ~$5-15/month (heavy users). Switching compression model from Claude Haiku to Gemini 2.5 Flash saves ~86%.
Full coverage: See Memory Systems: claude-mem for full architecture breakdown, observation types, progressive disclosure workflow, privacy controls, and cost comparison table.
Graphify converts a project directory into a persistent knowledge graph and injects a compact structural report (GRAPH_REPORT.md) into Claude Code. The assistant answers architecture questions by reading the pre-built graph instead of re-scanning raw files on each prompt. Initial extraction runs once; subsequent sessions query the graph at near-zero token cost.
How it works: Three passes per run:
Local AST extraction — tree-sitter parses 25+ languages (Python, TS, Go, Rust, Java, etc.) into a call graph. No API cost, no network.
Optional local transcription — faster-whisper transcribes audio/video locally.
Parallel semantic extraction — Claude subagents process docs, PDFs, and images using your existing API key.
Results merge into a NetworkX graph clustered with the Leiden algorithm (topology-based — no vector embeddings). Every relationship is tagged EXTRACTED, INFERRED, or AMBIGUOUS. Three output files land in graphify-out/:
graph.html — interactive browser visualization
GRAPH_REPORT.md — god nodes, cross-file connections, suggested queries (injected into Claude)
graph.json — persistent, queryable without re-extraction
Graphify vs GrepAI: Different layers, complementary. GrepAI (Ollama, local, free) handles real-time semantic lookups during active coding — fast, targeted, exact. Graphify pre-computes structural relationships across the full codebase (call chains, cross-file dependencies, community clusters) and replaces repeated file reads with a single compact report per session. GrepAI for discovery; Graphify for architectural reasoning and multi-hop questions.
Graphify vs claude-mem: Separate concerns. claude-mem stores what you discussed across sessions (decisions, tool calls, observations). Graphify maps what the codebase contains (structure, dependencies, concept clusters). No overlap — they address different layers of context loss.
Team workflow: Commit graphify-out/ (excluding manifest.json and cache/) to git so teammates inherit the pre-built graph without running extraction themselves.
Caveats:
Non-code files (docs, PDFs, images) are sent to your AI assistant’s API on first run — costs accumulate on large mixed-media repositories.
Without the post-commit hook, the graph drifts from the codebase.
Token efficiency claims from the author (71.5x–120x fewer tokens vs grep-based exploration) are self-reported benchmarks without independent reproduction. Treat as directional.
No native query language — graph queries go through the AI assistant, not Cypher/SQL.
Purpose: Natural language semantic search across code, docs, PDFs, and images.
Why consider mgrep: If you need multi-format search (code + PDFs + images) or prefer a cloud-based solution, mgrep is an alternative to grepai. Their benchmarks show ~2x fewer tokens used compared to grep-based workflows.
Key Features:
Feature
Description
Semantic search
Find code by natural language description
Background indexing
mgrep watch indexes respecting .gitignore
Multi-format
Search code, PDFs, images, text
Web integration
Web search fallback capability
Example:
Terminal window
# Traditional grep (exact match required)
grep-r"authenticate.*user".
# mgrep (intent-based)
mgrep"code that handles user authentication"
Use when:
Need to search across mixed content (code + PDFs + images)
Prefer cloud-based embeddings over local Ollama setup
grepai’s call graph analysis isn’t needed
Note: I haven’t tested mgrep personally. Consider it an alternative worth exploring.
Source: mgrep GitHub
Purpose: AST-based pattern matching for precise structural code searches.
Type: Optional Community Plugin (not core Claude Code)
Installation:
Terminal window
# Install ast-grep skill for Claude Code
npxskillsaddast-grep/agent-skill
# Or manually via plugin marketplace
/pluginmarketplaceadd
What is ast-grep?
ast-grep searches code based on syntax structure (Abstract Syntax Tree) rather than plain text. This enables finding patterns like “async functions without error handling” or “React components using specific hooks” that regex cannot reliably detect.
Key Characteristics:
Aspect
Behavior
Invocation
Explicit - Claude cannot automatically detect when to use it
Integration
Plugin that teaches Claude how to write ast-grep rules
Languages
JavaScript, Python, Rust, Go, Java, C/C++, Ruby, PHP + more
Early Claude Code versions used RAG with Voyage embeddings for semantic search. Anthropic switched to grep-based (ripgrep) agentic search after benchmarks showed superior performance with lower operational complexity (no index sync, no security liabilities). This “Search, Don’t Index” philosophy prioritizes simplicity.
ast-grep is a community extension for specialized structural searches where grep’s regex approach isn’t sufficient, but it’s not a replacement for grep — it’s a surgical tool for specific use cases.
Status: Active development — v0.15.0 (Feb 2026). 12,100+ stars. Rapid release cycle.
Purpose: Headless browser CLI built for AI agents. Uses Playwright/CDP under the hood but optimizes all output for LLM consumption. Written in Rust for sub-millisecond startup.
Why it matters for agentic workflows: Playwright MCP is verbose — every DOM snapshot adds tokens. agent-browser returns only actionable elements via stable short references (@e1, @e2), cutting token usage by ~82.5% on identical scenarios (Pulumi benchmark, 2026-03-03).
Install:
Terminal window
# Homebrew
brewinstallvercel-labs/tap/agent-browser
# Or npm
npminstall-g@vercel-labs/agent-browser
Capabilities:
Feature
Details
Navigation + interaction
Click, type, scroll, fill forms
Accessibility tree
LLM-optimized snapshots (actionable elements only)
Visual diffs
Pixel-level comparison against baselines
Session persistence
Save/restore auth state (AES-256-GCM)
Multi-session
Isolated instances, separate cookies/storage
Security (v0.15.0)
Auth vaults, domain allowlists, action policies
Browser streaming
Live WebSocket preview for human+agent “pair browsing”
agent-browser vs Playwright MCP:
Dimension
Playwright MCP
agent-browser
Primary audience
Developers (test suites)
AI agents
Token usage
Baseline
-82.5%
Element references
XPath/CSS selectors
@e1, @e2 (stable, compact)
Implementation
Node.js
Rust (sub-ms startup)
Session persistence
No
Yes
Security controls
None
Auth vaults, domain allowlists
Self-verifying agents
Awkward
Native pattern
The Ralph Wiggum Loop — self-verifying agent pattern:
1. Agent codes the feature
2. Deploys (Vercel, any target)
3. agent-browser navigates to deployed URL autonomously
4. Tests scenarios, reads accessibility snapshots
5. On failure: agent reads output, fixes code, re-deploys
6. Loop until all scenarios pass — no human in the loop
Documented in production at Pulumi (2026-03-03) across 6 test scenarios on a real app.
Use when:
Agent must verify its own deployed output (self-verifying loops)
⚠️ Status: Under Testing — Evaluated early 2026. MIT licensed, Python.
Purpose: Persistent semantic memory with cross-session search and multi-client support. Complements Serena (key-value) with meaning-based retrieval: retrieve_memory("what did we decide about auth?").
12 MCP tools (store, retrieve, tag search, graph ops, health check)
Multi-client
13+ apps share ~/.mcp-memory-service/memories.db
Install
pip install mcp-memory-service
Cross-device
Cloudflare backend required
Known issues: busy_timeout=5000ms default causes intermittent errors under concurrent access; fix with MCP_MEMORY_SQLITE_PRAGMAS=busy_timeout=15000,cache_size=20000.
Full coverage: See Memory Systems: doobidoo for installation, configuration, storage backends, known issues, and comparison with Kairn/ICM.
⚠️ Status: Under Testing — Evaluated March 2026. Source-Available license (free for individuals and teams ≤20). Benchmarks are vendor-reported, unverified independently.
Purpose: Persistent memory combining episodic decay (Memories) and permanent knowledge graph (Memoirs) in a single zero-dependency Rust binary.
Purpose: Programmatic Git access via 12 structured tools for commit, diff, log, and branch management.
Why Git MCP vs Bash git: The Bash tool can run git commands but returns raw terminal output that requires parsing and consumes tokens. Git MCP returns structured data directly usable by Claude, with built-in filters (date, author, branch) and token-efficient diffs via the context_lines parameter.
⚠️ Status: Early development — API subject to change. Suitable for local workflows; test before adopting in production pipelines.
Tools (12):
Tool
Description
git_status
Working tree status (staged, unstaged, untracked)
git_diff_unstaged
Unstaged changes
git_diff_staged
Staged changes ready to commit
git_diff
Compare any two branches, commits, or refs
git_commit
Create a commit with message
git_add
Stage one or more files
git_reset
Unstage files
git_log
Commit history with date, author, and branch filters
Purpose: Full GitHub platform access — Issues, Pull Requests, Projects, Code search, repository management, and GitHub Enterprise.
Git MCP vs GitHub MCP (two distinct layers):
Layer
Tool
Scope
Local Git operations
Git MCP Server
Commits, diffs, branches, staging
GitHub cloud platform
GitHub MCP Server
Issues, PRs, Projects, Reviews, Search
Both can be active simultaneously. They complement each other: Git MCP handles local work, GitHub MCP handles collaboration and cloud state.
Two setup modes:
Mode
Requires
When to use
Remote (api.githubcopilot.com)
GitHub Copilot subscription
Already a Copilot subscriber
Self-hosted binary
GitHub PAT only
No Copilot, proprietary code, or privacy requirements
Remote MCP (requires a GitHub Copilot subscription):
⚠️ Known issue: claude mcp add --transport http attempts OAuth dynamic client registration by default, which the Copilot endpoint does not support. You’ll get: Incompatible auth server: does not support dynamic client registration. The fix is to inject the token manually (see below).
Step 3 — Edit ~/.claude.json to add the Authorization header:
{
"mcpServers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer gho_xxxxxxxxxxxx"
}
}
}
}
If the token expires: gh auth refresh then update the value in ~/.claude.json.
Self-hosted setup (GitHub PAT only, no Copilot required):
Terminal window
# Download binary from github.com/github/github-mcp-server/releases
exportGITHUB_PERSONAL_ACCESS_TOKEN=ghp_xxx
./github-mcp-serverstdio
{
"mcpServers": {
"github": {
"command": "/path/to/github-mcp-server",
"args": ["stdio"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
}
}
}
}
Key capabilities:
Issues: create, list, filter, assign, close
Pull Requests: create, review, merge, list by assignee/label
Projects: read and update GitHub Projects v2
Code search: search across all repos in an org
GitHub Enterprise: same API, different base URL
Typical workflows with Claude Code:
“List all open PRs assigned to me on org/repo, sorted by last activity”
“For PR #456, summarize the changes, flag breaking changes, and draft a review comment”
“Create an issue for bug X with a checklist, then open a branch and push a fix commit”
“Search all repos in the org for usages of deprecated fetchUser() and list files to migrate”
Differentiator vs @modelcontextprotocol/server-github: The official GitHub MCP server adds Projects support, OAuth 2.1 auth, GitHub Enterprise, and the remote hosted endpoint. The npm reference server is lighter but covers fewer features.
Source: github/github-mcp-server — Go, MIT license, 20k+ stars, actively maintained with regular releases.
The Claude Code Ultimate Guide ships its own MCP server — claude-code-ultimate-guide-mcp — so you can query the guide directly from any Claude Code session without cloning the repo.
What it gives you: 9 tools covering search, content reading, templates, digests, cheatsheet, and release notes. The structured index (882 entries) is bundled in the package (~130KB); markdown files are fetched from GitHub on demand with 24h local cache.
A claude-code-guide agent is included in .claude/agents/claude-code-guide.md. It uses Haiku (fast, cheap) and automatically searches the guide before answering any Claude Code question.
Beyond the official servers listed above, the MCP ecosystem includes validated community servers that extend Claude Code’s capabilities with specialized integrations.
.mcp.json # Project-scope (project root, shareable via VCS)
Note: Three scopes exist: local (default, private to you + current project, in ~/.claude.json), project (shared via .mcp.json at project root), and user (cross-project, also in ~/.claude.json). Use claude mcp add --scope <scope> to target a specific scope.
When true, all tools from this server skip tool-search deferral and are always available without a ToolSearch call first. Use for servers with 1-5 critical tools needed on every turn. (v2.1.121)
Dynamic Headers for Multiple MCP Servers (v2.1.85+)
When a single headersHelper script serves multiple MCP servers, you can branch on CLAUDE_CODE_MCP_SERVER_NAME and CLAUDE_CODE_MCP_SERVER_URL to return different authentication tokens or scopes per server:
Absolute path to the project root (the directory Claude was started from). Auto-injected into stdio-type MCP server process environments. Also usable in plugin command strings. (v2.1.139)
Warning: The syntax ${workspaceFolder} and ${env:VAR_NAME} are VS Code conventions, not Claude Code. Claude Code uses standard shell-style ${VAR} and ${VAR:-default} for environment variable expansion in MCP config.
MCP stdio env injection: All stdio-type MCP servers automatically receive CLAUDE_PROJECT_DIR as an environment variable — no config needed. This lets MCP servers know which project they’re operating in without requiring the client to pass it explicitly.
When you accumulate many MCP servers, enabling them all globally degrades Claude’s tool selection — each server adds tool descriptions to the context, making the model less precise at picking the right one.
Pattern: keep a minimal global config (2-3 core servers) and activate project-specific servers via per-project .mcp.json.
# Project-scope (.mcp.json at project root) → only when needed
postgres # database project
playwright # frontend project
serena # large codebase
Community tools (e.g. cc-setup) are emerging to provide a TUI registry with per-project toggling and health checks — useful if you manage 8+ servers regularly.
Claude Code v4 introduced MCP Tool Search: instead of loading all MCP tool definitions at startup, tool schemas are fetched on-demand when Claude needs them.
Why it matters: each MCP server injects its full tool schema into the context window. With a dozen servers, that’s ~77,000 tokens consumed before you’ve written a single prompt.
Setup
Context used by tools
All tools loaded upfront
~77,000 tokens
MCP Tool Search enabled
~8,700 tokens
Reduction
~85%
Model accuracy on tool-selection tasks (measured on Opus 4): 49% → 74% (+25 points) when switching from full preload to lazy-loading. Auto-enables when MCP tools would consume >10% of the context window.
Practical implication: you can now connect dozens of MCP servers without the “too many tools” accuracy penalty. The advice to keep global config minimal still applies for unrelated tools, but MCP Tool Search changes the calculus for large project-specific sets.
To opt a specific server out of deferral entirely, set alwaysLoad: true in its config. Use this for servers with small tool counts (1-5 tools) that you know you’ll need every session:
.claude/settings.json
{
"mcpServers": {
"my-critical-server": {
"command": "npx",
"args": ["my-mcp-server"],
"alwaysLoad": true
}
}
}
CLI vs MCP — when a shell command beats a server: Familiar CLI tools (git, grep, jq, curl) are already deeply embedded in Claude’s training data. A few usage examples in CLAUDE.md are often more effective than an equivalent MCP server, because the model already knows the tool’s behavior, flags, and output format. An MCP server adds tool schema overhead and introduces an unfamiliar interface. Default to CLIs for standard tools; use MCP servers for proprietary systems or APIs the model has no training context for.
Problem: MCP servers require API keys and credentials. Storing them in plaintext mcp.json creates security risks (accidental Git commits, exposure in logs, lateral movement after breach).
Solution: Separate secrets from configuration using environment variables, OS keychains, or secret vaults.
For production deployments, consider zero standing privilege where MCP servers start with no secrets and request just-in-time credentials on tool invocation.
MCP servers handle auth/credentials — Claude Code sees only clean interfaces
Queries execute in parallel, not sequentially → majority of the time savings
Human investigators review Claude’s structured report, not raw data
One dedicated repo for all MCP server implementations + system prompt
Results (self-reported by Mergify, Nov 2025):
Triage time: ~15 min → <5 min (⅔ reduction)
First-pass accuracy: 75% (25% still require human follow-up)
Key takeaway: This pattern — Claude Code as operational orchestrator with domain-specific MCP adapters — applies to any ops/support team juggling multiple disconnected systems. It’s distinct from “Claude Code as dev tool”: here Claude runs in a production workflow, not an IDE.
Claude Code includes a comprehensive plugin system that allows you to extend functionality through community-created or custom plugins and marketplaces.
Remove plugin completely (prompts before deleting persistent data)
claude plugin uninstall security-audit
claude plugin update [name]
Update plugin to latest version
claude plugin update security-audit
claude plugin validate <path>
Validate plugin manifest
claude plugin validate ./my-plugin
${CLAUDE_PLUGIN_DATA} — Persistent plugin storage (v2.1.78+): Plugins can store state that survives updates using the ${CLAUDE_PLUGIN_DATA} env variable. This variable points to a dedicated directory that is preserved when the plugin is updated and only deleted on explicit /plugin uninstall (with confirmation prompt). Use it for caches, user preferences, or any data your plugin needs across sessions.
Team use case: Commit a shared config directory to your repo and all team members automatically get the same enabled plugins and approved marketplaces — no per-user configuration needed.
Since v2.0.74 (December 2025), Claude Code natively integrates with Language Server Protocol servers. Instead of navigating your codebase through text search (grep), Claude connects to the LSP server of your project and understands symbols, types, and cross-references — the same way an IDE does.
Why it matters: Finding all call sites of a function drops from ~45 seconds (text search) to ~50ms (LSP). Claude also gets automatic diagnostics after every file edit — errors and warnings appear in real time, without a separate build step.
Plugin = “How Claude thinks” (new workflows, specialized agents)
MCP Server = “What Claude can do” (new tools, external systems)
MCP Apps = “What Claude can show” (interactive UIs in supported clients)*
*Note: MCP Apps render in Claude Desktop, VS Code, ChatGPT, Goose. Not supported in Claude Code CLI (terminal is text-only). See Section 8.1 for details.
Two community plugins address complementary problems that AI-assisted development creates: code quality drift (accumulation of poorly-structured AI-generated code) and hallucination in generated solutions.
Problem solved: AI tools write code faster than teams can maintain it. GitClear’s analysis of 211M lines shows refactoring collapsed from 25% to under 10% of all changes (2021–2025). Vitals identifies which files are most likely to cause problems next — before they do.
How it works: Computes git churn × structural complexity × coupling centrality to rank hotspots. Not just “this file is complex” but “this complex file changed 49 times in 90 days and 63 other files break when it does.”
Terminal window
# Install (two commands in Claude Code)
/pluginmarketplaceaddchopratejas/vitals
/plugininstallvitals@vitals
# Scan from repo root
/vitals:scan
# Scope options
/vitals:scansrc/# Specific folder
/vitals:scan--top20# More results (default: 10)
/vitals:scansrc/auth--top5
What you get: Claude reads the flagged files and gives semantic diagnosis. Instead of “high complexity,” you get: “this class handles routing, caching, rate limiting, AND metrics in 7,137 lines — extract each concern.”
Status: v0.1 alpha. MIT. Zero dependencies (Python stdlib + git). Works on any repo.
Problem solved: AI-generated code contains subtle errors that survive code review because both the AI and the reviewer follow the same reasoning path. SE-CoVe breaks this by running an independent verifier that never sees the initial solution.
Research foundation: Adaptation of Meta’s Chain-of-Verification methodology (Dhuliawala et al., ACL 2024 Findings — arXiv:2309.11495).
How it works — 5-stage pipeline:
Baseline — Claude generates initial solution
Planner — Creates verification questions from the solution’s claims
Executor — Answers questions without seeing the baseline (prevents confirmation bias)
# Install (two separate commands — marketplace limitation)
/pluginmarketplaceaddvertti/se-cove-claude-plugin
/plugininstallchain-of-verification
# Use
/chain-of-verification:verify<yourquestion>
/ver<Tab># Autocomplete available
Trade-offs: ~2x token cost, reduced output volume. Worth it for security-sensitive code, complex debugging, and architectural decisions — not for rapid prototyping or simple fixes.
These tools solve different problems at different stages of the development cycle:
Vitals
SE-CoVe
When
Maintenance / weekly review
Per-task generation
Problem
Accumulated code debt
Per-solution accuracy
Input
Entire git history
A specific question
Output
Ranked hotspot files + diagnosis
Verified answer
Token cost
Low (Python analysis + Claude reads top files)
~2x standard generation
Best for
”Which file is going to break?"
"Is this solution correct?”
Status
v0.1 alpha
v1.1.1 stable
Complementary workflow: Run Vitals weekly to identify which areas of the codebase need attention, then use SE-CoVe when asking Claude to refactor or fix those hotspot files.
Not every change warrants SE-CoVe’s 5-stage pipeline. For everyday review within a single session, you can prompt Claude to switch from author to reviewer explicitly:
You just wrote the implementation above. Now forget you wrote it.
Review it as a senior engineer who did not author this code.
compatibility, security, performance. For each issue found, cite
the file and line, explain the problem, and propose a concrete fix.
Verdict: APPROVE, REQUEST CHANGES, or REJECT.
This works because the explicit instruction to “forget you wrote it” forces Claude to re-evaluate rather than defend prior decisions. It catches surface-level issues (missing null checks, inconsistent error handling, naming drift) but shares the same reasoning path as the author, so subtle architectural flaws may survive.
A single model reviewing its own code follows the same reasoning patterns that produced the code. Using a different model for review introduces genuinely independent analysis.
The pattern: generate with one model, review with another.
Terminal window
# Implement with Opus (deep reasoning)
claude--modelopus
# Review the diff with Sonnet (different reasoning path, lower cost)
claude-p"Review the changes in the last commit. Check for logic errors, \
edge cases, backward compatibility, and security issues. \
For each finding: severity (critical/high/medium), file:line, problem, fix.
If no issues found, say so explicitly.
Why different models catch different bugs: each model has distinct reasoning biases, training distributions, and failure modes. A bug that sits in one model’s blind spot may be obvious to another. This is the same principle behind diverse code review teams in traditional engineering.
Cost-effective patterns:
Generation Model
Review Model
Cost Multiplier
When
Opus
Sonnet
~1.3x
Default for critical code
Sonnet
Haiku
~1.05x
High-volume, pre-commit gate
Sonnet
Opus
~2x
Architecture, security-critical
Any
Same model, fresh session
~1.5x
Context isolation without model switch
The fresh session variant (same model, new context via claude -p) gives you context isolation without changing the model. Less effective than a true model switch but still better than reviewing in the same session where the code was written.
MCP servers extend Claude Code’s capabilities, but they also expand its attack surface. Before installing any MCP server, especially community-created ones, apply the same security scrutiny you’d use for any third-party code dependency.
CVE details & advanced vetting: For documented CVEs (2025-53109/53110, 54135, 54136), MCP Safe List, and incident response procedures, see Security Hardening Guide.
A malicious MCP server can declare tools with common names (like Read, Write, Bash) that shadow built-in tools. When Claude invokes what it thinks is the native Read tool, the MCP server intercepts the call.
Legitimate flow: Claude → Native Read tool → Your file
Mitigation: Check exposed tools with /mcp command. Use disallowedTools in settings to block suspicious tool names from specific servers.
Confused Deputy Problem
An MCP server with elevated privileges (database access, API keys) can be manipulated via prompt to perform unauthorized actions. The server authenticates Claude’s request but doesn’t verify the user’s authorization for that specific action.
Example: A database MCP with admin credentials receives a query from a prompt-injected request, executing destructive operations the user never intended.
Mitigation: Always configure MCP servers with read-only credentials by default. Only grant write access when explicitly needed.
Dynamic Capability Injection
MCP servers can dynamically change their tool offerings. A server might pass initial review, then later inject additional tools.
Mitigation: Pin server versions in your configuration. Periodically re-audit installed servers.
Note: disallowedTools is a root-level key or CLI flag (--disallowedTools), not nested under permissions. For settings.json, use permissions.deny to block tool patterns.