Session Buddy is an intelligent session management server for Claude Code that automates knowledge capture, enables cross-project intelligence, and provides advanced analytics — all with 100% local processing.
Core Capabilities:
Automatic Session Management: Auto-initializes and cleans up sessions for Git repositories, with manual controls for non-Git projects
Intelligent Knowledge Capture: Automatically extracts insights from conversations using SHA-256 deduplication
Cross-Project Intelligence: Shares knowledge across related projects with dependency-aware search for microservices, monorepos, and multi-repo setups
Memory & Search: Local DuckDB storage with semantic search using ONNX embeddings for cross-session conversation retention
Team Collaboration: Create teams, share knowledge with voting systems, and access control
Advanced Analytics: Real-time monitoring, predictive models, A/B testing, time-series analysis, and collaborative filtering
85+ Specialized Tools across 12 functional categories
Python Code Quality Analysis:
analyze_code: Full suite analysis on a file or directory — complexity, dead code, clone detection, coupling metrics, and dependency analysis
check_complexity: Measure cyclomatic complexity of functions with configurable min/max thresholds
check_coupling: Analyze class-level coupling using the CBO (Coupling Between Objects) metric
detect_clones: Find duplicate/near-duplicate code using APTED tree edit distance and LSH acceleration, with configurable similarity thresholds
find_dead_code: Identify unreachable code via Control Flow Graph (CFG) analysis with severity filtering (info, warning, error)
get_health_score: Generate an overall code health score (0–100) with a letter grade and category-level breakdowns
Provides automatic session lifecycle management for Git repositories, including automated initialization, quality checkpoints, and session cleanup with learning capture.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Session Buddy checkpoint the current session and analyze workflow efficiency"
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.
A session management MCP server for Claude Code.
A dedicated MCP server that manages session lifecycle, searchable memory, and cross-project intelligence for Claude Code sessions.
Session Buddy is the builder of the Bodai ecosystem — it persists, indexes, and recovers the conversation context that flows through Mahavishnu, Crackerjack, and the other components. Its knowledge graph captures cross-session decisions, agent recommendations, and session archaeology.
Standalone, Session Buddy is a session management MCP server for Claude Code — useful for any developer who wants searchable memory across multiple coding sessions. See bodai/docs for the full integration picture.
Related MCP server: Claude Session MCP
Crackerjack is the standard quality-control and CI/CD gate for Session Buddy. Use the same Crackerjack workflow locally that the project expects in CI.
Session Buddy focuses on three things that set it apart from a simple session log:
Session Buddy can extract structured insights from conversation patterns and make them searchable in later sessions. That reduces manual note-taking and turns normal development work into reusable project memory.
Session Buddy can surface relevant knowledge across related repos, services, or packages, which is especially useful for monorepos, microservices, and tightly coupled project families.
Local processing by default
Local embedding support
No required external API dependency for core workflows
Fast search and retrieval oriented toward interactive use
Session Buddy extends core session management with real-time monitoring, analytics, and cross-session learning.
WebSocket Server - Live dashboard streaming at 1-second intervals
Top 10 most active skills displayed in real-time
Performance anomaly detection with Z-score analysis
Client subscriptions (all skills or specific skill monitoring)
Prometheus Metrics - Monitoring export
5 metric types: Counters, Histograms, Gauges
HTTP endpoint on port 9090 for scraping
Thread-safe updates for concurrent access
Predictive Models - ML-based skill success prediction
RandomForest classifier with 7 features
30-day historical training window
Feature importance analysis
A/B Testing Framework - Experiment with recommendation strategies
Deterministic user assignment (SHA-256 hashing)
Statistical significance testing (t-test, p < 0.05)
Automated winner determination
Time-Series Analysis - Trend detection and forecasting
Linear regression trend detection
Hourly aggregation for dashboards
Anomaly detection using Z-scores
Collaborative Filtering - Learn from similar users
Jaccard similarity for user matching
Personalized recommendations
SHA-256 privacy hashing for user IDs
Community Baselines - Global skill effectiveness
Cross-user aggregation
Percentile rankings
User vs global comparisons
Crackerjack Integration - Quality gate tracking
Phase mapping to workflow stages
Automatic failure recommendations
ASCII workflow visualizations
IDE Plugin Protocol - Context-aware recommendations
Code pattern detection (tests, imports, async)
Language-specific skill patterns
Keyboard shortcut management
CI/CD Tracking - Pipeline analytics
Stage-by-stage monitoring
Bottleneck identification (< 80% success)
JSON export for dashboards
Categories - Organized skill domains
Code Quality, Testing, Documentation, Deployment, etc.
6 predefined categories
Multi-modal skill types (code → diagnostics, testing → test_results)
Dependencies - Co-occurrence patterns
Lift score calculation
Relationship mapping
Workflow-aware recommendations
Performance:
Real-time metrics: < 100ms
Anomaly detection: < 200ms
Collaborative filtering: < 200ms
MCP tools: < 50ms
Session Initialization: Setup with UV dependency management, project analysis, and automation tools
Quality Checkpoints: Mid-session quality monitoring with workflow analysis and optimization recommendations
Session Cleanup: Cleanup with learning capture and handoff file creation
Status Monitoring: Real-time session status and project context analysis
Auto-Generated Shortcuts: Automatically creates /start, /checkpoint, and /end Claude Code slash commands
Session Buddy includes local knowledge-capture and sharing features that help work carry across sessions and repos:
What It Does:
Automatically extracts educational insights from your conversations using deterministic pattern matching
Stores insights with semantic embeddings for later retrieval
Prevents duplicate capture through SHA-256 content hashing
Makes insights available across sessions via semantic search
How It Works:
When you use explanatory mode (like this session!), Session Buddy automatically captures insights marked with the ★ Insight ───── delimiter:
Some explanation text.
`★ Insight ─────────────────────────────────────`
Always use async/await for database operations to prevent blocking the event loop
`─────────────────────────────────────────────────`
More text here.Multi-Point Capture Strategy:
Checkpoint Capture: Extracts insights during mid-session quality checkpoints
Session End Capture: Additional extraction when session ends
Deduplication: SHA-256 hashing prevents storing duplicate insights
Session-Level Tracking: Maintains hash set across entire session
Benefits:
✅ Automatic Capture: Works automatically with explanatory mode
✅ No Hallucination: Rule-based extraction (not AI-generated)
✅ Conservative Capture: Better to miss an insight than invent one
✅ Measured Performance: <50ms extraction, <20ms semantic search
✅ Privacy-First: All processing done locally, no external APIs
Documentation: See docs/features/INSIGHTS_CAPTURE.md for complete details
What It Does:
Share knowledge across related projects automatically
Track project dependencies (uses, extends, references, shares_code)
Search across all projects with dependency-aware ranking
Coordinate microservices, monorepo modules, or related repositories
How It Works:
Create groups of related projects and define their relationships:
# Create project group
group = ProjectGroup(
name="microservices-app",
projects=["auth-service", "user-service", "api-gateway"],
description="Authentication and user management microservices",
)
# Define dependencies
deps = [
ProjectDependency(
source_project="user-service",
target_project="auth-service",
dependency_type="uses",
description="User service depends on auth service for validation",
),
ProjectDependency(
source_project="api-gateway",
target_project="user-service",
dependency_type="extends",
description="Gateway extends user service with rate limiting",
),
]Cross-Project Search:
Search across related projects automatically
Results ranked by dependency relationships
Understand how solutions propagate across your codebase
Benefits:
✅ Knowledge Reuse: Solutions found in one project help with related projects
✅ Dependency Awareness: Understand how changes ripple across projects
✅ Coordinated Development: Work effectively across multiple codebases
✅ Semantic Understanding: Find patterns even when projects use different terminology
Use Cases:
Microservices: Coordinate related services with shared patterns
Monorepos: Manage multiple packages/modules in one repository
Multi-Repo: Track patterns across separate but related repositories
For Git Repositories:
✅ Automatic initialization when Claude Code connects
✅ Automatic cleanup when session ends (quit, crash, or network failure)
✅ Automatic compaction during checkpoints
✅ Automatic in supported workflows
For Non-Git Projects:
📝 Use /start for manual initialization
📝 Use /end for manual cleanup
📝 Full session management features available on-demand
The server automatically detects git repositories and manages the session lifecycle with crash resilience and network failure recovery. Non-git projects retain manual control for flexible workflow management.
stateDiagram-v2
[*] --> GitRepo: Claude Code Connects
[*] --> ManualInit: Non-Git Project
GitRepo --> AutoStart: Auto-detect Git
AutoStart: Initialize Session
AutoStart --> Working: Development
ManualInit --> ManualStart: User runs /start
ManualStart: Initialize Session
ManualStart --> Working: Development
state Working {
[*] --> Active
Active --> Checkpoint: /checkpoint
Checkpoint --> Active: Continue Work
Active --> Monitoring: Track Quality
Monitoring --> Active
}
Working --> AutoEnd: Disconnect/Quit
Working --> ManualEnd: User runs /end
AutoEnd: Auto Cleanup
AutoEnd --> [*]: Session Handoff
ManualEnd: Manual Cleanup
ManualEnd --> [*]: Session Handoff
note right of AutoStart
Automatic Features:
- UV sync
- Project analysis
- Setup .claude/
- Create shortcuts
end note
note right of AutoEnd
Crash Resilient:
- Any disconnect
- Network failure
- System crash
All handled gracefully
end noteThis server provides 199 MCP tools across 31 tool groups (verified 2026-08-19 via SESSION_BUDDY_TOOL_PROFILE=full).
The actual count is gated by SESSION_BUDDY_TOOL_PROFILE (minimal/standard/full).
For a complete list of tools, see the MCP Tools Reference.
Session-Buddy conforms to the Bodai core MCP baseline (shared with mahavishnu, akosha, dhara, crackerjack). The following tools are registered on every profile:
Tool | Purpose |
| List registered tools, optionally filtered by name substring |
| Returns |
| Readiness probe over configured dependencies |
| Dependency health summary |
ping is preserved as a deprecated alias delegating to get_liveness and logs a WARN-level DeprecationWarning on every invocation. It will be removed in the next release; existing callers (Akosha's run_fitness_analysis, Mahavishnu's session_buddy_tools.py, Crackerjack's otel_ingester.py) should migrate to get_liveness.
Removed in 2026-08-12 audit: The following tools were documented but not wired into the default
server_optimized.pyentrypoint (which loadsregister_session_tools,register_memory_tools,register_fingerprint_tools,register_category_tools,register_code_graph_tools,register_prompt_tools). They remain available through the alternativesession_buddy.mcp.serverprofile-driven entrypoint whenSESSION_BUDDY_TOOL_PROFILE=fullis set, but the canonical Phase 4 / Intelligence sections below were misleading because the default startup does not register them.
start - Session initialization with project analysis and memory setup
checkpoint - Mid-session quality assessment with workflow analysis
end - Complete session cleanup with learning capture
status - Current session overview with health checks
store_reflection - Store insights with tagging and embeddings
quick_search - Fast overview search with count and top results
search_summary - Aggregated insights without individual result details
get_more_results - Pagination support for large result sets
search_by_file - Find conversations tied to a specific file
search_by_concept - Semantic search by concept with optional file context
Entity and relationship management for project knowledge
SQL/PGQ graph queries for complex relationship analysis
All tools use local processing for privacy, with DuckDB vector storage (FLOAT[384] embeddings) and HTTP embedding via llama-server (preferred) or Ollama with graceful degradation; 384-dim vectors from all-MiniLM-L6-v2 or nomic-embed-text.
Session Buddy includes deep integration with Crackerjack, the AI-driven Python development platform:
Key Features:
Quality Metrics Tracking: Automatically captures and tracks quality scores over time
Test Result Monitoring: Learns from test patterns, failures, and successful fixes
Error Pattern Recognition: Remembers how specific errors were resolved and suggests solutions
Example Workflow:
🚀 Session Buddy start - Sets up your session with accumulated context from previous work
🔧 Crackerjack runs quality checks and applies AI agent fixes to resolve issues
💾 Session Buddy captures successful patterns and error resolutions
🧠 Next session starts with all accumulated knowledge
For detailed information on Crackerjack integration, see Crackerjack Integration Guide.
# Clone the repository
git clone https://github.com/lesleslie/session-buddy.git
cd session-buddy
# Install with all dependencies (development + testing)
uv sync --group dev
# Or install minimal production dependencies only
uv sync
# Or use pip (for production only)
pip install session-buddyAdd to your project's .mcp.json file:
{
"mcpServers": {
"session-buddy": {
"command": "python",
"args": ["-m", "session_buddy.server"],
"cwd": "/path/to/session-buddy",
"env": {
"PYTHONPATH": "/path/to/session-buddy"
}
}
}
}If installed with pip/uv, you can use the script entry point:
{
"mcpServers": {
"session-buddy": {
"command": "session-buddy",
"args": [],
"env": {}
}
}
}Dependencies: Requires Python 3.13+. For a complete list of dependencies, see pyproject.toml.
This downloads the Xenova/all-MiniLM-L6-v2 model (~100MB) which includes:
Pre-converted ONNX model (no PyTorch needed!)
384-dimensional embeddings for semantic similarity
Fast CPU inference with ONNX Runtime
Note: Text search is highly effective and recommended for most use cases. Semantic search provides enhanced conceptual matching by understanding meaning beyond keywords.
Once configured, the following slash commands become available in Claude Code:
Primary Session Commands:
/session-buddy:start - Full session initialization
/session-buddy:checkpoint - Quality monitoring checkpoint with scoring
/session-buddy:end - Complete session cleanup with learning capture
/session-buddy:status - Current status overview with health checks
Auto-Generated Shortcuts:
After running /session-buddy:start once, these shortcuts are automatically created:
/start → /session-buddy:start
/checkpoint [name] → /session-buddy:checkpoint
/end → /session-buddy:end
These shortcuts are created in
~/.claude/commands/and work across all projects
Memory & Search Commands:
/session-buddy:quick_search - Fast search with overview results
/session-buddy:search_summary - Aggregated insights without full result lists
/session-buddy:get_more_results - Paginate search results
/session-buddy:search_by_file - Find results tied to a specific file
/session-buddy:search_by_concept - Semantic search by concept
/session-buddy:search_code - Search code-related conversations
/session-buddy:search_errors - Search error and failure discussions
/session-buddy:search_temporal - Search using time expressions
/session-buddy:store_reflection - Store important insights with tagging
/session-buddy:reflection_stats - Stats about the reflection database
For running the server directly in development mode:
python -m session_buddy.server
# or
session-buddyBuilt-in Conversation Memory:
Local Storage: DuckDB database at ~/.claude/data/reflection.duckdb
Embeddings: Local ONNX models for semantic search (no external API needed)
Privacy: Everything runs locally with no external dependencies
Cross-Project: Conversations tagged by project context for organized retrieval
Search Capabilities:
Semantic Search: Vector similarity matching with customizable thresholds
Time Decay: Recent conversations prioritized in results
Filtering: Search by project context or across all projects
This server manages its data locally in the user's home directory:
Memory Storage: ~/.claude/data/reflection.duckdb
Session Logs: ~/.claude/logs/
Configuration: Uses pyproject.toml and environment variables
Initialize Session: /session-buddy:start - Sets up project context, dependencies, and memory system
Monitor Progress: /session-buddy:checkpoint (every 30-45 minutes) - Quality scoring and optimization
Search Past Work: /session-buddy:quick_search or /session-buddy:search_summary - Find relevant past conversations and solutions
Store Important Insights: /session-buddy:store_reflection - Capture key learnings for future sessions
End Session: /session-buddy:end - Final assessment, learning capture, and cleanup
Automatic Insights Capture: Extracts educational insights from conversations without manual effort
Semantic Pattern Discovery: Find related insights across sessions using vector embeddings
Cross-Project Learning: Share knowledge between related projects automatically
Dependency Awareness: Understand how solutions propagate across your codebase
Team Knowledge Base: Collaborative filtering and voting for best practices
No Hallucination: Rule-based extraction ensures only high-quality insights are captured
Session Quality: Real-time monitoring and optimization
Memory Persistence: Cross-session conversation retention
Project Structure: Context-aware development workflows
Single Command Setup: One /session-buddy:start sets up everything
Local Dependencies: No external API calls or services required
Permission Memory: Reduces repeated permission prompts
Automated Workflows: Structured processes for common tasks
Quality Scoring: Guides session effectiveness
Built-in Memory: Enables building on past work automatically
Project Templates: Accelerates development setup
Knowledge Persistence: Maintains context across sessions
Complete documentation is available in the docs/ directory:
Intelligence Features Quick Start ⭐ Start Here - 5-minute practical guide
Automatic insights capture (how to use ★ Insight ───── delimiters)
Cross-project intelligence (group related projects)
Team collaboration (shared knowledge with voting)
Advanced search techniques (semantic, faceted, temporal)
Configuration and troubleshooting
Insights Capture & Deduplication ⭐ Deep Dive
Automatic extraction of educational insights from conversations
Multi-point capture strategy (checkpoint + session end)
SHA-256 deduplication to prevent duplicate insights
Semantic search with wildcard support
Complete test coverage (62/62 tests passing)
Architecture and implementation details
User Documentation - Quick start, configuration, and deployment guides
Quick Start Guide - Get started in 5 minutes
Configuration Guide - Advanced configuration options
MCP Tools Reference - Complete tool documentation
Developer Documentation - Architecture, testing, and integration guides
Oneiric Migration Guide - Database migration
Architecture Overview - System design and patterns
Feature Guides - In-depth documentation of specific features
Token Optimization - Context window management
Selective Auto-Store - Reflection storage policy
Auto Lifecycle - Automatic session management
Reference - MCP schemas and command references
Common Issues:
Memory/embedding issues: Ensure all dependencies are installed with uv sync
Path errors: Verify cwd and PYTHONPATH are set correctly in .mcp.json
Permission issues: Remove ~/.claude/sessions/trusted_permissions.json to reset trusted operations
Debug Mode:
# Run with verbose logging
PYTHONPATH=/path/to/session-buddy python -m session_buddy.server --debugFor more detailed troubleshooting guidance, see Configuration Guide or Quick Start Guide.
Comprehensive Python code quality analysis with complexity, dead code, clone detection, and coupling metrics
| Name | Required | Description | Default |
|---|---|---|---|
| analyses | No | Array of analyses to run. Options: complexity, dead_code, clone, cbo, deps. Default: all analyses | |
| path | Yes | Path to Python code (file or directory) to analyze | |
| recursive | No | Recursively analyze directories (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide key behavioral hints (destructiveHint: true, readOnlyHint: false, etc.), so the description doesn't need to repeat these. It adds value by specifying the types of analyses performed (complexity, dead code, etc.), but doesn't elaborate on side effects, rate limits, or output format beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key analyses without unnecessary details. Every word contributes to understanding the tool's scope, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple analysis types, destructive hint) and lack of output schema, the description is adequate but incomplete. It covers what analyses are performed but doesn't explain output format, error handling, or how results are returned, leaving gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantics by listing analysis types (e.g., complexity, dead_code) that align with the enum options, but doesn't provide additional context beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Python code quality analysis' with specific metrics (complexity, dead code, clone detection, coupling), which is a specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like check_complexity or detect_clones, which appear to handle individual analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It mentions 'comprehensive' analysis but doesn't specify scenarios where this is preferred over individual analysis tools like check_complexity or detect_clones, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze cyclomatic complexity of Python functions
| Name | Required | Description | Default |
|---|---|---|---|
| max_complexity | No | Maximum allowed complexity, 0 = no limit (default: 0) | |
| min_complexity | No | Minimum complexity to report (default: 1) | |
| path | Yes | Path to Python code to analyze | |
| show_details | No | Include detailed metrics (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, covering key behavioral traits. The description adds no additional context about what gets destroyed, authentication needs, rate limits, or other behaviors beyond annotations, but it doesn't contradict them, so it meets the lower bar with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on output format, error handling, or integration with sibling tools, which could help the agent use it more effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema. The description adds no extra meaning beyond the schema, such as explaining interactions between parameters or practical usage examples, so it defaults to the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('analyze') and resource ('cyclomatic complexity of Python functions'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'analyze_code' or 'find_dead_code', which might also analyze Python code metrics, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'analyze_code' or 'check_coupling'. It lacks context about specific scenarios, exclusions, or prerequisites, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze class coupling (CBO - Coupling Between Objects) metrics
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to Python code to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide key behavioral hints: readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description doesn't contradict these annotations, and it adds context by specifying the type of analysis (CBO metrics). However, it doesn't elaborate on what 'destructive' means in this context (e.g., whether it modifies files or just analyzes them), which could be useful. No annotation contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Analyze class coupling (CBO - Coupling Between Objects) metrics.' It is front-loaded with the core purpose and uses no unnecessary words, making it efficient and easy to understand. Every part of the sentence contributes directly to clarifying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing code metrics), annotations cover behavioral aspects like destructiveness and idempotency, and the schema fully documents the single parameter. However, there is no output schema, so the description doesn't explain return values or results, which is a gap. The description is adequate but could benefit from more context on what the analysis entails or outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter clearly documented as 'Path to Python code to analyze.' The description doesn't add any extra meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze class coupling (CBO - Coupling Between Objects) metrics.' It specifies the verb 'analyze' and the resource 'class coupling metrics,' which is specific and informative. However, it doesn't explicitly distinguish this tool from its siblings like 'analyze_code' or 'check_complexity,' which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'analyze_code' or 'check_complexity' for comparison. This lack of usage instructions makes it difficult for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect code clones using APTED tree edit distance and LSH acceleration
| Name | Required | Description | Default |
|---|---|---|---|
| group_clones | No | Group related clones together (default: true) | |
| min_lines | No | Minimum lines to consider as clone (default: 5) | |
| path | Yes | Path to Python code to analyze | |
| similarity_threshold | No | Minimum similarity threshold 0.0-1.0 (default: 0.8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive, non-idempotent, non-read-only operation with open-world data. The description adds value by specifying the algorithms used (APTED and LSH), which helps the agent understand computational behavior, but doesn't elaborate on side effects, rate limits, or output format beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Detect code clones') and adds technical details (algorithms) that are relevant for agent understanding, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive analysis with multiple parameters) and lack of output schema, the description is minimal. It covers the purpose and methods but omits details on output format, error handling, or performance considerations, leaving gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional parameter semantics beyond implying analysis of Python code via 'path', which is already covered. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detect code clones' using specific algorithms (APTED tree edit distance and LSH acceleration). It specifies the resource (Python code) and method, but doesn't explicitly differentiate from sibling tools like 'find_dead_code' or 'analyze_code' beyond the clone detection focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'find_dead_code' or 'analyze_code'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find unreachable code using Control Flow Graph (CFG) analysis
| Name | Required | Description | Default |
|---|---|---|---|
| min_severity | No | Minimum severity: info, warning, error (default: warning) | |
| path | Yes | Path to Python code to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, readOnlyHint: false, openWorldHint: true, and idempotentHint: false, suggesting this tool performs mutable, non-idempotent operations with potential side effects. The description adds value by specifying the analysis method ('CFG analysis'), but it doesn't elaborate on what 'destructive' entails (e.g., modifies files, generates reports) or other behavioral traits like rate limits or authentication needs. With annotations covering key aspects, the description provides some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Find unreachable code using Control Flow Graph (CFG) analysis'. It is front-loaded with the core purpose and method, with no unnecessary words or redundancy. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations (including destructiveHint: true) but no output schema, the description is moderately complete. It specifies the analysis method ('CFG analysis'), which adds context beyond the annotations. However, it doesn't explain the output format, potential side effects from the destructive hint, or how results are returned, leaving gaps that could hinder an AI agent's understanding of the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'min_severity' (minimum severity level with default) and 'path' (path to Python code). The description doesn't add any semantic details beyond the schema, such as explaining how 'CFG analysis' interacts with these parameters or providing examples. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find unreachable code using Control Flow Graph (CFG) analysis'. It specifies the verb ('Find'), resource ('unreachable code'), and method ('CFG analysis'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'analyze_code' or 'detect_clones', which might also analyze code structure, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'check_complexity' or 'detect_clones'. Without this context, an AI agent might struggle to choose this tool appropriately in a multi-tool environment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall code health score (0-100) with grade and category scores
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to Python code to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, suggesting potential side effects, but the description doesn't explain what gets destroyed or altered (e.g., if analysis modifies files or consumes resources). It adds context about the output format (score range, grade, categories), which is useful since there's no output schema, but fails to address the destructive behavior hinted by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key output details. Every word adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the basic purpose and output format adequately. However, given the annotations hint at destructive behavior and the lack of usage guidelines or behavioral details, it leaves gaps in understanding when and how to use the tool safely, especially compared to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'path' parameter. The description doesn't add any parameter-specific details beyond what the schema provides, such as path format examples or constraints. With high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('overall code health score') with specific output details (0-100 range, grade, category scores). It distinguishes from siblings by focusing on a comprehensive health metric rather than specific analyses like complexity or dead code detection, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., analyze_code, check_complexity). The description implies a broad health assessment, but it doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.14.3analyze_codecheck_complexitycheck_couplingdetect_clonesfind_dead_codeget_health_scoreThe tools have overlapping purposes that could cause confusion, particularly between analyze_code and the more specific tools like check_complexity and check_coupling. While descriptions clarify their focus, an agent might struggle to choose between analyze_code (which includes complexity and coupling) and the dedicated tools, leading to potential misselection.
All tool names follow a consistent verb_noun pattern (e.g., analyze_code, check_complexity, detect_clones), using snake_case throughout. This predictability makes it easy for agents to parse and understand the naming conventions without confusion.
With 6 tools, the count is well-scoped for a code analysis server, covering key aspects like complexity, coupling, clones, and dead code. Each tool appears to earn its place without feeling excessive or insufficient for the domain.
The tool set provides good coverage for code quality analysis, including metrics, clone detection, and dead code. A minor gap exists in areas like code style or security analysis, but agents can likely work around this with the available tools for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lesleslie/session-buddy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server