What can you do with this server?

The code-index-mcp server is a specialized Model Context Protocol (MCP) server for intelligent code indexing, searching, and analysis that enables AI models to interact with code repositories. Core Capabilities: * Project Indexing: Recursively scans directories to build a searchable index of code files, automatically ignoring build directories and non-code files * Search Code: Performs intelligent code searches using automatically detected tools (ripgrep, ag, or grep) with options for case sensitivity, context lines, file patterns, and fuzzy matching * Find Files: Locate files matching specific glob patterns within the project * Analyze Files: Generate detailed insights about file structure, including line counts, functions, imports, and complexity metrics * Manage Index: Refresh the project index or clear cached settings * Persistent Storage: Caches indexes for improved performance across sessions * Broad Language Support: Handles various programming languages, web files, database files, and documentation * Integration: Seamlessly integrates with Claude Desktop for enhanced code navigation and analysis

Which integrations are available for this server?

Provides access to git repositories, allowing users to clone projects for code indexing and analysis.

How do I use code-index-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@code-index-mcp search for authentication middleware in the current project" 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.

en es ja ko zh

code-index-mcp

by johnhuang316

Overview Schema Related Servers Score Discussions

Python

Local

Code Index MCP

MCP Server Python License Sponsor

Intelligent code indexing and analysis for Large Language Models

Transform how AI understands your codebase with advanced search, analysis, and navigation capabilities.

Overview

Code Index MCP is a Model Context Protocol server that bridges the gap between AI models and complex codebases. It provides intelligent indexing, advanced search capabilities, and detailed code analysis to help AI assistants understand and navigate your projects effectively.

Perfect for: Code review, refactoring, documentation generation, debugging assistance, and architectural analysis.

Related MCP server: @lex-tools/codebase-context-dumper

Quick Start

🚀 Recommended Setup (Most Users)

The easiest way to get started with any MCP-compatible application:

Prerequisites: Python 3.10+ and uv

Add to your MCP configuration (e.g., claude_desktop_config.json or ~/.claude.json):
```
{
  "mcpServers": {
    "code-index": {
      "command": "uvx",
      "args": ["code-index-mcp"]
    }
  }
}
```
Optional: append --project-path /absolute/path/to/repo to the args array so the server initializes with that repository automatically (equivalent to calling set_project_path after startup).
Restart your application – uvx automatically handles installation and execution
Start using (give these prompts to your AI assistant):
```
Set the project path to /Users/dev/my-react-app
Find all TypeScript files in this project  
Search for "authentication" functions
Analyze the main App.tsx file
```
If you launch with --project-path, you can skip the first command above - the server already knows the project location.

Codex CLI Configuration

If you are using Anthropic's Codex CLI, add the server to ~/.codex/config.toml. On Windows the file lives at C:\Users\<you>\.codex\config.toml:

[mcp_servers.code-index]
type = "stdio"
command = "uvx"
args = ["code-index-mcp"]

You can append --project-path C:/absolute/path/to/repo to the args list to set the project automatically on startup (same effect as running the set_project_path tool).

On Windows, uvx needs the standard profile directories to be present. Keep the environment override in the same block so the MCP starts reliably:

env = {
  HOME = "C:\\Users\\<you>",
  APPDATA = "C:\\Users\\<you>\\AppData\\Roaming",
  LOCALAPPDATA = "C:\\Users\\<you>\\AppData\\Local",
  SystemRoot = "C:\\Windows"
}

Linux and macOS already expose the required XDG paths and HOME, so you can usually omit the env table there. Add overrides only if you run the CLI inside a restricted container.

FastMCP & Discovery Manifests

Run fastmcp run fastmcp.json to launch the server via FastMCP with the correct source entrypoint and dependency metadata. Pass --project-path (or call the set_project_path tool after startup) so the index boots against the right repository.
Serve or copy .well-known/mcp.json to share a standards-compliant MCP manifest. Clients that support the .well-known convention (e.g., Claude Desktop, Codex CLI) can import this file directly instead of crafting configs manually.
Publish .well-known/mcp.llmfeed.json when you want to expose the richer LLM Feed metadata. It references the same code-index server definition plus documentation/source links, which helps registries present descriptions, tags, and capabilities automatically.

When sharing the manifests, remind consumers to supply --project-path (or to call set_project_path) so the server indexes the intended repository.

Typical Use Cases

Code Review: "Find all places using the old API"
Refactoring Help: "Where is this function called?"
Learning Projects: "Show me the main components of this React project"
Debugging: "Search for all error handling related code"

Key Features

🔍 Intelligent Search & Analysis

Dual-Strategy Architecture: Specialized tree-sitter parsing for 10 core languages, fallback strategy for 50+ file types
Direct Tree-sitter Integration: No regex fallbacks for specialized languages - fail fast with clear errors
Advanced Search: Auto-detects and uses the best available tool (ugrep, ripgrep, ag, or grep)
Universal File Support: Comprehensive coverage from advanced AST parsing to basic file indexing
File Analysis: Deep insights into structure, imports, classes, methods, and complexity metrics after running build_deep_index

🗂️ Multi-Language Support

10 Languages with Tree-sitter AST Parsing: Python, JavaScript, TypeScript, Java, Kotlin, C#, Go, Objective-C, Zig, Rust
50+ File Types with Fallback Strategy: C/C++, Ruby, PHP, and all other programming languages
Document & Config Files: Markdown, JSON, YAML, XML with appropriate handling
Web Frontend: Vue, React, Svelte, HTML, CSS, SCSS
Java Web & Build: JSP/Tag files (.jsp, .jspx, .jspf, .tag, .tagx), Grails/GSP (.gsp), Gradle & Groovy builds (.gradle, .groovy), .properties, and Protocol Buffers (.proto)
Database: SQL variants, NoSQL, stored procedures, migrations
Configuration: JSON, YAML, XML, Markdown
View complete list

⚡ Real-time Monitoring & Auto-refresh

File Watcher: Automatic index updates when files change
Cross-platform: Native OS file system monitoring
Smart Processing: Batches rapid changes to prevent excessive rebuilds
Shallow Index Refresh: Watches file changes and keeps the file list current; run a deep rebuild when you need symbol metadata

⚡ Performance & Efficiency

Tree-sitter AST Parsing: Native syntax parsing for accurate symbol extraction
Persistent Caching: Stores indexes for lightning-fast subsequent access
Smart Filtering: Intelligent exclusion of build directories and temporary files
Memory Efficient: Optimized for large codebases
Direct Dependencies: No fallback mechanisms - fail fast with clear error messages

Supported File Types

Languages with Specialized Tree-sitter Strategies:

Python (.py, .pyw) - Full AST analysis with class/method extraction and call tracking
JavaScript (.js, .jsx, .mjs, .cjs) - ES6+ class and function parsing with tree-sitter
TypeScript (.ts, .tsx) - Complete type-aware symbol extraction with interfaces
Java (.java) - Full class hierarchy, method signatures, and call relationships
Kotlin (.kt, .kts) - Package-aware symbol extraction with methods and call relationships
C# (.cs) - Namespace-aware type/member extraction with call relationships
Go (.go) - Struct methods, receiver types, and function analysis
Rust (.rs) - Functions, module-aware names, impl methods, structs/enums/traits, and basic call relationships
Objective-C (.m, .mm) - Class/instance method distinction with +/- notation
Zig (.zig, .zon) - Function and struct parsing with tree-sitter AST

All Other Programming Languages: All other programming languages use the FallbackParsingStrategy which provides basic file indexing and metadata extraction. This includes:

System & Low-Level: C/C++ (.c, .cpp, .h, .hpp)
Object-Oriented: Scala (.scala), Swift (.swift)
Scripting & Dynamic: Ruby (.rb), PHP (.php), Shell (.sh, .bash)
And 40+ more file types - All handled through the fallback strategy for basic indexing

Frameworks & Libraries:

Vue (.vue)
Svelte (.svelte)
Astro (.astro)

Styling:

CSS (.css, .scss, .less, .sass, .stylus, .styl)
HTML (.html)

Templates:

Handlebars (.hbs, .handlebars)
EJS (.ejs)
Pug (.pug)
FreeMarker (.ftl)
Mustache (.mustache)
Liquid (.liquid)
ERB (.erb)

SQL Variants:

Standard SQL (.sql, .ddl, .dml)
Database-specific (.mysql, .postgresql, .psql, .sqlite, .mssql, .oracle, .ora, .db2)

Database Objects:

Procedures & Functions (.proc, .procedure, .func, .function)
Views & Triggers (.view, .trigger, .index)

Migration & Tools:

Migration files (.migration, .seed, .fixture, .schema)
Tool-specific (.liquibase, .flyway)

NoSQL & Modern:

Graph & Query (.cql, .cypher, .sparql, .gql)

Markdown (.md, .mdx)
Configuration (.json, .xml, .yml, .yaml, .properties)

🛠️ Development Setup

For contributing or local development:

Clone and install:

git clone https://github.com/johnhuang316/code-index-mcp.git
cd code-index-mcp
uv sync

Configure for local development:

{
  "mcpServers": {
    "code-index": {
      "command": "uv",
      "args": ["run", "code-index-mcp"]
    }
  }
}

Debug with MCP Inspector:

npx @modelcontextprotocol/inspector uv run code-index-mcp

If you prefer traditional pip management:

pip install code-index-mcp

Then configure:

{
  "mcpServers": {
    "code-index": {
      "command": "code-index-mcp",
      "args": []
    }
  }
}

Available Tools

🏗️ Project Management

Tool	Description
`set_project_path`	Initialize indexing for a project directory
`refresh_index`	Rebuild the shallow file index after file changes
`build_deep_index`	Generate the full symbol index used by deep analysis
`get_settings_info`	View current project configuration and status

Run build_deep_index when you need symbol-level data; the default shallow index powers quick file discovery.

🔍 Search & Discovery

Tool	Description
`search_code_advanced`	Smart search with literal-by-default matching, optional `regex=True`, fuzzy matching, file filtering, and paginated results (10 per page by default); regex mode requires a native search tool because the basic fallback is literal-only
`find_files`	Locate files using glob patterns (e.g., `*/.py`)
`get_file_summary`	Analyze file structure, functions, imports, and complexity (requires deep index)

🔄 Monitoring & Auto-refresh

Tool	Description
`get_file_watcher_status`	Check file watcher status and configuration
`configure_file_watcher`	Enable/disable auto-refresh and configure settings

🛠️ System & Maintenance

Tool	Description
`create_temp_directory`	Set up storage directory for index data
`check_temp_directory`	Verify index storage location and permissions
`clear_settings`	Reset all cached data and configurations
`refresh_search_tools`	Re-detect available search tools (ugrep, ripgrep, etc.)

Usage Examples

🎯 Quick Start Workflow

1. Initialize Your Project

Set the project path to /Users/dev/my-react-app

Automatically indexes your codebase and creates searchable cache

2. Explore Project Structure

Find all TypeScript component files in src/components

Uses: find_files with pattern src/components/**/*.tsx

3. Analyze Key Files

Give me a summary of src/api/userService.ts

Uses: get_file_summary to show functions, imports, and complexity Tip: run build_deep_index first if you get a needs_deep_index response.

🔍 Advanced Search Examples

Search for all function calls matching "get.*Data" using `regex=True`

Finds: getData(), getUserData(), getFormData(), etc. Regex search is opt-in; install a native search tool and use regex=True because the basic fallback stays literal-only.

Find authentication-related functions with fuzzy search for 'authUser'

Matches: authenticateUser, authUserToken, userAuthCheck, etc.

Search for "API_ENDPOINT" only in Python files

Uses: search_code_advanced with literal matching and file_pattern: "*.py" (defaults to 10 matches; use max_results to expand or start_index to page)

Configure automatic index updates when files change

Uses: configure_file_watcher to enable/disable monitoring and set debounce timing

I added new components, please refresh the project index

Uses: refresh_index to update the searchable cache

Troubleshooting

🔄 Auto-refresh Not Working

If automatic index updates aren't working when files change, try:

pip install watchdog (may resolve environment isolation issues)
Use manual refresh: Call the refresh_index tool after making file changes
Check file watcher status: Use get_file_watcher_status to verify monitoring is active

macOS File Watcher Options

The default FSEvents observer works well for most projects. If you experience issues, you can switch to an alternative observer via configure_file_watcher:

"auto" (default): Platform default (FSEvents on macOS)
"kqueue": Kqueue observer (macOS/BSD)
"fsevents": Force FSEvents (macOS only)
"polling": Cross-platform polling fallback

Note: Kqueue opens one file descriptor per watched file. For large projects using kqueue, you may need to increase the limit: ulimit -n 10240

Development & Contributing

🔧 Building from Source

git clone https://github.com/johnhuang316/code-index-mcp.git
cd code-index-mcp
uv sync
uv run code-index-mcp

🐛 Debugging

npx @modelcontextprotocol/inspector uvx code-index-mcp

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

📜 License

MIT License

🌐 Translations

Available Tools

14 tools

build_deep_indexA

Build the deep index (full symbol extraction) for the current project.

This performs a complete re-index and loads it into memory.
Uses parallel processing by default. For large codebases (3000+ files),
tuning max_workers can significantly improve build times.

Args:
    max_workers: Maximum number of parallel workers for file processing.
        Defaults to min(4, cpu_count) when not specified.
        Increase for I/O-bound workloads on machines with many cores.
    timeout: Parallel build timeout in seconds. When not specified,
        scales dynamically based on file count (0.5s per file,
        min 30s, max 600s).

ParametersJSON Schema

Name	Required	Description	Default
`max_workers`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it performs a complete re-index, loads into memory, uses parallel processing, and has a dynamic timeout. However, it does not mention whether existing indices are overwritten or if the operation is destructive. No annotations are present to supplement this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (3 sentences for main description, 2 bullet for args) and front-loaded. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the main purpose and parameter details well. Lacks mention of side effects like index overwrite or potential performance impact on the system. Output schema exists so return values are not required.

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?

Both parameters are thoroughly explained beyond the schema. For max_workers, it describes default behavior and performance impact. For timeout, it gives the exact dynamic scaling formula. This compensates for the 0% schema description coverage.

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 action ('Build the deep index (full symbol extraction)'), the resource ('current project'), and implies it's a full re-index. This distinguishes it from sibling tools like 'refresh_index' which likely updates an existing index.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides tuning guidance for large codebases but does not specify when to use this tool versus alternatives (e.g., refresh_index, search_code_advanced). No explicit conditions for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_temp_directoryA

Check the temporary directory used for storing index data.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only states 'Check' without disclosing side effects or safety profile, leaving the agent to infer 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no extraneous text, efficiently conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has an output schema to explain return values, but the description could be more informative (e.g., what exactly is checked). Still adequate for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist and schema coverage is 100%; description adds no parameter info, but zero parameters warrant a baseline of 4.

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 uses the verb 'Check' and specifies the resource 'temporary directory used for storing index data,' clearly differentiating from sibling tools like 'create_temp_directory' which creates a directory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as 'get_settings_info' or 'create_temp_directory'; usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clear_settingsB

Clear all settings and cached data.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It implies destructive action ('clear all') but does not disclose side effects, reversibility, required permissions, or output behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence with no wasted words. It efficiently conveys the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is destructive and has no annotations, the description is insufficient. It does not clarify when to use it, what output to expect (though output schema exists), or implications for other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters, so coverage is complete. The description correctly implies no parameters needed. No additional parameter info necessary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool clears all settings and cached data, using a specific verb and resource. However, it does not differentiate from sibling tools like get_settings_info or configure_file_watcher, though the action is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool, what situations call for it, or what alternatives exist. The description simply states the action without any contextual advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

configure_file_watcherA

Configure file watcher service settings.

Args:
    enabled: Whether to enable file watcher
    debounce_seconds: Debounce time in seconds before triggering rebuild
    additional_exclude_patterns: Additional directory/file patterns to exclude
    observer_type: Observer backend to use. Options:
        - "auto" (default): platform default observer
        - "kqueue": Force kqueue observer (macOS/BSD)
        - "fsevents": Force FSEvents observer (macOS only, has known reliability issues)
        - "polling": Cross-platform polling fallback (slower but most compatible)

ParametersJSON Schema

Name	Required	Description	Default
`enabled`	No
`debounce_seconds`	No
`additional_exclude_patterns`	No
`observer_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adds some behavioral context, e.g., noting that fsevents observer has known reliability issues. However, it omits other traits like side effects, persistence of changes, or required privileges.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured with a clear purpose followed by an Args list. Every sentence adds value without redundancy, maintaining brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and no annotations, the description adequately covers parameter semantics and provides some behavioral context. Lacks high-level impact description but is sufficient for a configuration tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description thoroughly explains each parameter, including the observer_type options with platform-specific details. This compensates well for the lack of schema 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?

Clearly states 'Configure file watcher service settings' providing a specific verb and resource. The description further details the configurable aspects, distinguishing it from sibling tools like get_file_watcher_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives or any prerequisites. The description only lists arguments without context on usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_temp_directoryA

Create the temporary directory used for storing index data.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only states the creation action but omits critical details such as what happens if the directory already exists, permissions required, or 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words. It is appropriately sized for a zero-parameter tool and front-loaded with the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity and presence of an output schema, the description provides the basic purpose. However, it lacks information about idempotency or behavior when the directory already exists, which is important for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so baseline is 4. The description does not add parameter info, but none is needed.

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 action 'create' and the resource 'temporary directory' with purpose 'used for storing index data'. It distinguishes from sibling tool 'check_temp_directory' which checks existence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'check_temp_directory' or 'refresh_index'. The description lacks any contextual usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_filesA

Find files matching glob pattern using in-memory index. Supports path patterns (.py, test_.js) and filename-only matching (README.md).

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It mentions 'in-memory index' hinting at performance, but fails to disclose scope (e.g., which directories, case sensitivity) or side effects. As a safe read operation, this is adequate but not comprehensive.

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?

Two concise sentences front-load the core purpose and provide examples. Every word adds value; no redundancy. Slightly more structure (e.g., bullet points) would improve scannability but not necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nested objects) and presence of an output schema, the description covers the essential behavior. It does not explain return values, but that is handled by the output schema. Slightly missing details on scope or performance characteristics, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 to the 'pattern' parameter by explaining it supports glob patterns and providing specific examples ('*.py', 'README.md'). This compensates for the schema gap effectively.

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 finds files matching glob patterns using an in-memory index. It uses specific verbs ('Find files') and resources ('files'), and distinguishes from siblings like 'search_code_advanced' by focusing on path/filename patterns rather than content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides pattern examples but lacks explicit guidance on when to use this tool versus alternatives like 'search_code_advanced' or 'refresh_index'. It does not specify context or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_file_summaryB

Get a summary of a specific file, including:
- Line count
- Function/class definitions (for supported languages)
- Import statements
- Basic complexity metrics

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description lists what the tool returns (line count, definitions, etc.), giving behavioral insight. However, it omits details like file existence handling or read-only nature, which is acceptable but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is highly concise: one sentence plus three bullet points. Front-loaded with purpose, every line adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple tool with one parameter and existing output schema, the description covers the main functionality. Missing some error context or path format, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, and the tool description does not add parameter guidance beyond mentioning 'specific file'. It lacks format, required existence, or language support specifics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: getting a file summary with specific items like line count and definitions. It differentiates from siblings somewhat, as siblings like find_files or get_symbol_body are more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use vs alternatives. The description implies usage for file summaries but does not provide when-not-to-use or mention sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_file_watcher_statusA

Get file watcher service status and statistics.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Implicitly indicates a read-only operation, but lacks details on permissions or side effects. Without annotations, more behavioral context could be provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has zero parameters and an output schema to define return values. Description adequately covers purpose, though could hint at typical use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so baseline 4 applies. Description adds no extra semantics beyond the empty schema, but the tool is self-explanatory.

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 uses specific verb 'Get' and resource 'file watcher service status and statistics', clearly distinguishing from sibling tools like configure_file_watcher or refresh_index.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 check_temp_directory or get_file_summary. The description assumes basic understanding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_settings_infoB

Get information about the project settings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description does not disclose any behavioral traits such as whether the tool is read-only or has side effects. Although 'get' implies a read operation, explicit confirmation is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no fluff. It efficiently communicates the core purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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, has output schema), the description is mostly complete. However, it could clarify which project's settings are referenced or whether settings are global. The existence of an output schema reduces the need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so the description adds no parameter-level detail. Per guidelines, zero parameters defaults to a baseline of 4, as the schema already covers all needs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and resource 'project settings', making the purpose understandable. However, it does not differentiate from sibling tools like 'clear_settings' or 'configure_file_watcher', which also relate to settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as 'get_file_summary' or 'check_temp_directory'. The description lacks context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_symbol_bodyA

Get the source code body of a specific symbol (function, method, or class).

This tool retrieves only the code for the specified symbol, enabling efficient
context usage by avoiding loading entire files.

Args:
    file_path: Path to the file containing the symbol
    symbol_name: Name of the symbol to retrieve (e.g., "process_data", "MyClass.my_method")

Returns:
    Dictionary containing:
    - status: "success" or "error"
    - symbol_name: Name of the symbol
    - type: Type of symbol (function, method, class)
    - line: Start line number
    - end_line: End line number
    - code: The actual source code
    - signature: Function/method signature (if available)
    - docstring: Documentation string (if available)
    - called_by: List of symbols that call this symbol

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`symbol_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes retrieval behavior and return fields, but does not disclose side effects, prerequisites (e.g., indexing), or error conditions.

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?

Well-structured with Args and Returns sections, front-loaded with main purpose. However, the Returns section is verbose; could be shortened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters and detailed return fields in description, it covers what the tool does and what it returns. Lacks mention of prerequisites or error handling, but adequate for a retrieval tool.

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 description's Args section provides explicit meaning for both parameters (file_path, symbol_name) with examples, adding significant value beyond the bare 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 clearly states it gets the source code body of a specific symbol (function, method, or class). It distinguishes from siblings by highlighting efficient context usage and avoiding loading entire files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when only symbol code is needed via 'efficient context usage', but lacks explicit when-to-use/when-not-to-use statements or comparisons to siblings like get_file_summary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refresh_indexA

Manually rebuild the project file index. Use after git operations or when index seems stale.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full burden. It indicates rebuilding the index but does not disclose whether this is destructive, any side effects, permissions needed, or performance impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, direct sentences with no unnecessary words. Front-loads the action and usage hint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and an output schema exists, so description need not explain return values. However, it lacks details on safety, cost, or concurrency, which would be helpful given no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters with 100% schema description coverage. Baseline is 4; description adds no extra parameter info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('manually rebuild the project file index') and the resource. It provides usage context ('after git operations or when index seems stale'), which helps differentiate from sibling tool 'build_deep_index', though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use the tool ('after git operations or when index seems stale'), but does not provide when-not-to-use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refresh_search_toolsA

Manually re-detect the available command-line search tools on the system. This is useful if you have installed a new tool (like ripgrep) after starting the server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the action (re-detect) but lacks detail on side effects (e.g., overwriting custom settings) or return behavior. With no annotations, description carries full burden and is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 0-parameter tool with output schema, the description gives enough context to understand when to use it. Lacks description of output, but schema covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is trivial 100%. Description adds no param info, which is appropriate. Baseline of 4 applies.

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 uses specific verb 're-detect' and resource 'available command-line search tools', clearly distinguishing it from sibling tools that perform actual searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states a use case: after installing a new tool like ripgrep. Does not explicitly contrast with siblings but context implies it's for manual refresh when auto-detection fails.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_code_advancedA

Search for code pattern with pagination. Auto-selects best search tool (ugrep/ripgrep/ag/grep). Supports glob file_pattern (e.g., "*.py"), explicit regex mode, and fuzzy matching (ugrep only). Regex matching requires passing regex=True and may require an external search tool.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes
`case_sensitive`	No
`context_lines`	No
`file_pattern`	No
`fuzzy`	No
`regex`	No
`start_index`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses auto-selection of tools, regex requirement, and fuzzy limitation to ugrep. However, it omits details about pagination behavior across backends, error handling, and potential consequences of auto-selection failures. The mention of 'may require an external search tool' is vague.

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 concise with four sentences, front-loading the main purpose. It avoids redundancy but has minor duplication (ugrep only mentioned twice). Overall efficient communication.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and existing output schema, the description covers key behaviors and parameter highlights but lacks details on default values, error states, and return format. Adequate for basic use but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It adds meaning for pattern, file_pattern, regex, fuzzy, and pagination parameters, but does not explain case_sensitive, context_lines, or the exact syntax of pattern. Coverage is partial, not full.

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 it searches for code patterns with pagination and auto-selects the best search tool, distinguishing it from sibling tools like find_files which searches by file name. The mention of glob, regex, and fuzzy matching further clarifies its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for code pattern searches and lists supported features, but lacks explicit guidance on when to use this tool versus alternatives, such as when to prefer find_files or when not to use it. No when-not or exclusion criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_project_pathC

Set the base project path for indexing.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It only states the action without detailing side effects, validation, or error conditions. The mutation nature is implied but not elaborated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks important details. It's not overly verbose, but the brevity reduces its utility.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a simple 1-parameter tool and an output schema being present (not shown), the description fails to explain return values, errors, or post-conditions. It is incomplete for an agent to understand the full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'path' is described only by its name and type (string) in the schema, with 0% schema description coverage. The description adds no additional meaning, such as expected format, constraints, or examples.

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 tool name and description clearly indicate it sets the base project path for indexing. It's a specific verb+resource pair, distinct from siblings like 'refresh_index' or 'get_settings_info'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or conditions for use. It lacks context such as whether the path must exist or if it's relative.

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.

8 tool updatesv2.17.0May 7, 2026

Changedbuild_deep_index2 fields changed

addedInput schema / properties / max_workers

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Workers"
+}

addedInput schema / properties / timeout

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Timeout"
+}

Changedcheck_temp_directory4 fields changed

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"check_temp_directoryOutput"New value: +"check_temp_directoryDictOutput"

Changedcreate_temp_directory4 fields changed

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"create_temp_directoryOutput"New value: +"create_temp_directoryDictOutput"

Changedget_file_summary4 fields changed

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"get_file_summaryOutput"New value: +"get_file_summaryDictOutput"

Changedget_file_watcher_status4 fields changed

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"get_file_watcher_statusOutput"New value: +"get_file_watcher_statusDictOutput"

Changedget_settings_info4 fields changed

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"get_settings_infoOutput"New value: +"get_settings_infoDictOutput"

Addedget_symbol_body

Changedsearch_code_advanced8 fields changed

addedInput schema / properties / file_pattern / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / file_pattern / type
```
Removed value: -"string"
```

addedInput schema / properties / regex / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / regex / type
```
Removed value: -"boolean"
```
addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "additionalProperties": true,
-    "title": "Result",
-    "type": "object"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"search_code_advancedOutput"New value: +"search_code_advancedDictOutput"

13 tool updatesv1.0.0Jan 3, 2026

Addedbuild_deep_index

Changedcheck_temp_directory1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "check_temp_directoryOutput",
+  "type": "object"
+}

Changedclear_settings1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "clear_settingsOutput",
+  "type": "object"
+}

Changedconfigure_file_watcher2 fields changed

addedInput schema / properties / observer_type

Added value: +{
+  "default": null,
+  "title": "Observer Type",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "configure_file_watcherOutput",
+  "type": "object"
+}

Changedcreate_temp_directory1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "create_temp_directoryOutput",
+  "type": "object"
+}

Changedfind_files1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "type": "string"
+      },
+      "title": "Result",
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "find_filesOutput",
+  "type": "object"
+}

Changedget_file_summary1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_file_summaryOutput",
+  "type": "object"
+}

Changedget_file_watcher_status1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_file_watcher_statusOutput",
+  "type": "object"
+}

Changedget_settings_info1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_settings_infoOutput",
+  "type": "object"
+}

Changedrefresh_index1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "refresh_indexOutput",
+  "type": "object"
+}

Changedrefresh_search_tools1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "refresh_search_toolsOutput",
+  "type": "object"
+}

Changedsearch_code_advanced3 fields changed

addedInput schema / properties / max_results

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": 10,
+  "title": "Max Results"
+}

addedInput schema / properties / start_index

Added value: +{
+  "default": 0,
+  "title": "Start Index",
+  "type": "integer"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "search_code_advancedOutput",
+  "type": "object"
+}

Changedset_project_path1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "set_project_pathOutput",
+  "type": "object"
+}

12 tool updatesAug 15, 2025
- First observedcheck_temp_directory
- First observedclear_settings
- First observedconfigure_file_watcher
- First observedcreate_temp_directory
- First observedfind_files
- First observedget_file_summary
- First observedget_file_watcher_status
- First observedget_settings_info
- First observedrefresh_index
- First observedrefresh_search_tools
- First observedsearch_code_advanced
- First observedset_project_path

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action: index building, file watching, settings management, searching, etc. Overlap is minimal and descriptions clarify the differences.

Naming Consistency5/5

All tool names use a consistent verb_noun snake_case pattern (e.g., build_deep_index, check_temp_directory, get_file_summary). No mixing of conventions.

Tool Count5/5

14 tools cover indexing, searching, file details, symbol retrieval, settings, and utilities. This is well-scoped for a code index server, neither sparse nor excessive.

Completeness4/5

Covers core operations: index build/refresh, file and code search, symbol body retrieval, settings, file watcher. Minor gaps like listing symbols or index statistics exist but do not hinder primary use.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

MCP File Context Server
Coding Agents Developer Tools Code Execution
bsmi021
A
license
B
quality
F
maintenance
A Model Context Protocol server that enables LLMs to read, search, and analyze code files with advanced caching and real-time file watching capabilities.
Updated a year ago (2025-07-10 23:26 UTC)
6
19
39
MIT
@lex-tools/codebase-contextofficial
Code Analysis Developer Tools Documentation Access
lex-tools
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).
Updated a year ago (2025-08-02 06:43 UTC)
1
12
3
Apache 2.0
CodeAlive MCPofficial
Code Analysis RAG Systems Developer Tools
CodeAlive-AI
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
Updated 20 days ago (2026-08-16 13:58 UTC)
89
MIT
Local Project Sync
Code Analysis Developer Tools
xueshanisusan
F
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that enables AI applications to access and analyze local code repositories without manual uploads, providing file listing, content reading, code searching, and project structure analysis capabilities.
Updated a year ago (2025-07-31 19:47 UTC)
7
-

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/johnhuang316/code-index-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Code Index MCP

Overview

Quick Start

🚀 Recommended Setup (Most Users)

Codex CLI Configuration

FastMCP & Discovery Manifests

Typical Use Cases

Key Features

🔍 Intelligent Search & Analysis

🗂️ Multi-Language Support

⚡ Real-time Monitoring & Auto-refresh

⚡ Performance & Efficiency

Supported File Types

🛠️ Development Setup

Available Tools

🏗️ Project Management

🔍 Search & Discovery

🔄 Monitoring & Auto-refresh

🛠️ System & Maintenance

Usage Examples

🎯 Quick Start Workflow

🔍 Advanced Search Examples

Troubleshooting

🔄 Auto-refresh Not Working

macOS File Watcher Options

Development & Contributing

🔧 Building from Source

🐛 Debugging

🤝 Contributing

📜 License

🌐 Translations

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@lex-tools/codebase-contextofficial

CodeAlive MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API