git-project-xray-mcp
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., "@git-project-xray-mcpAnalyze the UserService class and show me what would break if I change the authenticate method."
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.
XRAY MCP - Progressive Code Intelligence for AI Assistants
❌ Without XRAY
AI assistants struggle with codebase understanding. You get:
❌ "I can't see your code structure"
❌ "I don't know what depends on this function"
❌ Generic refactoring advice without impact analysis
❌ No understanding of symbol relationships
Related MCP server: ast-grep MCP Server
✅ With XRAY
XRAY gives AI assistants code navigation capabilities. Add use XRAY tools to your prompt:
Analyze the UserService class and show me what would break if I change the authenticate method. use XRAY toolsFind all functions that call validate_user and show their dependencies. use XRAY toolsXRAY provides three focused tools:
🗺️ Map (
explore_repo) - See project structure with symbol skeletons🔍 Find (
find_symbol) - Locate functions and classes with fuzzy search💥 Impact (
what_breaks) - Find where a symbol is referenced
🚀 Quick Install
Install from PyPI (Easiest)
# Install directly from PyPI with pip
pip install git-project-xray-mcp
# Or with uv (faster)
uv pip install git-project-xray-mcp
# Then run
git-project-xray-mcpInstall with uv Tool (Recommended for MCP)
# Install uv if you don't have it
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install as a uv tool
uv tool install git-project-xray-mcp
# Then run from anywhere
git-project-xray-mcpAutomated Install with uv
For the quickest setup, this script automates the uv installation process.
curl -fsSL https://raw.githubusercontent.com/Jamie-BitFlight/git-project-xray-mcp/main/install.sh | bashInstall from Source (Development)
git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd xray
uv tool install .Generate Config
# Get config for your tool
uv run python mcp-config-generator.py cursor local_python
uv run python mcp-config-generator.py claude docker
uv run python mcp-config-generator.py vscode sourceLanguage Support
XRAY uses ast-grep, a tree-sitter powered structural search tool, providing accurate parsing for:
Python - Functions, classes, methods, async functions
JavaScript - Functions, classes, arrow functions, imports
TypeScript - All JavaScript features plus interfaces, type aliases
Go - Functions, structs, interfaces, methods
ast-grep ensures structural accuracy - it understands code syntax, not just text patterns.
The XRAY Workflow - Progressive Discovery
1. Map - Start Simple, Then Zoom In
# First: Get the big picture (directories only)
tree = explore_repo("/path/to/project")
# Returns:
# /path/to/project/
# ├── src/
# ├── tests/
# ├── docs/
# └── config/
# Then: Zoom into areas of interest with full details
tree = explore_repo("/path/to/project", focus_dirs=["src"], include_symbols=True)
# Returns:
# /path/to/project/
# └── src/
# ├── auth.py
# │ ├── class AuthService: # Handles user authentication
# │ ├── def authenticate(username, password): # Validates user credentials
# │ └── def logout(session_id): # Ends user session
# └── models.py
# ├── class User(BaseModel): # User account model
# └── ... and 3 more
# Or: Limit depth for large codebases
tree = explore_repo("/path/to/project", max_depth=2, include_symbols=True)2. Find - Locate Specific Symbols
# Find symbols matching "authenticate" (fuzzy search)
symbols = find_symbol("/path/to/project", "authenticate")
# Returns list of exact symbol objects with name, type, path, line numbers3. Impact - See What Would Break
# Find where authenticate_user is used
symbol = symbols[0] # From find_symbol
result = what_breaks(symbol)
# Returns: {"references": [...], "total_count": 12,
# "note": "Found 12 potential references based on text search..."}Architecture
FastMCP Server (mcp_server.py)
↓
Core Engine (src/xray/core/)
└── indexer.py # Orchestrates ast-grep for structural analysis
↓
ast-grep (external binary)
└── Tree-sitter powered structural searchStateless design - No database, no persistent index. Each operation runs fresh ast-grep queries for real-time accuracy.
Why ast-grep?
Traditional grep searches text. ast-grep searches code structure:
grep: Finds "authenticate" in function names, variables, comments, strings
ast-grep: Finds only
def authenticate()orfunction authenticate()definitions
This structural approach provides clean, accurate results essential for reliable code intelligence.
Performance Characteristics
Startup: Fast - launches ast-grep subprocess
File tree: Python directory traversal
Symbol search: Runs multiple ast-grep patterns, speed depends on codebase size
Impact analysis: Name-based search across all files
Memory: Minimal - no persistent state
What Makes This Practical
Progressive Discovery - Start with directories, add symbols only where needed
Smart Caching - Symbol extraction cached per git commit for instant re-runs
Flexible Focus - Use
focus_dirsto zoom into specific parts of large codebasesEnhanced Symbols - See function signatures and docstrings, not just names
Based on tree-sitter - ast-grep provides accurate structural analysis
XRAY helps AI assistants avoid information overload while providing deep code intelligence where needed.
Stateless Design
XRAY performs on-demand structural analysis using ast-grep. There's no database to manage, no index to build, and no state to maintain. Each query runs fresh against your current code.
Getting Started
Install: See
getting_started.mdfor modern installationMap the terrain:
explore_repo("/path/to/project")Find your target:
find_symbol("/path/to/project", "UserService")Assess impact:
what_breaks(symbol)
The XRAY Philosophy
XRAY bridges the gap between simple text search and complex LSP servers:
More than grep - Matches code syntax patterns, not just text
Less than LSP - No language servers or complex setup
Practical for AI - Provides structured data about code relationships
A simple tool that helps AI assistants navigate codebases more effectively than text search alone.
Architectural Journey & Design Rationale
The current implementation of XRAY is the result of a rigorous evaluation of multiple code analysis methodologies. My journey involved prototyping and assessing several distinct approaches, each with its own set of trade-offs. Below is a summary of the considered architectures and the rationale for my final decision.
Naive Grep-Based Analysis: I initially explored a baseline approach using standard
grepfor symbol identification. While expedient, this method proved fundamentally inadequate due to its inability to differentiate between syntactical constructs and simple text occurrences (e.g., comments, strings, variable names). The high signal-to-noise ratio rendered it impractical for reliable code intelligence.Tree-Sitter Native Integration: A direct integration with
tree-sitterwas evaluated to leverage its powerful parsing capabilities. However, this path was fraught with significant implementation complexities, including intractable errors within the parser generation and binding layers. The maintenance overhead and steep learning curve for custom grammar development were deemed prohibitive for a lean, multi-language tool.Language Server Protocol (LSP): I considered leveraging the Language Server Protocol for its comprehensive, standardized approach to code analysis. This was ultimately rejected due to the excessive operational burden it would impose on the end-user, requiring them to install, configure, and manage separate LSPs for each language in their environment. This friction conflicted with my goal of a lightweight, zero-configuration user experience.
Comby-Based Structural Search:
Combywas explored for its structural search and replacement capabilities. Despite its promising feature set, I encountered significant runtime instability and idiosyncratic behavior that undermined its reliability for mission-critical code analysis. The tool's performance and consistency did not meet my stringent requirements for a production-ready system.ast-grep as the Core Engine: My final and current architecture is centered on
ast-grep. This tool provides the optimal balance of structural awareness, performance, and ease of integration. By leveragingtree-sitterinternally, it offers robust, syntactically-aware code analysis without the complexities of directtree-sitterintegration or the overhead of LSPs. Its reliability and rich feature set for structural querying made it the unequivocal choice for XRAY's core engine.
Getting Started with XRAY - Modern Installation with uv
XRAY is a minimal-dependency code intelligence system that enhances AI assistants' understanding of codebases. This guide shows how to install and use XRAY with the modern uv package manager.
Prerequisites
Python 3.10 or later
uv - Fast Python package manager
Installing uv
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
# Or with pip
pip install uvInstallation Options
Option 1: Automated Install (Easiest)
For the quickest setup, use the one-line installer from the README.md. This will handle everything for you.
curl -fsSL https://raw.githubusercontent.com/Jamie-BitFlight/git-project-xray-mcp/main/install.sh | bashOption 2: Quick Try with uvx (Recommended for Testing)
Run XRAY directly without installation using uvx:
# Clone the repository
git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd xray
# Run XRAY directly with uvx
uvx --from . git-project-xray-mcpOption 3: Install as a Tool (Recommended for Regular Use)
Install XRAY as a persistent tool:
# Clone and install
git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd xray
# Install with uv
uv tool install .
# Now you can run git-project-xray-mcp from anywhere
git-project-xray-mcpOption 4: Development Installation
For contributing or modifying XRAY:
# Clone the repository
git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd xray
# Create and activate virtual environment with uv
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install in editable mode
uv pip install -e .
# Run the server
python -m xray.mcp_serverConfigure Your AI Assistant
After installation, configure your AI assistant to use XRAY:
Using the MCP Config Generator (Recommended)
For easier configuration, use the mcp-config-generator.py script located in the XRAY repository. This script can generate the correct JSON configuration for various AI assistants and installation methods.
To use it:
Navigate to the XRAY repository root:
cd /path/to/xrayRun the script with your desired tool and installation method. For example, to get the configuration for Claude Desktop with an installed
git-project-xray-mcpscript:python mcp-config-generator.py claude installed_scriptOr for VS Code with a local Python installation:
python mcp-config-generator.py vscode local_pythonThe script will print the JSON configuration and instructions on where to add it.
Available tools:
cursor,claude,vscodeAvailable methods:local_python,docker,source,installed_script(method availability varies by tool)
Manual Configuration (Advanced)
If you prefer to configure manually, here are examples for common AI assistants:
Claude CLI (Claude Code)
For Claude CLI users, simply run:
claude mcp add xray git-project-xray-mcp -s localThen verify it's connected:
claude mcp list | grep xrayClaude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"xray": {
"command": "uvx",
"args": ["--from", "/path/to/xray", "git-project-xray-mcp"]
}
}
}Or if installed as a tool:
{
"mcpServers": {
"xray": {
"command": "git-project-xray-mcp"
}
}
}Cursor
Settings → Cursor Settings → MCP → Add new global MCP server:
{
"mcpServers": {
"xray": {
"command": "git-project-xray-mcp"
}
}
}Minimal Dependencies
One of XRAY's best features is its minimal dependency profile. You don't need to install a suite of language servers. XRAY uses:
ast-grep: A single, fast binary for structural code analysis.
Python: For the server and core logic.
This means you can start using XRAY immediately after installation with no complex setup!
Verify Installation
1. Check XRAY is accessible
# If installed as tool
git-project-xray-mcp --version
# If using uvx
uvx --from /path/to/xray git-project-xray-mcp --version2. Test basic functionality
Create a test file test_xray.py:
def hello_world():
print("Hello from XRAY test!")
def calculate_sum(a, b):
return a + b
class Calculator:
def multiply(self, x, y):
return x * y3. In your AI assistant, test these commands:
Build the index for the current directory. use XRAY toolsExpected: Success message with files indexed
Find all functions containing "hello". use XRAY toolsExpected: Should find hello_world function
What would break if I change the multiply method? use XRAY toolsExpected: Impact analysis showing any dependencies
Usage Examples
Once configured, use XRAY by adding "use XRAY tools" to your prompts:
# Index a codebase
"Index the src/ directory for analysis. use XRAY tools"
# Find symbols
"Find all classes that contain 'User' in their name. use XRAY tools"
# Impact analysis
"What breaks if I change the authenticate method in UserService? use XRAY tools"
# Dependency tracking
"What does the PaymentProcessor class depend on? use XRAY tools"
# Location queries
"What function is defined at line 125 in main.py? use XRAY tools"Troubleshooting
uv not found
Make sure uv is in your PATH:
# Add to ~/.bashrc or ~/.zshrc
export PATH="$HOME/.cargo/bin:$PATH"Permission denied
On macOS/Linux, you might need to make the script executable:
chmod +x ~/.local/bin/git-project-xray-mcpPython version issues
XRAY requires Python 3.10+. Check your version:
python --version
# If needed, install Python 3.10+ with uv
uv python install 3.10MCP connection issues
Check XRAY is running:
git-project-xray-mcp --testVerify your MCP config JSON is valid
Restart your AI assistant after config changes
Advanced Configuration
Custom Database Location
Set the XRAY_DB_PATH environment variable:
export XRAY_DB_PATH="$HOME/.xray/databases"Debug Mode
Enable debug logging:
export XRAY_DEBUG=1What's Next?
Index your first repository: In your AI assistant, ask it to "Build the index for my project. use XRAY tools"
Explore the tools:
build_index- Visual file tree of your repositoryfind_symbol- Fuzzy search for functions, classes, and methodswhat_breaks- Find what code depends on a symbol (reverse dependencies)what_depends- Find what a symbol depends on (calls and imports)
Note: Results may include matches from comments or strings. The AI assistant will intelligently filter based on context.
Read the documentation: Check out the README for detailed examples and API reference
Development
Setting Up Development Environment
Clone the repository:
git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd git-project-xray-mcpInstall development dependencies:
uv syncThis installs XRAY in editable mode along with:
ruff- Fast linter and formatter (replaces flake8, black, isort)mypy- Static type checkerpytest- Testing frameworkpytest-cov- Code coverage plugin
Running Tests
# Run all tests
uv run pytest tests/
# Run with coverage
uv run pytest tests/ --cov=xray --cov-report=term-missing
# Run specific test file
uv run pytest tests/test_indexer.py -vCode Quality
Linting:
# Check code with ruff
uv run ruff check src/ tests/
# Auto-fix issues
uv run ruff check --fix src/ tests/Formatting:
# Check formatting
uv run ruff format --check src/ tests/
# Format code
uv run ruff format src/ tests/Type Checking:
# Run mypy type checker
uv run mypy src/Continuous Integration
The project uses GitHub Actions for CI/CD:
Linting: Runs ruff to check code style
Formatting: Verifies code is properly formatted
Type Checking: Runs mypy for static type analysis
Testing: Executes pytest across Python 3.10, 3.11, 3.12
Coverage: Uploads coverage reports to Codecov
CI runs automatically on:
Push to
mainordevelopbranchesPull requests to
mainordevelopbranches
Project Structure
git-project-xray-mcp/
├── src/xray/ # Main source code
│ ├── mcp_server.py # FastMCP server and tool definitions
│ └── core/
│ └── indexer.py # Core indexing engine
├── tests/ # Test suite
│ ├── test_indexer.py # Tests for indexer
│ └── test_mcp_server.py # Tests for MCP server
├── .github/workflows/ # GitHub Actions CI
│ └── ci.yml # Linting and testing workflow
└── pyproject.toml # Project configurationWhy XRAY Uses a Minimal Dependency Approach
XRAY is designed for simplicity and ease of use. It relies on:
ast-grep: A powerful and fast single-binary tool for code analysis.
Python: For its robust standard library and ease of scripting.
This approach avoids the complexity of setting up and managing multiple language servers, while still providing accurate, structural code intelligence.
Benefits of Using uv
10-100x faster than pip for installations
No virtual environment hassles - uv manages everything
Reproducible installs - uv.lock ensures consistency
Built-in Python management - install any Python version
Global tool management - like pipx but faster
Happy coding with XRAY! 🚀
Available Tools
3 toolsexplore_repoA
🗺️ STEP 1: Map the codebase structure - start simple, then zoom in!
PROGRESSIVE DISCOVERY WORKFLOW:
First call: explore_repo("/path/to/project") - See directory structure only
Zoom in: explore_repo("/path/to/project", focus_dirs=["src"], include_symbols=True)
Go deeper: explore_repo("/path/to/project", max_depth=3, include_symbols=True)
INPUTS:
root_path: The ABSOLUTE path to the project (e.g., "/Users/john/myproject") NOT relative paths like "./myproject" or "~/myproject"
max_depth: How deep to traverse directories (None = unlimited, accepts int or string)
include_symbols: Show function/class signatures with docs (False = dirs only, accepts bool or string)
focus_dirs: List of top-level directories to focus on (e.g., ["src", "lib"])
max_symbols_per_file: Max symbols to show per file when include_symbols=True (accepts int or string)
EXAMPLE 1 - Initial exploration (directory only): explore_repo("/Users/john/project")
Returns:
/Users/john/project/
├── src/
├── tests/
├── docs/
└── README.md
EXAMPLE 2 - Zoom into src/ with symbols: explore_repo("/Users/john/project", focus_dirs=["src"], include_symbols=True)
Returns:
/Users/john/project/
└── src/
├── auth.py
│ ├── class AuthService: # Handles user authentication
│ ├── def authenticate(username, password): # Validates credentials
│ └── def logout(session_id): # Ends user session
└── models.py
├── class User(BaseModel): # User account model
└── ... and 3 more
EXAMPLE 3 - Limited depth exploration: explore_repo("/Users/john/project", max_depth=1, include_symbols=True)
Shows only top-level dirs and files with their symbols
💡 PRO TIP: Start with include_symbols=False to see structure, then set it to True for areas you want to examine in detail. This prevents information overload!
⚡ PERFORMANCE: Symbol extraction is cached per git commit - subsequent calls are instant!
WHAT TO DO NEXT:
If you found interesting directories, zoom in with focus_dirs
If you see relevant files, use find_symbol() to locate specific functions
| Name | Required | Description | Default |
|---|---|---|---|
| root_path | Yes | ||
| max_depth | No | ||
| include_symbols | No | ||
| focus_dirs | No | ||
| max_symbols_per_file | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: shows directory structure and optionally symbols, performance caching per git commit, accepts flexible types (int or string for several params), and provides detailed examples of output format. No destructive actions are implied, and it clarifies expected inputs like absolute root_path.
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 long but well-organized with emojis, numbered workflow, examples, and pro tips. Every section adds value; however, some redundancy (e.g., repeated parameter types) could be trimmed. It is front-loaded with the main purpose and workflow, making it easy to grasp 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 5 parameters, no annotations, and an output schema, the description covers all necessary input details and workflow guidance. The examples effectively illustrate expected output, and the output schema likely provides additional structure. The description addresses the complexity of progressive exploration thoroughly.
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 0%, but the description richly explains each parameter: root_path (absolute path requirement), max_depth (how deep, unlimited by default, accepts int/string), include_symbols (shows signatures, accepts bool/string), focus_dirs (top-level directories), and max_symbols_per_file (limit when symbols included). Examples demonstrate usage.
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 maps a codebase structure starting simple then zooming in. It specifies 'explore_repo' as distinct from sibling tools 'find_symbol' and 'what_breaks' by focusing on directory and symbol overview rather than locating specific functions or analyzing breaks.
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 a clear progressive discovery workflow (step 1-3), explicit when to use include_symbols, and advice on avoiding information overload. It also tells what to do next after exploring, giving contextual guidance on using focus_dirs or find_symbol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_symbolA
🔍 STEP 2: Find specific functions, classes, or methods in the codebase.
USE THIS AFTER explore_repo() when you need to locate a specific piece of code. Uses fuzzy matching - you don't need the exact name!
INPUTS:
root_path: Same ABSOLUTE path used in explore_repo
query: What you're looking for (fuzzy search works!) Examples: "auth", "user service", "validate", "parseJSON"
EXAMPLE INPUTS: find_symbol("/Users/john/awesome-project", "authenticate") find_symbol("/Users/john/awesome-project", "user model") # Fuzzy matches "UserModel"
EXAMPLE OUTPUT: [ { "name": "authenticate_user", "type": "function", "path": "/Users/john/awesome-project/src/auth.py", "start_line": 45, "end_line": 67 }, { "name": "AuthService", "type": "class", "path": "/Users/john/awesome-project/src/services.py", "start_line": 12, "end_line": 89 } ]
RETURNS: List of symbol objects (dictionaries). Save these objects - you'll pass them to what_breaks()! Empty list if no matches found.
WHAT TO DO NEXT: Pick a symbol from the results and pass THE ENTIRE SYMBOL OBJECT to what_breaks() to see where it's used in the codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| root_path | Yes | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: uses fuzzy matching, returns a list of symbol objects with exact fields, empty list if no matches, and how to proceed with the output. No annotations exist, so the description carries the full burden well.
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 well-structured with clear sections (STEP, INPUTS, EXAMPLES, RETURNS, NEXT) and front-loaded with purpose. It is somewhat verbose but every sentence adds value, though could be slightly more concise.
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 only 2 parameters and an output schema, the description is very complete. It explains the return format via example, the usage flow, and links to sibling tools, leaving no ambiguity.
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?
With 0% schema description coverage, the description adds critical meaning: root_path must be the same absolute path from explore_repo, query examples are given. This compensates for the schema's lack of descriptions.
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: finding specific functions, classes, or methods in the codebase. It specifies the verb 'find' and the resource 'symbols', and distinguishes from siblings like explore_repo and what_breaks.
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 explicit when-to-use guidance: 'USE THIS AFTER explore_repo()' and 'Pick a symbol from the results and pass... to what_breaks()'. It also mentions fuzzy matching and gives practical examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
what_breaksA
💥 STEP 3: See what code might break if you change this symbol.
USE THIS AFTER find_symbol() to understand the impact of changing a function/class. Shows you every place in the codebase where this symbol name appears.
INPUT:
exact_symbol: Pass THE ENTIRE SYMBOL OBJECT from find_symbol(), not just the name! Must be a dictionary with AT LEAST 'name' and 'path' keys.
EXAMPLE INPUT:
First, get a symbol from find_symbol():
symbols = find_symbol("/Users/john/project", "authenticate") symbol = symbols[0] # Pick the first result
Then pass THE WHOLE SYMBOL OBJECT:
what_breaks(symbol)
or directly:
what_breaks({ "name": "authenticate_user", "type": "function", "path": "/Users/john/project/src/auth.py", "start_line": 45, "end_line": 67 })
EXAMPLE OUTPUT: { "references": [ { "file": "/Users/john/project/src/api.py", "line": 23, "text": " user = authenticate_user(username, password)" }, { "file": "/Users/john/project/tests/test_auth.py", "line": 45, "text": "def test_authenticate_user():" } ], "total_count": 2, "note": "Found 2 potential references based on a text search for the name 'authenticate_user'. This may include comments, strings, or other unrelated symbols." }
⚠️ IMPORTANT: This does a text search for the name, so it might find:
Actual function calls (what you want!)
Comments mentioning the function
Other functions/variables with the same name
Strings containing the name
Review each reference to determine if it's actually affected.
| Name | Required | Description | Default |
|---|---|---|---|
| exact_symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavioral traits: it performs a text search for the name, lists potential false positives (comments, same names, strings), and notes it is not a dependency analysis. The 'IMPORTANT' section clearly warns about limitations.
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?
Description is structured with clear sections (INPUT, EXAMPLE INPUT, EXAMPLE OUTPUT, IMPORTANT) and front-loaded with purpose. While thorough, it is somewhat verbose (approx. 300 words) and could be slightly trimmed without losing 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?
Covers purpose, usage flow, input format, output structure with real example, and limitations. Despite lack of annotations and formal output schema, the example output and notes make the tool's behavior fully understandable for an agent.
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 0% (only provides type: object with additionalProperties). Description compensates fully by specifying that the object must have at least 'name' and 'path' keys, and provides a concrete example with all relevant fields. This adds significant meaning 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 starts with 'See what code might break if you change this symbol' and explicitly states it shows every place the symbol name appears. Clearly distinguishes from siblings find_symbol (which finds symbols) and explore_repo.
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?
Directly instructs 'USE THIS AFTER find_symbol()' and provides step context 'STEP 3'. Includes detailed example of chaining with find_symbol and explicit input requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
explore_repo - First observed
find_symbol - First observed
what_breaks
TDQS
Each tool has a distinct, non-overlapping purpose: explore_repo for directory structure, find_symbol for locating code symbols, and what_breaks for impact analysis. The workflow is clearly sequenced, so an agent can easily select the right tool for each step.
All tool names follow a consistent verb_noun pattern (explore_repo, find_symbol, what_breaks). The names are descriptive and align with their functions, with 'what_breaks' being a slight phrase but still fitting the pattern.
With only 3 tools, the server is tightly scoped to a progressive discovery workflow. Each tool earns its place, and the count is ideal for the focused purpose of code exploration and impact analysis.
The tools cover the core workflow of exploring structure, finding symbols, and checking references. Missing features like direct file content reading or diff analysis are minor given the stated use case, but they are not critical gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to understand and navigate codebases through structural analysis. Provides code mapping, symbol search, and impact analysis using ast-grep for accurate parsing of Python, JavaScript, TypeScript, and Go projects.452MIT
- AlicenseAqualityCmaintenanceEnables AI assistants to search and analyze codebases using Abstract Syntax Tree (AST) pattern matching with ast-grep. Supports structural code search, pattern testing, and AST visualization across multiple programming languages.4456MIT
- AlicenseNot gradedqualityCmaintenanceProvides a semantic understanding of your codebase by parsing with tree-sitter and building a graph of symbols and dependencies. Enables AI assistants to navigate code, analyze changes, and discover architecture using 18 tools with minimal context overhead.221MIT
- FlicenseNot gradedqualityBmaintenanceProvides efficient code navigation and graph-based analysis for AI agents, enabling symbol resolution, callers, implementations, and type schemas with minimal token usage.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jamie-BitFlight/git-project-xray-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server