Skip to main content
Glama
reflex-search

Reflex

Official

search_regex

Search your codebase with regex patterns, returning all matches with file paths, line numbers, and previews. Handles special characters and complex regex operators.

Instructions

Regex code search across the whole codebase. Prefer this over rg / grep -E / grep -P for pattern matching across files — one call returns every match with file paths, line numbers, and previews.

Use this for patterns with special characters or regex operators: ->with\(, ::new\(, fn (get|set)_\w+, \[(derive|test)\], \bAuth\w*Controller\b, alternation a|b, anchors ^$, wildcards .*. Escaping: must escape ( ) [ ] { } . * + ? \\ | ^ $; no escaping needed for -> :: - _ / = < >; in JSON use double backslashes (\\(, \\[).

For simple alphanumeric patterns use search_code instead — it is faster and avoids escaping overhead. For symbol definitions use search_code with symbols: true.

mode: "count" returns {count, pattern} only. List-mode result shape is columnar: {columns, rows} — each row aligns positionally to columns (path, language, start_line, end_line, preview; then kind/symbol/context when present). Set env REFLEX_MCP_COLUMNAR=0 for the legacy results[] shape. Pagination: if response.pagination.has_more is true, fetch the next page with offset. On "Index not found" / "stale" error, call index_project, then retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoFilter by file path
globNoInclude files matching glob patterns
langNoFilter by language
modeNoResponse mode: "list" (default) returns full match results; "count" returns only {count, pattern} — faster, skips match body serialization.
forceNoForce execution of potentially expensive queries (bypasses broad query detection)
limitNoMaximum number of results (default: 200, max: 500). Use with offset for pagination.
pathsNoReturn only unique file paths
offsetNoPagination offset (skip first N results after sorting)
excludeNoExclude files matching glob patterns
patternYesRegex pattern
dependenciesNoInclude dependency information (imports) in results. Only extracts static imports.
Behavior4/5

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

The description thoroughly explains behavior including result structure (columnar), pagination (offset, has_more), error handling (index_project), and output customization (env var). It does not explicitly state read-only, but the nature of search implies no side effects. Lacks explicit mention of idempotency.

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 efficiently organized with clear sections, immediate purpose statement, and concise guidance. While it is longer than some, the information density justifies the length; no redundant sentences.

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?

For a tool with no output schema and no annotations, the description is remarkably complete. It addresses purpose, when to use, parameter semantics, result format, pagination, error recovery, and configuration options. Few gaps remain.

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?

The description significantly enriches parameter semantics with concrete examples and escaping rules for the `pattern` parameter, clarifies mode behavior, pagination details, and glob filtering. It leverages the high schema coverage to provide actionable guidance rather than redundancy.

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 explicitly defines the tool's function as regex code search across the entire codebase, distinguishes it from alternatives like search_code and rg/grep, and details the output format (file paths, line numbers, previews). No ambiguity.

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 and when-not-to-use guidance, directly naming alternatives (search_code, rg/grep) and specifying conditions (simple patterns vs regex, symbol searches). It also gives context for mode selection.

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/reflex-search/reflex'

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