Greply MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Greply MCP Serversearch for 'TODO' in src/ with 2 lines of context before and after"
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.
greply MCP Server
An MCP server that wraps the greply CLI (Node wrapper for the greppy search tool).
This allows you to use greply directly from an MCP-compatible client such as the Gemini CLI.
Features
greply.search— rungreplywith query, before/after context, and flags.greply.help— printgreplyusage text.
Related MCP server: MCP-Grep
Requirements
Node.js 20 or newer (22 LTS recommended)
npmorpnpmfor dependency installationgreplyCLI available on PATH, or specifygreply_CMDenv var
Installation
Clone and install dependencies:
git clone https://github.com/your-org/greply-mcp-server.git
cd greply-mcp-server
# Make sure Node version is >= 20
node -v
# If needed:
# curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
# source ~/.nvm/nvm.sh
# nvm install 22 && nvm use 22
npm installUsage
Run the server directly:
node server.mjsOr with npm:
npm startGemini CLI Configuration
Add this to your ~/.gemini/settings.json:
{
"mcpServers": {
"greply": {
"command": "node",
"args": ["/absolute/path/to/greply-mcp-server/server.mjs"],
"env": {
"greply_CMD": "/usr/local/bin/greppy"
}
}
}
}greply_CMDis optional — only set it if the server cannot findgreplyautomatically.Use an absolute path for
server.mjs.
Tools
greply.search
Search files or directories with the given query and optional flags.
Input schema:
Field | Type | Description |
| string | Search term (required) |
| string | File or directory (default |
| integer | Lines of context before match ( |
| integer | Lines of context after match ( |
| boolean | Recurse directories ( |
| boolean | Match whole words ( |
| boolean | Case-sensitive match ( |
| boolean | Fixed-string match ( |
| boolean | Return stdout/stderr on non-zero exit |
greply.help
Display greply usage information.
Available Tools
2 toolsgreply.helpShow greply usageA
Runs greply with no args to print usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the behavior: runs greply with no args to print usage, which is transparent and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word is necessary and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It could optionally elaborate on what the usage output includes, but it is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds no parameter information because none is needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prints usage by running with no arguments. It distinguishes from the sibling 'greply.search' which likely does search, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining usage information. While it does not explicitly state when not to use it or mention alternatives, the sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
greply.searchSearch with greplyC
Run the greply CLI to search files with optional context and flags.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| target | No | . | |
| before | No | ||
| after | No | ||
| recursive | No | ||
| wholeWord | No | ||
| matchCase | No | ||
| fixedStrings | No | ||
| noColor | No | ||
| greplyCmd | No | ||
| suppressErrors | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies executing an external CLI command but does not disclose side effects, required permissions, output format, or error behavior. Without annotations, the burden on the description is high, and it fails to provide critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is too brief to be informative. Conciseness is achieved at the expense of clarity and completeness, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no annotations, and no output schema. The description provides almost no context, leaving the agent without enough information to correctly invoke the tool. It is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for 11 parameters. It only vaguely mentions 'optional context and flags', adding no meaningful detail about individual parameters like query, target, or boolean flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs 'greply CLI to search files', specifying verb and resource. It differentiates from sibling 'greply.help' by being a search tool. However, it lacks specificity on what 'greply' is or the scope of search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only sibling is 'greply.help', but description does not explicitly say when to search vs get help. No conditions or exclusions are mentioned.
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.
1 tool update
v1.0.0- Changed
greply.help1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
2 tool updates
- First observed
greply.help - First observed
greply.search
TDQS
The two tools have clearly distinct purposes: one for displaying usage/help and one for performing searches. There is no overlap in functionality.
Both tools follow a consistent 'greply.<action>' naming pattern, which is predictable and clearly indicates the tool's purpose.
With only two tools, the server is minimal. While a help tool and a search tool cover the basic operations for a CLI wrapper, the low count may leave agents wanting for more functionality.
The tool surface lacks essential operations beyond help and search, such as configuration management, result filtering, or output formatting. Agents may find the server inadequate for complex search tasks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Agentic search over your Dewey document collections from any MCP-compatible client.
Discover 6,700+ MCP servers and 15,000+ OpenClaw skills. Agent-native search with outcome ranking.
Search Hacker News, Bluesky, and Substack from a single MCP interface
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides ripgrep search capabilities to MCP clients like Claude, allowing high-performance text searches across files on your system.526774MIT
- AlicenseNot gradedqualityDmaintenanceA server implementation that exposes grep functionality through the Model Context Protocol, allowing MCP-compatible clients to search for patterns in files using regular expressions.24GPL 3.0
- AlicenseBqualityDmaintenanceProvides powerful text search capabilities using the grep command-line utility, allowing users to search files and directories using both natural language descriptions and regex patterns.5337MIT
- AlicenseNot gradedqualityDmaintenanceEnables searching text across configured local workspaces using ripgrep. Provides secure text search capabilities within defined workspace boundaries through both MCP server and CLI interfaces.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AnthonyRuffino/greply-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server