Generates Mermaid flowchart diagrams from code call graphs, with both standard visualization and LLM-optimized token-efficient formats for AI analysis
Analyzes Python codebases using AST parsing to extract function metadata, build call graphs, and provide semantic search capabilities
Provides code analysis capabilities for TypeScript projects, including AST parsing and call graph generation
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., "@CodeFlow MCP Server show me the call graph for the authentication module"
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.
CodeFlow is a powerful code analysis tool designed to help developers and autonomous agents understand complex codebases with minimal cognitive overhead. It generates detailed call graphs, identifies critical code elements, and provides semantic search capabilities, all while adhering to principles that prioritize human comprehension.
By extracting rich metadata from Tree-sitter ASTs and leveraging a persistent vector store (ChromaDB), CodeFlow enables efficient querying and visualization of code structure and behavior across Python, TypeScript/TSX, and Rust codebases.
The tool provides three main interfaces:
CLI Tool: A command-line interface for direct analysis and querying of codebases.
MCP Server: A Model Context Protocol server that integrates with AI assistants and IDEs for real-time code analysis.
Unified API: A single programmatic interface that automatically detects and analyzes both Python and TypeScript codebases.
Related MCP server: Codebase Contextifier 9000
Deep AST Metadata Extraction (Python, TypeScript/TSX, Rust via Tree-sitter): Gathers comprehensive details about functions and classes including:
Parameters, return types, docstrings
Cyclomatic complexity and Non-Comment Lines of Code (NLOC)
Applied decorators (e.g., @app.route, @transactional)
Explicitly caught exceptions
Locally declared variables
Inferred external library/module dependencies
Source body hash for efficient change detection
Structured Data Indexing (JSON/YAML):
Parses and indexes configuration files (.json, .yaml, .yml).
Enables semantic search for configuration keys and values (e.g., "database port", "api url").
Flattens hierarchical data into semantic chunks for precise retrieval.
Unified Interface: Single API that automatically detects and analyzes Python, TypeScript/TSX, and Rust codebases without manual language specification.
Intelligent Call Graph Generation:
Builds a graph of function-to-function calls.
Employs multiple heuristics to identify potential entry points in the codebase.
Scores and categorizes entry points (runtime/framework/library/test) for prioritization.
Persistent Vector Store (ChromaDB):
Stores all extracted code elements and call edges as semantic embeddings.
Enables rapid semantic search and filtered queries over the codebase's functions and their metadata.
Persists analysis results to disk, allowing instant querying of previously analyzed projects without re-parsing.
Automatic Cleanup: Background process removes stale references to deleted files, keeping the index accurate and efficient.
Mermaid Diagram Visualization:
Generates text-based Mermaid Flowchart syntax for call graphs.
Highlights functions relevant to a semantic query.
Includes an LLM-optimized mode for concise, token-efficient graph representations suitable for Large Language Model ingestion, providing clear aliases and FQN mappings.
Real-time Analysis: File watching with incremental updates for dynamic codebases.
Background Maintenance: Automatic cleanup of stale file references in the vector store to maintain index accuracy.
Tool-based API: Exposes analysis capabilities through MCP tools for AI assistants.
Session Context: Maintains per-session state for complex analysis workflows.
Comprehensive Tools: Semantic search, call graph generation, function metadata retrieval, entry point identification, impact analysis, and Mermaid graph generation.
Batch Analysis: Complete codebase analysis with report generation.
Interactive Querying: Semantic search against analyzed codebases.
Flexible Output: JSON reports, Mermaid diagrams, and console output.
Incremental Updates: Query existing analyses without full re-processing.
Call Graph Metrics: Writes .codeflow/reports/call_graph_metrics.json and .codeflow/reports/call_graph_metrics.md for baseline comparisons.
Designed with principles to make the tool's output and its own codebase easy to understand and use.
Mental Model Simplicity: Clear, predictable patterns in code and output.
Explicit Behavior: Favor clarity over brevity, making implicit actions visible (e.g., decorators).
Information Hiding & Locality: Well-defined modules, keeping related code together.
Minimal Background Knowledge: Self-describing data, common patterns, reduced need for memorization.
Strategic Abstraction: Layers introduced only when they genuinely reduce overall complexity.
Linear Understanding: Code and output structured for easy top-to-bottom reading.
System | Project Size | Indexing Time |
RooCode | 40k LOC | 2.2 min |
CodeFlow | 40k LOC | 8.6s |
Before running CodeFlow, ensure you have Python 3.8+ and the following dependencies installed:
chromadb
sentence-transformers
hdbscan
scikit-learn
mcp[cli]
pyyaml
watchdog>=2.0
pytest
pytest-asyncio
pydantic
tree-sitter
tree-sitter-python
tree-sitter-typescript
tree-sitter-rustInstall the CLI and MCP server as user-level tools:
uv tool install code-flowExpose uv's tool bin directory on your PATH:
export PATH="$(uv tool dir --bin):$PATH"Add the export to your shell profile (e.g., ~/.zshrc) to persist it.
One-off execution without installation:
uvx --from code-flow code_flow --helpClone the repository and install dependencies:
git clone https://github.com/yourusername/codeflow.git
cd codeflow
pip install -e .This will install the package in editable mode and make both the CLI tool and MCP server available.
The CLI tool is available as a module:
code_flow --helpThe MCP server is available as a script:
code_flow_mcp_server --helpThe code_flow.cli.code_flow module is the main entry point for command-line analysis. All commands start with a subcommand:
code_flow analyze -- [YOUR_CODE_DIRECTORY]
Replace [YOUR_CODE_DIRECTORY] with the path to your project. If omitted, the current directory (.) will be used.
This command will parse your codebase, build the call graph, populate the ChromaDB vector store (persisted in <project_root>/.codeflow/chroma/), and generate a JSON report. Language detection is automatic.
code_flow analyze -- [YOUR_CODE_DIRECTORY] --output my_analysis_report.jsonRun a full analysis and then immediately perform a semantic search. This will update the vector store if code has changed.
code_flow query -- [YOUR_CODE_DIRECTORY] --query "functions that handle user authentication"Once a codebase has been analyzed (i.e., the .codeflow/chroma/ directory exists under project_root), you can query it much faster without re-running the full analysis:
code_flow query -- [YOUR_CODE_DIRECTORY] --no-analyze --query "functions related to data serialization"You can generate Mermaid diagrams of the call graph for functions relevant to your query.
Standard Mermaid (for visual rendering):
code_flow query -- [YOUR_CODE_DIRECTORY] --query "database connection pooling" --mermaidThe output is Mermaid syntax, which can be copied into a Mermaid viewer (e.g., VS Code extension, Mermaid.live) for visualization.
LLM-Optimized Mermaid (for AI agents):
code_flow query -- [YOUR_CODE_DIRECTORY] --query "main entry point setup" --llm-optimizedThis output is stripped of visual styling and uses short aliases for node IDs, with explicit %% Alias: ShortID = Fully.Qualified.Name comments. This minimizes token count for LLMs while providing all necessary structural information.
Common arguments (available on subcommands):
<directory>: (Positional, optional) Path to the codebase directory. If provided, overrides watch_directories in config. If not provided, uses watch_directories from config or defaults to current directory.
--config: Path to configuration YAML file (default: codeflow.config.yaml).
--embedding-model: Embedding model to use. Shortcuts: fast (384-dim), medium (384-dim), or accurate (768-dim). Default: fast. See Embedding Model Configuration for details.
--max-tokens: Maximum tokens per chunk for embedding model. Default: 256. Increase for larger context windows (must match model max sequence length).
--language: Force language selection (python, typescript, rust). Defaults to auto-detection.
Subcommand-specific arguments:
analyze: --output, --summaries, --drift.
query: --query, --no-analyze, --mermaid, --llm-optimized, --limit.
graphs: --format, --fqns, --output, --llm-optimized.
drift: --output.
memory: add|query|list|reinforce|forget.
The code_analysis_report.json provides a comprehensive JSON structure including a summary, identified entry points, class summaries, and a detailed call graph (functions with all metadata, and edges).
The MCP server provides programmatic access to CodeFlow's analysis capabilities through the Model Context Protocol. It can be integrated with AI assistants, IDEs, and other MCP-compatible tools.
Start the MCP server with default configuration:
code_flow_mcp_serverOr with a custom configuration file:
code_flow_mcp_server --config path/to/config.yamlNote: The server looks for codeflow.config.yaml in the current directory by default.
Background Analysis: The server starts immediately and accepts connections while analyzing the codebase in the background. During the initial analysis, tools may return empty or partial results as the codebase is being indexed. This is normal behavior for first-time scans. Use the ping tool to check analysis progress.
The server exposes the following tools through the MCP protocol:
ping: Test server connectivity and check analysis status. Returns current analysis state (not_started, in_progress, completed, failed) and count of indexed functions.
semantic_search: Search functions semantically using natural language queries. Includes analysis status in response.
get_call_graph: Retrieve call graph in JSON or Mermaid format. Includes analysis status in response.
get_function_metadata: Get detailed metadata for a specific function. Includes analysis status in response.
query_entry_points: Get identified entry points with pagination (limit, offset). Returns minimal fields by default; set include_details=true for full metadata. Includes scoring fields entry_point_score, entry_point_category, entry_point_priority, entry_point_signals.
generate_mermaid_graph: Generate Mermaid diagram for call graph visualization. Includes analysis status in response.
cleanup_stale_references: Manually trigger cleanup of stale file references in the vector store
update_context: Update session context with key-value pairs
get_context: Retrieve current session context
reinforce_memory: Create or reinforce a Cortex memory entry (TRIBAL/EPISODIC/FACT).
query_memory: Search Cortex memory with decay-aware ranking.
list_memory: List Cortex memory entries with filters/pagination.
forget_memory: Delete a Cortex memory entry by id.
Resources: memory://top and memory://<knowledge_id> expose top Cortex memories as MCP resources.
Note: All analysis-dependent tools include an analysis_status field in their responses to inform clients about the current state of code analysis.
Use the included client to test server functionality:
python client.pyThis performs a handshake and tests basic tool functionality.
Both the CLI tool and MCP server share a central configuration system. The default configuration file is codeflow.config.yaml in the current working directory.
project_root: "/path/to/project"
watch_directories: ["."] # Directories to analyze (default: current directory)
ignored_patterns: ["venv", "**/__pycache__", ".git", "node_modules"] # Patterns to ignore
max_graph_depth: 3 # Maximum depth for graph traversal
embedding_model: "all-MiniLM-L6-v2" # Embedding model to use
max_tokens: 256 # Maximum tokens per chunk
language: "python" # Default language ("python", "typescript", or "rust")
call_graph_confidence_threshold: 0.8
incremental_debounce_seconds: 0.5 # Per-file debounce window for watcher events
incremental_inflight_dedupe_enabled: true # Prevent concurrent duplicate re-indexing for the same file
incremental_max_pending_per_file: 1 # Max follow-up runs queued while a file is already in-flightCustomize these settings by creating your own config file and passing it with --config.
memory_enabled: true
memory_collection_name: "cortex_memory_v1"
memory_similarity_weight: 0.7
memory_score_weight: 0.3
memory_min_score: 0.1
memory_cleanup_interval_seconds: 3600
memory_grace_seconds: 86400
memory_half_life_days:
TRIBAL: 180.0
EPISODIC: 7.0
FACT: 30.0
memory_decay_floor:
TRIBAL: 0.1
EPISODIC: 0.01
FACT: 0.05# Add tribal memory
code_flow memory add --type TRIBAL --content "Use snake_case for DB columns" --tags conventions
# Query memory
code_flow memory query --query "DB column naming" --type TRIBAL --limit 5
# List episodic memory
code_flow memory list --type EPISODIC --limit 10
# Reinforce and forget
code_flow memory reinforce --knowledge-id <uuid>
code_flow memory forget --knowledge-id <uuid>CodeFlow uses SentenceTransformers for semantic code search. You can choose between different embedding models to balance speed and accuracy:
Shorthand | Model Name | Dimensions | Speed | Use Case |
|
| 384 | Fastest | Quick analysis, smaller codebases |
|
| 384 | Balanced | Good balance of speed and quality |
|
| 768 | Slower | Detailed analysis, larger codebases |
Use the --embedding-model flag with either a shorthand or specific model name:
# Using shorthand (recommended)
code_flow analyze -- . --embedding-model fast
code_flow analyze -- . --embedding-model accurate
# Using specific model name
code_flow analyze -- . --embedding-model all-MiniLM-L6-v2Adjust chunk size with --max-tokens (default: 256):
# Note: all models have max sequence length of 384 tokens
code_flow analyze -- . --embedding-model accurate --max-tokens 384Configure in your YAML config file:
# Fast configuration (default)
embedding_model: "all-MiniLM-L6-v2"
max_tokens: 256
# Accurate configuration (max sequence length is 384)
embedding_model: "all-mpnet-base-v2"
max_tokens: 384Consistency: Once a vector store is created with a specific embedding dimension (384 or 768), you must continue using models with the same dimension. CodeFlow will automatically detect and use the existing dimension.
Performance: 384-dim models are ~2x faster than 768-dim models with minimal accuracy loss for code search.
Custom Models: You can specify any SentenceTransformer model name. See the full list.
CodeFlow supports optional LLM-driven semantic code summaries to enhance context retrieval for AI agents. This feature generates concise, natural-language summaries of functions and classes that are indexed alongside the code, enabling more efficient and accurate semantic search.
Enable summary generation in your codeflow.config.yaml:
# Summary Generation (Meta-RAG)
summary_generation_enabled: false # Set to true to enable
llm_config:
api_key_env_var: "OPENAI_API_KEY"
base_url: "https://openrouter.ai/api/v1" # Default: OpenRouter
model: "x-ai/grok-4.1-fast" # Default model
max_tokens: 256 # Max tokens in LLM response per summary
concurrency: 5 # Number of parallel summary generation workers
# Smart filtering to reduce costs
min_complexity: 3 # Only summarize functions with complexity >= 3
min_nloc: 5 # Only summarize functions with >= 5 lines of code
skip_private: true # Skip functions starting with _ (private)
skip_test: true # Skip test functions (test_*, *_test)
prioritize_entry_points: true # Summarize entry points first
# Depth control
summary_depth: "standard" # "minimal", "standard", "detailed"
max_input_tokens: 2000 # Truncate function body if longerSmart Filtering Options:
min_complexity: Only summarize functions with cyclomatic complexity >= threshold (default: 0)
min_nloc: Only summarize functions with >= N lines of code (default: 0)
skip_private: Skip private functions - supports both Python (_prefix) and TypeScript (private/protected modifiers) (default: false)
skip_test: Skip test functions (names containing "test") (default: false)
prioritize_entry_points: Process entry points first (default: false)
Depth Control:
minimal: Just name, signature, and code (lowest cost)
standard: Adds docstring (balanced)
detailed: Includes complexity, NLOC, decorators (highest quality)
Token Limits:
max_tokens: Maximum tokens in LLM response (controls summary length)
max_input_tokens: Truncate function body if longer (controls input cost)
You can override configuration via environment variables:
OPENAI_API_KEY: Your LLM API key (required when summary generation is enabled)
OPENAI_BASE_URL: Override the base URL (default: https://openrouter.ai/api/v1)
OPENAI_SUMMARY_MODEL: Override the model (default: x-ai/grok-4.1-fast)
Background Processing: Summaries are generated asynchronously in the background after code analysis completes
Resumable: On restart, CodeFlow automatically identifies and generates summaries for any functions missing them
Parallel Generation: Multiple LLM requests run concurrently (configurable via concurrency)
Retrieval: Summaries are returned via the get_function_metadata tool and included in semantic search results
# Enable in config, then start MCP server
export OPENAI_API_KEY="your-api-key"
code_flow_mcp_server
# Summaries will be generated in the background
# Check progress with the ping toolSummary generation incurs LLM API costs (typically $0.001-0.01 per function depending on model)
The feature is disabled by default to avoid unexpected costs
Use faster, cheaper models like grok-4.1-fast for cost-effective summarization
Summaries are cached in ChromaDB and only regenerated when code changes
CodeFlow provides comprehensive TypeScript analysis capabilities with feature parity to Python support. It can analyze TypeScript applications, extract detailed metadata, and build call graphs for various TypeScript frameworks.
TypeScript analysis is performed using Tree-sitter parsing with the bundled language grammars.
# Analyze a TypeScript project (language detection is automatic)
code_flow analyze -- /path/to/typescript/project --output analysis.json
# Query TypeScript codebase
code_flow query -- /path/to/typescript/project --query "user authentication functions"Angular Application Analysis:
# Analyze Angular project (language detection automatic)
code_flow query -- /path/to/angular-app --query "component lifecycle methods"
# Find Angular services
code_flow query -- /path/to/angular-app --query "injectable services"NestJS Application Analysis:
# Analyze NestJS backend (language detection automatic)
code_flow query -- /path/to/nestjs-app --query "controller endpoints"
# Find service dependencies
code_flow query -- /path/to/nestjs-app --query "database service dependencies"React TypeScript Analysis:
# Analyze React TypeScript components (language detection automatic)
code_flow query -- /path/to/react-ts-app --query "custom hooks"
# Find component prop types
code_flow query -- /path/to/react-ts-app --query "component interfaces"Type System Analysis:
Interface Detection: Identifies and extracts TypeScript interfaces and their implementations
Type Annotations: Analyzes function parameters and return types
Generic Types: Handles generic type definitions and constraints
Union/Intersection Types: Processes complex type definitions
Decorator Analysis: Detects Angular, NestJS, and custom decorators
Framework Pattern Recognition:
Angular: Component, Service, Module, Directive decorators
NestJS: Controller, Injectable, Module decorators
Express: Route handlers and middleware detection
React: Component classes and hooks detection
The tool automatically detects and parses tsconfig.json for project structure information:
{
"compilerOptions": {
"target": "ES2020",
"module": "commonjs",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
},
"include": ["src/**/*"],
"exclude": ["node_modules", "dist"]
}Supported File Types:
.ts - TypeScript files
.tsx - TypeScript React/JSX files
CodeFlow uses Tree-sitter parsing for TypeScript analysis, providing comprehensive support for:
Type annotations and generics
Classes, interfaces, and enums
Decorators and access modifiers
Framework patterns (Angular, React, NestJS, Express)
Import/export analysis
CodeFlow includes Rust analysis powered by Tree-sitter, enabling call graph generation and semantic search for .rs codebases.
Rust analysis uses the bundled tree-sitter-rust grammar.
# Analyze a Rust project (language detection is automatic)
code_flow analyze -- /path/to/rust/project --output analysis.json
# Query Rust codebase
code_flow query -- /path/to/rust/project --query "trait implementations"Supported File Types:
.rs - Rust source files
# Analyze current directory and generate report (language detection automatic)
code_flow analyze -- . --output analysis.json
# Analyze a specific project
code_flow analyze -- /path/to/my/project# Find authentication functions
code_flow query -- . --query "user authentication login"
# Search for database operations
code_flow query -- . --query "database queries CRUD operations"# Generate Mermaid diagram for API endpoints
code_flow query -- . --query "API endpoints" --mermaid
# LLM-optimized graph for AI analysis
code_flow query -- . --query "error handling" --llm-optimized{
"tool": "semantic_search",
"input": {
"query": "functions that handle user authentication",
"n_results": 5,
"filters": {}
}
}{
"tool": "get_function_metadata",
"input": {
"fqn": "myapp.auth.authenticate_user"
}
}{
"tool": "get_call_graph",
"input": {
"fqns": ["myapp.main"],
"format": "mermaid"
}
}{
"tool": "update_context",
"input": {
"current_focus": "authentication_module",
"analysis_depth": "detailed"
}
}Run the MCP server test suite:
pytest tests/mcp_server/This includes tests for:
Server initialization and tool registration
Tool functionality (semantic search, call graphs, etc.)
Configuration loading
File watching and incremental updates
Test the CLI tool by running analysis on the test files:
# Test basic functionality
code_flow analyze -- tests/ --output test_report.json
# Test querying
code_flow query -- tests/ --query "test functions"Use the client script for end-to-end testing:
python client.pyThis tests the MCP protocol handshake and basic tool interactions.
For programmatic access, CodeFlow provides a unified interface that automatically detects and analyzes both Python and TypeScript codebases:
from code_flow.core import create_extractor, extract_from_file, extract_from_directory, get_language_from_extension
# Create appropriate extractor based on file type (automatic language detection)
extractor = create_extractor('myfile.ts') # Returns TreeSitterTypeScriptExtractor
extractor = create_extractor('myfile.py') # Returns TreeSitterPythonExtractor
extractor = create_extractor('myfile.rs') # Returns TreeSitterRustExtractor
# Single API for both languages
elements = extract_from_file('myfile.ts') # Works for TypeScript
elements = extract_from_file('myfile.py') # Works for Python
elements = extract_from_file('myfile.rs') # Works for Rust
# Directory processing with automatic language detection
elements = extract_from_directory('./src') # Processes all Python, TypeScript, and Rust files
# Manual language detection
language = get_language_from_extension('file.ts') # Returns 'typescript'
language = get_language_from_extension('file.py') # Returns 'python'
language = get_language_from_extension('file.rs') # Returns 'rust'The unified interface provides:
Automatic Language Detection: No need to manually specify Python vs TypeScript
Factory Pattern: create_extractor() returns appropriate extractor for file type
Consistent API: Same functions work for both languages
Clean Abstraction: Hides complexity of modular structure underneath
The tool is structured into four main components, designed for clarity and maintainability:
Unified Interface (core/__init__.py)
Provides a single API for both Python and TypeScript codebases.
Factory functions for automatic language detection and extractor creation.
Simplifies usage by hiding complexity of modular structure.
AST Extractor (core/ast_extractor.py)
Parses source code into Abstract Syntax Trees.
Extracts rich metadata for FunctionElement and ClassElement objects (complexity, decorators, dependencies, etc.).
Filters files based on .gitignore for relevant analysis.
Call Graph Builder (core/call_graph_builder.py)
Constructs a directed graph of function calls based on extracted AST data.
Identifies application entry points using multiple heuristics.
Provides structured FunctionNode and CallEdge objects, containing the rich metadata.
Vector Store (core/vector_store.py)
Integrates with ChromaDB for a persistent, queryable knowledge base.
Stores semantic embeddings of functions and edges, along with their detailed metadata.
Enables semantic search (query_functions) and efficient updates via source code hashing.
Server (mcp_server/server.py): MCP SDK-based server handling MCP protocol and tool registration.
Analyzer (mcp_server/analyzer.py): Core analysis logic with file watching for incremental updates.
Tools (mcp_server/tools.py): MCP tool implementations with request/response models.
Configuration (mcp_server/config/): YAML-based configuration management.
CodeGraphAnalyzer (cli/code_flow.py): Main orchestrator for analysis pipeline.
Command-line argument parsing and output formatting.
Integration with core components for analysis and querying.
We welcome contributions! Please refer to the Contributing Guide (or similar if you create one) for details on how to get involved.
This project is licensed under the MIT License - see the LICENSE file for details.
Enhanced TypeScript parsing and feature parity with Python.
Advanced data flow analysis (beyond simple local variables).
Integration with other visualization tools (e.g., Graphviz).
More sophisticated entry point detection for various frameworks.
Direct IDE integrations for real-time analysis and navigation.
Support for other programming languages.
Web-based UI for interactive code exploration.
Plugin system for custom analysis rules.
✅ Unified Interface Module: Single API for automatic Python and TypeScript detection and analysis
✅ Factory Functions: create_extractor() and get_language_from_extension() for simplified usage
✅ Unified Interface Module: Single API for automatic Python and TypeScript detection and analysis
✅ Factory Functions: create_extractor() and get_language_from_extension() for simplified usage
✅ Backward Compatibility: Existing code continues to work with new modular structure
✅ Structured Data Indexing: Support for JSON and YAML configuration files with semantic search
This project is built upon the excellent work of:
Mermaid.js for diagramming.
MCP SDK for MCP server framework.
Watchdog for file monitoring.
Run drift detection on the current analyzed codebase.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| report | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only states 'Run drift detection' without disclosing whether it is destructive, requires state, or has side effects.
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, front-loaded sentence with no wasted words. Every word contributes to understanding 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 simplicity (no parameters, output schema exists), the description is adequate but not thorough. It lacks context about what 'drift detection' entails or what the output contains, though the output schema may compensate.
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 tool has zero parameters, and schema description coverage is 100%. Baseline is 4; the description adds value by stating the tool's purpose, which is sufficient given no parameters.
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 'Run drift detection' and specifies the target 'current analyzed codebase.' It effectively distinguishes from siblings like 'cleanup_stale_references' or 'get_function_metadata,' as none directly relate to drift detection.
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?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage must be inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger cleanup of stale file references in the vector store. Removes documents that reference files that no longer exist on the filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| message | Yes | |
| stale_paths | Yes | |
| removed_documents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description correctly indicates that the tool removes documents referencing nonexistent files. However, it lacks details on return values, side effects, or whether the operation is reversible.
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 consists of two short, efficient sentences with no wasted words, making it easy to parse.
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 simplicity (no parameters, output schema exists), the description is largely complete. It explains the trigger condition and effect. Minor gap: no mention of what happens after cleanup (e.g., confirmation or count).
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 tool has zero parameters and schema coverage is 100% (empty schema), so no parameter explanation is needed. The baseline of 4 is appropriate.
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 verb 'trigger cleanup' and specifies the resource 'stale file references in the vector store', distinguishing it from sibling tools like 'check_drift' or 'forget_memory' 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleaning stale references but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| knowledge_id | Yes | Memory ID to delete |
| Name | Required | Description |
|---|---|---|
| record | No | |
| success | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Mermaid diagram for the call graph.
| Name | Required | Description | Default |
|---|---|---|---|
| fqns | No | List of fully qualified names to highlight in the graph | |
| llm_optimized | Yes | Whether to optimize the graph for LLM consumption |
| Name | Required | Description |
|---|---|---|
| graph | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states the action without mentioning idempotency, permissions, side effects, or whether it is read-only.
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?
Extremely concise single sentence with no waste. However, it could incorporate more useful information without becoming verbose.
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 simple tool with output schema, description is adequate but lacks context on when to use compared to siblings and any behavioral notes.
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 coverage is 100%, so schema already documents parameters. Description adds no extra meaning beyond the schema, hence baseline 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?
Description clearly states it generates a Mermaid diagram for the call graph, specifying both the output format (Mermaid) and the resource (call graph). This distinguishes it from sibling like 'get_call_graph' which likely returns raw data.
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 on when to use this tool versus alternatives such as 'get_call_graph' or 'impact_analysis'. It does not mention prerequisites or contexts where Mermaid output is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the call graph in specified format.
| Name | Required | Description | Default |
|---|---|---|---|
| fqns | No | List of fully qualified names to include in the graph | |
| depth | No | Depth of the call graph to export | |
| format | No | Output format, either 'json' or 'mermaid' | json |
| Name | Required | Description |
|---|---|---|
| graph | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the tool 'exports', implying a read-only operation, but fails to disclose potential limitations, performance impacts, or any side effects. The minimal description adds little beyond the tool name.
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 sentence with no wasted words, but it is arguably too brief, lacking essential detail. It is concise but at the expense of completeness, scoring a middle ground.
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?
Although an output schema exists (reducing the need to describe return values), the description fails to clarify the overall context: what is a call graph, how does it relate to the system, or what are the prerequisites for using this tool. With three parameters and zero required, the description should at least hint at typical usage scenarios.
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?
All three parameters have descriptions in the schema (100% coverage), so the description does not need to add details. The description's mention of 'specified format' loosely aligns with the format parameter but provides no new semantic value. Baseline 3 is appropriate as the schema already explains the parameters.
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 states it exports a call graph in a specified format, which is a clear verb+resource. However, it does not distinguish from the sibling tool 'generate_mermaid_graph', which likely produces a similar output, causing potential ambiguity. The schema adds clarity but the description alone is vague.
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 on when to use this tool versus alternatives like 'generate_mermaid_graph'. There is no mention of preconditions, scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata for a specific function by its fully qualified name.
Args: fqn: The fully qualified name of the function to retrieve metadata for. Returns: MetadataResponse containing detailed function metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| fqn | Yes | Fully qualified name of the function |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| nloc | Yes | |
| summary | Yes | |
| is_async | Yes | |
| line_end | Yes | |
| docstring | Yes | |
| file_path | Yes | |
| hash_body | Yes | |
| is_method | Yes | |
| is_static | Yes | |
| class_name | Yes | |
| complexity | Yes | |
| decorators | Yes | |
| line_start | Yes | |
| parameters | Yes | |
| is_exported | Yes | |
| return_type | Yes | |
| incoming_edges | Yes | |
| is_entry_point | Yes | |
| outgoing_edges | Yes | |
| access_modifier | Yes | |
| analysis_status | No | |
| catches_exceptions | Yes | |
| fully_qualified_name | Yes | |
| external_dependencies | Yes | |
| local_variables_declared | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read-only operation but gives no details on permissions or side effects. Adequate for a simple retrieval tool.
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?
Two sentences plus structured Args/Returns. No redundant information, efficient.
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 low complexity (1 param, output schema exists), the description is sufficient. No missing critical information.
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 coverage is 100%, and description repeats the parameter's meaning. No additional semantic detail beyond the schema.
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?
Description clearly states 'Retrieve metadata for a specific function' with verb and resource. It does not explicitly differentiate from siblings, but the purpose is clear.
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 on when to use this tool vs alternatives. No context about filtering, searching, or listing functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Call graph traversal depth | |
| direction | No | Traversal direction: up|down|both | both |
| changed_files | No | Changed file paths | |
| include_paths | No | Include call paths in response |
| Name | Required | Description |
|---|---|---|
| paths | No | |
| inputs | Yes | |
| summary | Yes | |
| impacted_nodes | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items | |
| offset | No | Offset for pagination | |
| filters | No | Optional filters |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simple ping tool to echo a message and report analysis status.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to echo |
| Name | Required | Description |
|---|---|---|
| echoed | Yes | |
| status | Yes | |
| analysis_status | No | |
| indexed_functions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only hints at 'report analysis status' without detailing behavior, side effects, or output. For a ping tool, more context on what 'analysis status' means would help.
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?
Single sentence is concise and front-loaded, but could be slightly more structured to mention output. Still efficient.
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?
Tool is simple with one param and output schema exists (but not shown). Description missing explanation of what 'analysis status' entails, which could be important for usage.
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?
Parameter 'message' already well-described in schema ('Message to echo'). Description adds no new meaning beyond schema, so baseline 3 is appropriate.
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 echoes a message and reports analysis status, which is a specific verb+resource. It distinguishes from unrelated siblings.
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 explicit guidance on when to use or alternatives, but the simplicity and distinct purpose make it adequate. Sibling tools are all different, so minimal confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve identified entry points in the codebase with optional pagination and detail level.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entry points to return | |
| offset | No | Offset for pagination | |
| include_details | No | Include full function metadata (edges, decorators, etc.) |
| Name | Required | Description |
|---|---|---|
| limit | No | |
| total | No | |
| offset | No | |
| entry_points | Yes | |
| analysis_status | No | |
| include_details | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose traits like read-only nature, performance implications, or how entry points are identified. The description adds minimal behavioral context beyond parameter descriptions.
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 sentence that is concise and front-loaded. It avoids unnecessary words, though it could benefit from slightly more context without becoming verbose.
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 simplicity of the tool and the presence of an output schema, the description is adequate but incomplete. It does not explain what 'entry points' are or any prerequisites, leaving the agent to infer from the tool name.
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 coverage is 100%, so the schema fully documents parameters. The description reiterates pagination and detail level but adds no new meaning beyond what the schema already provides.
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 retrieves entry points with pagination and detail level. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like get_function_metadata.
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 implies usage for retrieving entry points with optional parameters, but provides no guidance on when to use this tool versus alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| filters | No | Optional filters | |
| n_results | No | Number of results to return |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for filtering | |
| scope | No | repo | project | file | repo |
| source | No | user | system | tool | user |
| content | Yes | Memory content to store or reinforce | |
| metadata | No | Additional metadata | |
| file_paths | No | Related files | |
| memory_type | No | TRIBAL | EPISODIC | FACT | FACT |
| knowledge_id | No | Existing memory id to reinforce | |
| base_confidence | No | Initial confidence |
| Name | Required | Description |
|---|---|---|
| record | No | |
| success | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform semantic search in codebase using vector similarity.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| format | No | Output format: 'markdown' or 'json' | markdown |
| filters | No | Optional filters to apply to the search results | |
| n_results | No | Number of results to return |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| analysis_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the high-level function without disclosing behaviors like rate limits, authentication needs, or what happens with empty results. Basic transparency is lacking.
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 (7 words) with no redundancy. It is concise, though perhaps too brief for full clarity.
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?
Despite having 4 parameters, nested objects, and an output schema, the description is very minimal. It does not explain what 'semantic search' entails, how filters work, or what the output contains. More context is needed.
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 schema has 100% description coverage, so the description adds no value beyond what the schema already provides. Baseline 3 is appropriate.
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 'semantic search' in a 'codebase' using 'vector similarity', which is a specific verb+resource. It distinguishes it from sibling tools like check_drift or get_call_graph.
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 on when to use this tool vs alternatives (e.g., get_function_metadata), nor any exclusions or prerequisites. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Several tools have overlapping purposes (e.g., get_call_graph vs. generate_mermaid_graph, and multiple memory tools with no descriptions), making it harder for an agent to distinguish them without additional context.
Most tools follow a consistent verb_noun pattern with underscore separators, but a few (e.g., semantic_search, impact_analysis) deviate slightly, preventing a perfect score.
With 13 tools, the set is reasonably scoped for a code analysis server, neither too sparse nor too heavy, though some tools may be redundant.
Missing descriptions for several tools (e.g., forget_memory, impact_analysis) and apparent gaps like no tool for listing functions or retrieving source code suggest the surface is incomplete for comprehensive code analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrorigo/code-flow-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
