Skip to main content
Glama
Jamie-BitFlight

git-project-xray-mcp

XRAY MCP - Progressive Code Intelligence for AI Assistants

Python MCP ast-grep

❌ 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 tools
Find all functions that call validate_user and show their dependencies. use XRAY tools

XRAY 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-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-mcp

Automated 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 | bash

Install 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 source

Language 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 numbers

3. 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 search

Stateless 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() or function 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

  1. Progressive Discovery - Start with directories, add symbols only where needed

  2. Smart Caching - Symbol extraction cached per git commit for instant re-runs

  3. Flexible Focus - Use focus_dirs to zoom into specific parts of large codebases

  4. Enhanced Symbols - See function signatures and docstrings, not just names

  5. 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

  1. Install: See getting_started.md for modern installation

  2. Map the terrain: explore_repo("/path/to/project")

  3. Find your target: find_symbol("/path/to/project", "UserService")

  4. 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.

  1. Naive Grep-Based Analysis: I initially explored a baseline approach using standard grep for 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.

  2. Tree-Sitter Native Integration: A direct integration with tree-sitter was 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.

  3. 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.

  4. Comby-Based Structural Search: Comby was 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.

  5. 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 leveraging tree-sitter internally, it offers robust, syntactically-aware code analysis without the complexities of direct tree-sitter integration 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 uv

Installation 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 | bash

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-mcp

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-mcp

Option 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_server

Configure Your AI Assistant

After installation, configure your AI assistant to use XRAY:

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:

  1. Navigate to the XRAY repository root:

    cd /path/to/xray
  2. Run the script with your desired tool and installation method. For example, to get the configuration for Claude Desktop with an installed git-project-xray-mcp script:

    python mcp-config-generator.py claude installed_script

    Or for VS Code with a local Python installation:

    python mcp-config-generator.py vscode local_python

    The script will print the JSON configuration and instructions on where to add it.

    Available tools: cursor, claude, vscode Available 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 local

Then verify it's connected:

claude mcp list | grep xray

Claude 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 --version

2. 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 * y

3. In your AI assistant, test these commands:

Build the index for the current directory. use XRAY tools

Expected: Success message with files indexed

Find all functions containing "hello". use XRAY tools

Expected: Should find hello_world function

What would break if I change the multiply method? use XRAY tools

Expected: 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-mcp

Python version issues

XRAY requires Python 3.10+. Check your version:

python --version

# If needed, install Python 3.10+ with uv
uv python install 3.10

MCP connection issues

  1. Check XRAY is running: git-project-xray-mcp --test

  2. Verify your MCP config JSON is valid

  3. 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=1

What's Next?

  1. Index your first repository: In your AI assistant, ask it to "Build the index for my project. use XRAY tools"

  2. Explore the tools:

    • build_index - Visual file tree of your repository

    • find_symbol - Fuzzy search for functions, classes, and methods

    • what_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.

  3. Read the documentation: Check out the README for detailed examples and API reference

Development

Setting Up Development Environment

  1. Clone the repository:

git clone https://github.com/Jamie-BitFlight/git-project-xray-mcp.git
cd git-project-xray-mcp
  1. Install development dependencies:

uv sync

This installs XRAY in editable mode along with:

  • ruff - Fast linter and formatter (replaces flake8, black, isort)

  • mypy - Static type checker

  • pytest - Testing framework

  • pytest-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 -v

Code 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 main or develop branches

  • Pull requests to main or develop branches

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 configuration

Why 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 tools
explore_repoA

🗺️ STEP 1: Map the codebase structure - start simple, then zoom in!

PROGRESSIVE DISCOVERY WORKFLOW:

  1. First call: explore_repo("/path/to/project") - See directory structure only

  2. Zoom in: explore_repo("/path/to/project", focus_dirs=["src"], include_symbols=True)

  3. 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

ParametersJSON Schema
NameRequiredDescriptionDefault
root_pathYes
max_depthNo
include_symbolsNo
focus_dirsNo
max_symbols_per_fileNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
root_pathYes
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
exact_symbolYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 3 tool updatesv0.1.0
    • First observedexplore_repo
    • First observedfind_symbol
    • First observedwhat_breaks

TDQS

A4.9/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables 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.
    4
    52
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Enables 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.
    4
    456
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides 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.
    22
    1
    MIT

Latest Blog Posts

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