PGR is an experimental, stateless MCP code-search server for studying how ranking, latency, and output shaping affect agentic search.
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"pgr": {
"cwd": "/absolute/path/to/repo",
"command": "pgr"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
pgr is an experimental, stateless MCP server for code search, built as part of research into how coding agents search repositories.
No automated test available for this server. Check the GitHub README for setup instructions.
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
No package registry to scan.
Click any tool to inspect its schema.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in other
Pi Coding Agent extension (CLI-first) — routes bash/read/grep/find/ls through lean-ctx CLI for strong token savings. Optional MCP bridge can register advanced tools.
Autonomous spec-to-product coding-agent CLI with an MCP server exposing 34 tools over stdio.
97% token reduction for AI coding sessions — zero deps, 21 languages, MCP server
App framework, testing framework, and inspector for MCP Apps.
MCP Security Weekly
Get CVE alerts and security updates for Pgr and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.

pgr is an experimental, stateless MCP server for code search, built as part of
research into how coding agents search repositories.
It is a working prototype and public research artifact, not a polished product.
It wraps local code search with ranking and output shaping designed for agent workflows: surfacing likely implementation files earlier, de-prioritizing tests and low-value matches, and formatting results so a model can decide what to read next with less thrashing.
This repository also includes the public datasets, benchmark packages, and saved results used in the accompanying writeup on agentic code search.
Install pgr from this repository:
git clone https://github.com/entireio/pgr.git
cd pgr
cargo install --path .
Then add it to any MCP client that can launch a stdio server:
{
"mcpServers": {
"pgr": {
"command": "pgr",
"cwd": "/absolute/path/to/repo"
}
}
}
Set cwd to the repository you want your agent to search. pgr searches the
current working directory of the process that launches it.
Once configured, ask your agent to search the repo. For example:
search for where checkpoint commits are written
find the code that handles MCP tool calls
If pgr is not yet on your shell PATH after install, use the binary directly
at:
~/.cargo/bin/pgr
pgr is not trying to replace ripgrep. It shells out to local rg for fast
content search and file listing, then ranks and shapes the results for coding
agents.
That means an agent is more likely to see implementation files before test noise, repeated references, or lower-signal matches.
At a high level it provides tools for:
search_coderead_codefind_fileslist_dirThe search output profile is controlled with PGR_OUTPUT_PROFILE. If it is
unset, the server defaults to the richer planner-oriented output profile used in
the public results.
There is no index to build, no background daemon, and no separate storage layer.
pgr starts, answers MCP tool calls over stdio, and exits when the client stops
it.
cargo build --release
The binary will be available at target/release/pgr.
If you want the binary on your PATH, you can also install it locally with:
cargo install --path .
For most first-time users, this is the easiest way to try pgr.
ripgrep installed and available as
rgpgr shells out to local rg for both content search and file listing. If rg
is not installed, pgr will not be able to search.
pgr is built around a simple idea: faster search alone is not enough. What
matters just as much is whether the search result helps the model choose a
better next action.
In the public benchmarks in this repository, the strongest effects did not come from raw scan speed. They showed up in more local agent behavior:
That is the problem pgr is designed to improve.
The public artifacts referenced in the writeup live under
public_release/.
Key packages: