Which integrations are available for this server?

Provides package management functionality for installing dependencies and building the MCP server project Enables type-safe development with TypeScript configuration and compilation support Implements input validation using Zod schemas to ensure secure command execution

How do I use Grep MCP Server?

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., "@Grep MCP Server find all email addresses in the src directory" 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.

Grep MCP Server

by 247arjun

Overview Schema Related Servers Score Discussions

JavaScript

Local

MCP Server for Grep

npm version npm downloads

A Model Context Protocol (MCP) server that provides powerful text search capabilities using the grep command-line utility. This server allows you to search for patterns in files and directories using both natural language descriptions and direct regex patterns.

Features

🧠 Natural Language Search

Describe what you're looking for in plain English
Automatic conversion to appropriate regex patterns
Built-in patterns for common searches (emails, URLs, phone numbers, etc.)

🔍 Advanced Search Capabilities

Direct regex pattern matching
Recursive directory searching
File extension filtering
Case-sensitive/insensitive search
Whole word matching
Context line display
Match counting
File listing with matches

🛡️ Security First

Safe command execution using child_process.spawn
Input validation with Zod schemas
No shell injection vulnerabilities
Path validation and sanitization

Related MCP server: Greply MCP Server

Installation

Method 1: NPM Installation (Recommended)

# Install globally
npm install -g @247arjun/mcp-grep

# Or install locally in your project
npm install @247arjun/mcp-grep

Method 2: From Source

# Clone the repository
git clone https://github.com/247arjun/mcp-grep.git
cd mcp-grep

# Install dependencies
npm install

# Build the project
npm run build

# Optional: Link globally
npm link

Method 3: Direct from GitHub

# Install directly from GitHub
npm install -g git+https://github.com/247arjun/mcp-grep.git

Configuration

Claude Desktop Setup

Add to your Claude Desktop configuration file:

Location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json

Configuration:

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

Alternative: Using npx (no global install needed)

{
  "mcpServers": {
    "mcp-grep": {
      "command": "npx",
      "args": ["@247arjun/mcp-grep"]
    }
  }
}

Local Development Setup

{
  "mcpServers": {
    "mcp-grep": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-grep/build/index.js"]
    }
  }
}

After adding the configuration, restart Claude Desktop to load the MCP server.

Verification

Test that the server is working:

# Test the built server
node build/index.js

# Should show: "Grep MCP Server running on stdio"
# Press Ctrl+C to exit

Available Tools

1. `grep_search_intent`

Search using natural language descriptions.

Parameters:

intent (string): Plain English description (e.g., "email addresses", "TODO comments")
target (string): File or directory path to search
case_sensitive (boolean, optional): Case-sensitive search (default: false)
max_results (number, optional): Limit number of results
show_context (boolean, optional): Show surrounding lines (default: false)
context_lines (number, optional): Number of context lines (default: 2)

Example:

{
  "intent": "email addresses",
  "target": "./src",
  "show_context": true,
  "context_lines": 1
}

2. `grep_regex`

Search using direct regex patterns.

Parameters:

pattern (string): Regular expression pattern
target (string): File or directory path to search
case_sensitive (boolean, optional): Case-sensitive search
whole_words (boolean, optional): Match whole words only
invert_match (boolean, optional): Show non-matching lines
max_results (number, optional): Limit results
show_context (boolean, optional): Show context lines
context_lines (number, optional): Context line count
file_extensions (array, optional): Filter by file extensions

Example:

{
  "pattern": "function\\s+\\w+\\s*\\(",
  "target": "./src",
  "file_extensions": ["js", "ts"],
  "show_context": true
}

3. `grep_count`

Count matches for a pattern.

Parameters:

pattern (string): Pattern to count
target (string): Search target
case_sensitive (boolean, optional): Case sensitivity
whole_words (boolean, optional): Whole word matching
by_file (boolean, optional): Show count per file
file_extensions (array, optional): File extension filter

4. `grep_files_with_matches`

List files containing the pattern.

Parameters:

pattern (string): Search pattern
target (string): Directory to search
case_sensitive (boolean, optional): Case sensitivity
whole_words (boolean, optional): Whole word matching
file_extensions (array, optional): File extensions to include
exclude_patterns (array, optional): File patterns to exclude

5. `grep_advanced`

Execute grep with custom arguments (advanced users).

Parameters:

args (array): Array of grep arguments (excluding 'grep' itself)

Built-in Natural Language Patterns

The server recognizes these natural language intents:

Communication

"email", "email address", "emails" → Email address pattern
"url", "urls", "website", "link", "links" → URL pattern
"phone", "phone number", "phone numbers" → Phone number pattern

Network

"ip", "ip address", "ip addresses" → IPv4 address pattern

Data Types

"number", "numbers", "integer", "integers" → Numeric patterns
"date", "dates" → Date patterns

Code Patterns

"function", "functions" → Function declarations
"class", "classes" → Class definitions
"import", "imports" → Import statements
"export", "exports" → Export statements
"comment", "comments" → Comment lines
"todo", "todos" → TODO/FIXME/HACK comments

Error Patterns

"error", "errors" → Error messages
"warning", "warnings" → Warning messages

Usage Examples

Search for email addresses in a project

{
  "tool": "grep_search_intent",
  "intent": "email addresses",
  "target": "./src",
  "show_context": true
}

Find all TODO comments

{
  "tool": "grep_search_intent", 
  "intent": "todo comments",
  "target": "./",
  "file_extensions": ["js", "ts", "py"]
}

Search for function definitions with regex

{
  "tool": "grep_regex",
  "pattern": "^\\s*function\\s+\\w+",
  "target": "./src",
  "file_extensions": ["js"]
}

Count occurrences of a word

{
  "tool": "grep_count",
  "pattern": "async",
  "target": "./src",
  "by_file": true
}

List files containing import statements

{
  "tool": "grep_files_with_matches",
  "pattern": "^import",
  "target": "./src",
  "file_extensions": ["js", "ts"]
}

Development

Build and Run

# Development with auto-rebuild
npm run dev

# Production build
npm run build

# Start the server
npm start

Project Structure

mcp-grep/
├── src/
│   └── index.ts          # Main server implementation
├── build/                # Compiled JavaScript output
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
└── README.md            # This file

Troubleshooting

Common Issues

"Command not found" error
- Ensure mcp-grep is installed globally: npm install -g @247arjun/mcp-grep
- Or use npx: "command": "npx", "args": ["@247arjun/mcp-grep"]
"Permission denied" error
- Check file permissions: chmod +x build/index.js
- Rebuild the project: npm run build
MCP server not appearing in Claude
- Verify JSON syntax in configuration file
- Restart Claude Desktop completely
- Check that the command path is correct
"grep command not found"
- Install grep on your system (usually pre-installed on macOS/Linux)
- Windows users: Install via WSL or use Git Bash

Debugging

Enable verbose logging by setting environment variable:

# For development
DEBUG=1 node build/index.js

# Test with sample input
echo '{"jsonrpc": "2.0", "method": "initialize", "params": {}}' | node build/index.js

Security Notes

Uses spawn with shell: false to prevent command injection
Validates all file paths before execution
Blocks potentially dangerous grep flags in advanced mode
Input validation with Zod schemas
No access to system files outside specified targets

Available Tools

5 tools

grep_advancedC

Execute grep with custom arguments (advanced usage)

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes	Array of grep arguments (excluding 'grep' itself)

TDQS

C2.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 carries the full burden of behavioral disclosure. It mentions 'execute grep' which implies a read operation, but doesn't disclose critical traits like whether it modifies files, requires specific permissions, has rate limits, or what the output format is (e.g., text lines, error handling). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads the key information ('Execute grep with custom arguments') and adds a qualifier ('advanced usage'). There's no wasted text, making it appropriately concise, though it could be slightly more structured by explicitly stating the tool's core function upfront.

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 complexity of a grep tool (which can involve various arguments and behaviors), no annotations, and no output schema, the description is incomplete. It doesn't explain what grep does, what the output looks like, or how to interpret results, leaving the agent under-informed for proper tool invocation in this context.

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?

The schema description coverage is 100%, with the parameter 'args' fully documented in the schema as 'Array of grep arguments (excluding 'grep' itself)'. The description adds no additional meaning beyond this, such as examples of common arguments or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.

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

Purpose3/5

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

The description 'Execute grep with custom arguments (advanced usage)' states the action (execute grep) and scope (custom arguments, advanced usage), but it's vague about what 'grep' specifically does (text search) and doesn't clearly distinguish from siblings like 'grep_regex' or 'grep_search_intent' that might also involve advanced grep usage. It avoids tautology but lacks specificity.

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 like 'grep_regex' or 'grep_count', nor does it mention prerequisites or exclusions. The term 'advanced usage' implies a context but doesn't specify what makes it advanced or when it's appropriate, leaving the agent with no clear usage rules.

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

grep_countC

Count the number of matches for a pattern

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern or plain text to count
`target`	Yes	File or directory path to search in
`case_sensitive`	No	Whether the search should be case sensitive
`whole_words`	No	Match whole words only
`by_file`	No	Show count per file when searching directories
`file_extensions`	No	Only search files with these extensions

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 carries the full burden of behavioral disclosure. It states what the tool does ('count matches') but doesn't describe how it behaves—e.g., whether it searches recursively in directories, handles errors, or returns structured output. For a tool with 6 parameters and no annotations, this is a significant gap in transparency.

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 extremely concise—a single sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it efficient for an agent to parse quickly.

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's complexity (6 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the tool returns (e.g., a number, a list), how it handles directories versus files, or error conditions. For a grep-like tool with multiple siblings, more context is needed to guide proper usage.

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?

The description doesn't add any semantic meaning beyond what the input schema provides. Since schema description coverage is 100%, the schema already fully documents all parameters (pattern, target, case_sensitive, whole_words, by_file, file_extensions). The baseline score of 3 is appropriate as the schema does the heavy lifting, but the description doesn't enhance parameter understanding.

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 with a specific verb ('count') and resource ('matches for a pattern'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings (grep_advanced, grep_files_with_matches, grep_regex, grep_search_intent), which likely have overlapping functionality, so it doesn't reach the highest score.

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 its siblings or alternatives. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

grep_files_with_matchesB

List only the names of files that contain the pattern

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern or plain text to search for
`target`	Yes	Directory path to search in
`case_sensitive`	No	Whether the search should be case sensitive
`whole_words`	No	Match whole words only
`file_extensions`	No	Only search files with these extensions
`exclude_patterns`	No	Exclude files matching these patterns

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists file names with matches, but doesn't cover critical behaviors like whether it's read-only (implied but not explicit), how it handles errors, if it supports pagination for large results, or what the output format looks like (e.g., plain list vs structured data). This is a significant gap for a search tool with no annotation coverage.

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, efficient sentence: 'List only the names of files that contain the pattern.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every word earns its place.

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 tool's moderate complexity (6 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., output format, error handling) and usage guidelines relative to siblings. With no output schema, it should ideally hint at return values, but it doesn't, leaving gaps in completeness.

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 100%, so the schema fully documents all 6 parameters (pattern, target, case_sensitive, whole_words, file_extensions, exclude_patterns). The description adds no parameter-specific information beyond what's in the schema, such as examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.

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: 'List only the names of files that contain the pattern.' It specifies the verb ('List') and resource ('names of files'), and distinguishes it from siblings like grep_count (which likely counts matches) or grep_advanced (which might return more details). However, it doesn't explicitly differentiate from grep_search_intent, leaving some ambiguity.

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 its siblings (grep_advanced, grep_count, grep_regex, grep_search_intent). It doesn't mention alternatives, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

grep_regexC

Search using a direct regex pattern

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern to search for
`target`	Yes	File or directory path to search in
`case_sensitive`	No	Whether the search should be case sensitive
`whole_words`	No	Match whole words only
`invert_match`	No	Show lines that don't match the pattern
`max_results`	No	Maximum number of results to return
`show_context`	No	Show surrounding lines for context
`context_lines`	No	Number of context lines to show before/after matches
`file_extensions`	No	Only search files with these extensions (e.g., ['js', 'ts'])

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'search' but doesn't describe what gets returned (e.g., lines, matches, counts), error handling, performance implications, or any constraints like rate limits or permissions. For a tool with 9 parameters and no annotations, this is a significant gap in transparency.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core function without unnecessary elaboration, making it easy for an agent to parse quickly.

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 complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., search results format), behavioral traits, or how it differs from siblings. For a search tool with rich parameters, more context is needed to guide effective use.

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 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters (e.g., how 'whole_words' modifies 'pattern') or providing usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Search using a direct regex pattern' states the verb ('search') and resource ('regex pattern'), but it's vague about what exactly is being searched (files, text, etc.) and doesn't distinguish from sibling tools like 'grep_advanced' or 'grep_search_intent'. It provides a basic purpose but lacks specificity and differentiation.

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 'grep_advanced' or 'grep_search_intent'. The description implies a direct regex search, but it doesn't specify contexts, prerequisites, or exclusions, leaving the agent with no usage direction beyond the tool name.

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

grep_search_intentB

Search for patterns using plain English descriptions (e.g., 'email addresses', 'phone numbers', 'TODO comments')

ParametersJSON Schema

Name	Required	Description
`intent`	Yes	Plain English description of what to search for
`target`	Yes	File or directory path to search in
`case_sensitive`	No	Whether the search should be case sensitive
`max_results`	No	Maximum number of results to return
`show_context`	No	Show surrounding lines for context
`context_lines`	No	Number of context lines to show before/after matches

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the search functionality, it doesn't describe what happens when matches are found (e.g., returns matches with line numbers), performance characteristics, error conditions, or whether the search is recursive through directories. For a tool with 6 parameters and no annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that immediately communicates the core functionality with relevant examples. Every element earns its place - the main action, the input method, and concrete examples all contribute to understanding without any wasted words or unnecessary elaboration.

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?

For a tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (matches, counts, files?), how results are formatted, error handling, or performance considerations. The high parameter count and lack of structured metadata mean the description should provide more behavioral context to be truly helpful.

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 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining the 'intent' parameter's purpose ('plain English descriptions') with helpful examples, but doesn't provide additional semantic context beyond what's in the schema for other parameters. This meets the baseline for high schema 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 specific action ('Search for patterns') and resource ('using plain English descriptions'), with concrete examples ('email addresses', 'phone numbers', 'TODO comments') that help distinguish it from regex-based sibling tools like grep_regex. It precisely communicates the tool's unique capability of intent-based pattern matching.

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 context through the examples of plain English descriptions, suggesting this tool is for high-level pattern matching rather than precise regex patterns. However, it doesn't explicitly state when to use this vs. alternatives like grep_advanced or grep_regex, nor does it mention any exclusions or prerequisites for usage.

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.

5 tool updatesAug 15, 2025
- First observedgrep_advanced
- First observedgrep_count
- First observedgrep_files_with_matches
- First observedgrep_regex
- First observedgrep_search_intent

Install Server

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

TDQS

B3.2/5.0

Disambiguation3/5

The tools have overlapping purposes, as grep_advanced, grep_regex, and grep_search_intent all perform pattern searches, which could cause confusion. However, grep_count and grep_files_with_matches are more distinct in focusing on counting matches and listing files, respectively, which helps mitigate ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a 'grep_' prefix, making them predictable and easy to understand. This uniformity enhances clarity and usability across the tool set.

Tool Count5/5

With 5 tools, the server is well-scoped for a grep-focused utility, offering a reasonable range of operations without being overwhelming. Each tool appears to serve a specific function, justifying its inclusion.

Completeness4/5

The tool set covers core grep functionalities like searching, counting, and file listing, with advanced and intent-based options. A minor gap is the lack of a basic grep tool for simple pattern matching, but agents can work around this using the provided tools.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

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

sunub-obsidian-mcp-server
ai.smithery
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Note Taking Search Text Summarization
22
Maguyva
ai.maguyva
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code Analysis Coding Agents
23
OrchaOAuth
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
GitHits AOAuth
com.githits
Search public open-source code, documentation, metadata, vulnerabilities, changelogs, and examples.
Developer Tools Documentation Access Search
295

Related MCP Servers

MCP Ripgrep Server
Search Command Line File Systems
mcollina
A
license
B
quality
D
maintenance
Provides ripgrep search capabilities to MCP clients like Claude, allowing high-performance text searches across files on your system.
Updated a year ago (2025-04-29 21:59 UTC)
5
1,018
74
MIT
Greply MCP Server
File Systems Shell Access Command Line
AnthonyRuffino
A
license
B
quality
C
maintenance
Enables file and directory searching through the greply CLI tool with configurable search options like context lines, case sensitivity, and pattern matching. Provides direct access to powerful grep-like functionality from MCP-compatible clients.
Updated a year ago (2025-08-11 02:41 UTC)
2
21
MIT
Local Filesystem MCP Server
paracetamol951
-
license
Not graded
quality
Not graded
maintenance
Enables exploration and search of local filesystems using glob pattern matching to find files and grep to search for text patterns within files.
Updated 10 months ago (2025-11-13 20:01 UTC)
-
Local Filesystem MCP Server
File Systems Developer Tools Command Line
xue20010808
F
license
Not graded
quality
Not graded
maintenance
Enables exploration and search of local filesystems using glob pattern matching to find files and grep to search for text patterns within files.
Updated 9 months ago (2025-12-09 08:29 UTC)
-

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/247arjun/mcp-grep'

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

MCP Server for Grep

Features

🧠 Natural Language Search

🔍 Advanced Search Capabilities

🛡️ Security First

Installation

Method 1: NPM Installation (Recommended)

Method 2: From Source

Method 3: Direct from GitHub

Configuration

Claude Desktop Setup

Verification

Available Tools

1. grep_search_intent

2. grep_regex

3. grep_count

4. grep_files_with_matches

5. grep_advanced

Built-in Natural Language Patterns

Communication

Network

Data Types

Code Patterns

Error Patterns

Usage Examples

Search for email addresses in a project

Find all TODO comments

Search for function definitions with regex

Count occurrences of a word

List files containing import statements

Development

Build and Run

Project Structure

Troubleshooting

Common Issues

Debugging

Security Notes

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `grep_search_intent`

2. `grep_regex`

3. `grep_count`

4. `grep_files_with_matches`

5. `grep_advanced`