Grep MCP Server

by 247arjun

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 2.9/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-grep MCP server](https://glama.ai/mcp/servers/247arjun/mcp-grep/badges/card.svg)](https://glama.ai/mcp/servers/247arjun/mcp-grep)

Score Badge

Copy to your README.md:

[![mcp-grep MCP server](https://glama.ai/mcp/servers/247arjun/mcp-grep/badges/score.svg)](https://glama.ai/mcp/servers/247arjun/mcp-grep)

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