MCP grep results appear partial vs native grep (need exhaustive mode for drop-in routing)

[light-merlin-dark]

Summary

When using fff-mcp grep as a backend for a grep -R -n --fixed-strings workflow, results can be ranked/partial rather than exhaustive vs native grep for the same target subdirectory.

Environment

• fff.nvim repo: main (as of 2026-04-10)
• install path: fff-mcp via install-fff-mcp.sh
• macOS host

Repro (real monorepo case, sanitized)

API_SRC=apps/api/src
WEB_SRC=apps/web/src

# run from repo root
/usr/bin/grep -R -n --fixed-strings TODO "$API_SRC" | wc -l
/usr/bin/grep -R -n --fixed-strings TODO "$WEB_SRC" | wc -l

# fff-backed path (wrapper -> fff-mcp grep)
NCR_ENABLE_FFF_GREP=1 grep -R -n --fixed-strings TODO "$API_SRC" | wc -l
NCR_ENABLE_FFF_GREP=1 grep -R -n --fixed-strings TODO "$WEB_SRC" | wc -l

Observed in one repo:

• API native: 14
• API fff-backed: 6
• Web native: 4
• Web fff-backed: 2

Minimal synthetic repro (public-safe)

ROOT="$(mktemp -d)"
mkdir -p "$ROOT"/apps/api/src "$ROOT"/apps/web/src "$ROOT"/docs "$ROOT"/scripts
cd "$ROOT"
git init

# 14 TODOs in api target path
for i in $(seq 1 14); do echo "export const a$i = 'TODO api $i'" >> apps/api/src/api.ts; done
# 4 TODOs in web target path
for i in $(seq 1 4); do echo "export const w$i = 'TODO web $i'" >> apps/web/src/web.ts; done
# noise outside target paths
for i in $(seq 1 80); do echo "TODO doc $i" >> docs/readme.md; done
for i in $(seq 1 80); do echo "echo TODO script $i" >> scripts/build.sh; done

git add . && git commit -m "seed"

/usr/bin/grep -R -n --fixed-strings TODO apps/api/src | wc -l
# expected: 14

# helper call used by wrapper
node ~/.local/share/ncr/bin/grep-fff-helper.mjs --path "$ROOT/apps/api/src" --query TODO --line-number 1 | wc -l
# observed here: 10 (lines 11-14 missing)

Why this matters

For command-router use cases, grep compatibility requires shape + completeness parity for supported forms.

If FFF is intentionally ranked/preview-oriented, that is useful for AI workflows, but wrappers need an explicit exhaustive contract/mode before using it as a default native backend.

Request

Would you consider adding one of these:

1. An explicit exhaustive grep mode for MCP/tool calls (native-like completeness), or
2. Tool metadata/options that clearly distinguish ranked/preview vs exhaustive, including paging semantics and termination guarantees.

Happy to test a proposed flag/contract and report back with parity checks.

[dmtrKovalenko]

I do not understand what are this numbers from

Observed counts:

API native: 14
API fff-backed: 6
Web native: 4
Web fff-backed: 2

Can you provide the repo & query you used to see that grep didn't find something

• fff relies on the pagination is your AI agent is requested first 5 occurances we will return first at least 5 occurances (could be 6) but this is by design

---

if you observed that fff couldn't find some values which grep can this is a very criticl issue and please give me a way to repro this

[light-merlin-dark]

Okay, got it. I isolated the behavior into a public repro:

https://github.com/light-merlin-dark/fff-grep-repro

It compares native grep -R -n --fixed-strings directly against raw fff-mcp over JSON-RPC.

Repro:

git clone https://github.com/light-merlin-dark/fff-grep-repro.git
cd fff-grep-repro
node scripts/run-repro.mjs

What it shows locally on macOS:

• Single-file completeness: native grep returns 14, raw fff-mcp returns 10, with lines 11..14 missing from src/api.ts.
• Path scoping: native grep under apps/api/src returns 14, raw fff-mcp returns 34 total matches, but only 10 are within apps/api/src.
• Raw fff-mcp also returns files outside the requested base path: apps/web/src/web.ts, docs/readme.md, scripts/build.sh.
• In both repro cases, no cursor is exposed, so this does not appear to be just a pagination-loop bug on our side.

MCP behavior itself appears to be non-exhaustive within a file and non-scoped to the requested base path for this native-grep style use case.

I'm creating tooling called "Native Command Router" where I want to use FFF as an optimization backend when behavior is compatible:

https://github.com/light-merlin-dark/native-command-router

Thanks again for such a wonderful tool! fff is lightning fast!! ⚡️

Merlin (@EnchantedRobot on X) & ChatGPT 5.4 via Codex

[gustav-fff]

[triage-bot] FEATURE REQUEST: confirmed limitation, but out of scope for autonomous fix.

Root cause of partial results: crates/fff-mcp/src/server.rs:69 hardcodes max_matches_per_file: 10 in make_grep_options. Cursor paginates by file_offset only (crates/fff-core/src/grep.rs:345), so matches 11..N within one file are unreachable via paging. This is by design for AI/preview workflows — fff-mcp is not a drop-in grep -R substitute.

Out-of-path results in your second repro come from fff not honoring a base-path constraint at the MCP boundary — fff-mcp searches the whole indexed picker root. Path scoping requires a glob constraint (apps/api/src/**) in the query string, not a separate parameter.

Adding an exhaustive mode is a new tool surface (matches/file uncapped, cursor over matches not files, base-path parameter). Per repo policy that is maintainer scope, not a bot fix. @dmtrKovalenko — flagging for design.

Workaround for current behavior: pass file constraint in query (e.g. TODO apps/api/src/) and increase maxResults; per-file 10-match cap still applies.