Skip to main content
Glama

Ripgrep search

rg
Read-only

Search file contents with regex to find text across files and return structured match rows; filter by glob, ignore case, count per file, or extract matched substrings.

Instructions

Search file contents with ripgrep. Returns files as [file, "line:text", ...] rows (a context line is "line-text"), [file, count] under countPerFile, [file] under filesOnly. Use glob (string or array, '!' to exclude) to filter files, ignoreCase for case-insensitive search, filesOnly for just filenames, countPerFile for match counts per file, maxPerFile to cap hits per file. For 'collect all X' tasks use only:true to return just the matched substrings (one row per hit) — add replace ($1 capture groups) to extract structured values.

Input Schema

NameRequiredDescriptionDefault
globNoFile glob filter(s); a string or array. Prefix with '!' to exclude (e.g. ['*.ts','!*.test.ts'])
onlyNoReturn only the matched substring(s), not the whole line — one row per match. Best for collecting tokens (versions, names, URLs)
pathNoDirectory or file to search (default: cwd)
contextNoLines of context around each match
patternNoRequired. Regex pattern to search for
replaceNoRewrite each match with this template ($1, $2 capture groups) and return the result; implies only-match extraction
filesOnlyNoOnly return filenames, not matched lines
ignoreCaseNoCase-insensitive search
maxPerFileNoCap matches per file (rg --max-count), independent of maxResults — keeps one hot file from dominating
maxResultsNoMax results to return across all files (default 30). When the cap bites, the response reports the true totalMatches so you can decide whether to narrow the pattern or raise the cap
countPerFileNoReturn match counts grouped by file instead of individual matches
fixedStringsNoTreat pattern as literal string
maxLineLengthNoWindow matched line text to ~this many chars centered on the match, so long/minified lines don't dump in full (0 = unlimited, default 120)

Output Schema

NameRequiredDescriptionDefault
filesYes
retainedNo
truncatedNoPresent only when maxResults cut the matches
matchCountNoMatches returned; with countPerFile, the sum of counts
totalMatchesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv5.0.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real behavioral context — the exact row shapes returned under each mode and the fact that maxResults caps results but reports true totalMatches so the agent can widen or narrow. No mention of auth, performance, or ignore-file behavior, so not a 5.

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?

Front-loaded with purpose and return shapes, and every sentence conveys usable information. The middle section is a dense comma-and-parenthetical list of flags, which reads more like a compressed cheat sheet than clean prose, costing it the top band.

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 13-parameter tool with an output schema already present, the description covers what structured fields don't: return row formats per mode and the truncation/totalMatches contract. It omits defaults like cwd for path and doesn't address error or no-match behavior, so there is a small residual gap.

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 coverage is 100%, so baseline is 3; the description earns above that by explaining parameter interactions the schema states only in isolation — replace implies only-match extraction, maxPerFile is independent of maxResults, and glob's '!' exclusion form. Most of the per-parameter detail is still schema-owned.

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?

States a specific verb and resource ('Search file contents with ripgrep'), which cleanly separates it from filename-oriented siblings like glob and find_files. It does not explicitly name those siblings as alternatives, so it falls just short of the top band.

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?

Gives concrete conditional guidance: use glob to filter files, only:true for 'collect all X' tasks, replace with capture groups to extract structured values. Missing an explicit 'use this instead of X when...' routing against sibling search/list tools.

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