Skip to main content
Glama
AtefAndrus

@atef_andrus/mcp-ripgrep

by AtefAndrus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Ripgrep Search and Replace Preview

search-and-replace

Preview find-and-replace results across files with ripgrep without altering them. Validate regex capture groups ($1, $2, ${name}) before applying changes.

Instructions

Read-only preview of search-and-replace results using ripgrep. Does NOT modify files. Useful for previewing replacements and testing capture groups ($1, $2, ${name}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
globNoGlob pattern to filter files
pathYesDirectory or file to search
patternYesSearch pattern (regex by default)
fileTypeNoFilter by file type (e.g. 'ts', 'py')
maxDepthNoMaximum directory traversal depth
noIgnoreNoDo NOT respect .gitignore rules (search files that are normally ignored)
multilineNoEnable multiline matching (for function signatures, import blocks, etc.)
wordMatchNoOnly match whole words
maxResultsNoMaximum matches per file
fileTypeNotNoExclude file type (e.g. 'json')
replacementYesReplacement string (supports $1, $2, ${name} for capture groups)
fixedStringsNoTreat pattern as a literal string
onlyMatchingNoShow only the matched/replaced text instead of the full line (useful for extracting captured groups)
caseSensitiveNotrue = case-sensitive, false = case-insensitive, omit = smart-case
includeHiddenNoInclude hidden files and directories
maxCharactersNoMaximum characters in the result. Truncated with summary if exceeded.
followSymlinksNoFollow symbolic links

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the safety burden and does well by declaring the operation is read-only and does not modify files, plus mentions capture group substitution semantics. It omits any note on result truncation/limits or output shape, though maxCharacters is documented in the schema.

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?

Three short sentences with the most important constraint (read-only, no modification) front-loaded. No filler or restatement of the tool name.

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?

For a 17-parameter tool with no annotations and no output schema, the description is quite thin — it doesn't explain what the preview output looks like, how matches are reported, or how truncation surfaces. The rich schema compensates somewhat, so it is adequate but not 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 coverage is 100%, so every parameter is already documented, giving a baseline of 3. The description echoes capture-group syntax ($1, $2, ${name}) that is already present in the replacement parameter description, adding no 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?

States a specific verb and resource ('search-and-replace results using ripgrep') and immediately narrows scope with 'Read-only preview' and 'Does NOT modify files'. An agent can distinguish it from the sibling 'search' tool, which presumably only finds matches without replacement.

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 clear when-to-use context ('previewing replacements and testing capture groups'). However, it never names an alternative tool or states when NOT to use it (e.g., 'use search if you only need to find matches'), so routing guidance is implicit rather than explicit.

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

Deploy Server

Other Tools