Skip to main content
Glama
marksolly

Code Index MCP

by marksolly

search_code_advanced

Search codebases for patterns using automatic tool selection with options for case sensitivity, context lines, file filters, fuzzy matching, and regex.

Instructions

Search for a code pattern in the project using an advanced, fast tool.

This tool automatically selects the best available command-line search tool
(like ugrep, ripgrep, ag, or grep) for maximum performance.

Args:
    pattern: The search pattern. Can be literal text or regex (see regex parameter).
    case_sensitive: Whether the search should be case-sensitive.
    context_lines: Number of lines to show before and after the match.
    file_pattern: A glob pattern to filter files to search in
                 (e.g., "*.py", "*.js", "test_*.py").
                 All search tools now handle glob patterns consistently:
                 - ugrep: Uses glob patterns (*.py, *.{js,ts})
                 - ripgrep: Uses glob patterns (*.py, *.{js,ts})
                 - ag (Silver Searcher): Automatically converts globs to regex patterns
                 - grep: Basic glob pattern matching
                 All common glob patterns like "*.py", "test_*.js", "src/*.ts" are supported.
    fuzzy: If True, enables fuzzy/partial matching behavior varies by search tool:
           - ugrep: Native fuzzy search with --fuzzy flag (true edit-distance fuzzy search)
           - ripgrep, ag, grep, basic: Word boundary pattern matching (not true fuzzy search)
           IMPORTANT: Only ugrep provides true fuzzy search. Other tools use word boundary
           matching which allows partial matches at word boundaries.
           For exact literal matches, set fuzzy=False (default and recommended).
    regex: Controls regex pattern matching behavior:
           - If True, enables regex pattern matching
           - If False, forces literal string search
           - If None (default), automatically detects regex patterns and enables regex for patterns like "ERROR|WARN"
           The pattern will always be validated for safety to prevent ReDoS attacks.

Returns:
    A dictionary containing the search results or an error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patternYes
case_sensitiveNo
context_linesNo
file_patternNo
fuzzyNo
regexNo
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: automatic selection among ugrep, ripgrep, ag, grep; tool-specific behavior for fuzzy and regex patterns; safety validation to prevent ReDoS; and how file_pattern globs are handled consistently. This goes beyond what schema provides.

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: first line states purpose, then bullet-like parameter explanations. However, parameter descriptions are verbose, especially file_pattern and fuzzy, which could be more concise. The essential info is front-loaded, but overall length could be 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?

Given 6 parameters (1 required), no output schema, and no annotations, the description thoroughly covers all aspects: parameter meanings, automatic tool selection, edge cases (fuzzy tool differences, regex auto-detection, safety validation), and return type (dictionary with results or error). It is fully sufficient for an AI agent to use the tool correctly.

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?

Schema has 0% coverage, so description must carry full weight. It adds detailed semantics for each parameter: pattern (literal/regex), case_sensitive, context_lines, file_pattern (glob handling per tool), fuzzy (tool differences), regex (auto-detection). While thorough, some repetition (e.g., file_pattern details repeated) prevents a perfect score.

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: 'Search for a code pattern in the project using an advanced, fast tool.' It specifies the verb 'search' and resource 'code pattern', and distinguishes from sibling tools like 'find_files' (which likely searches by file name) by emphasizing 'advanced' and 'fast' and automatic tool selection.

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?

The description indicates when to use this tool (searching code patterns, automatic selection of best command-line tool) but does not explicitly state when not to use it or contrast with alternatives. However, it implicitly differentiates from siblings by describing its advanced nature, so nearly comprehensive.

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

Install Server

Other Tools

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/marksolly/code-scope-mcp'

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