Local-First Search Is Becoming Agent Infrastructure
Coding agents do not usually fail because they cannot edit files. They fail earlier, when they cannot find the right file, symbol, behavior, or migration path before the context window fills up.
That is why the September 2 release of zg, also called zvec-grep, is worth watching. The Qwen Developer team open-sourced a local-first search layer that combines ripgrep, BM25, and vector search behind one interface. More interesting for AgentNDX readers: it includes an MCP surface for coding agents.
This is not just another repo search tool. It points at a pattern that is becoming hard to ignore. Agents need retrieval systems that understand both exact code and fuzzy intent, and they need those systems close to the workspace.
The problem is not search. It is search under an agent budget.
Humans can afford messy search loops. We try one term, scan a few files, change the query, jump into the IDE, and build a mental map as we go.
Agents pay for that same loop in tool calls, tokens, latency, and bad guesses. If an agent searches for the wrong identifier three times, reads two full files, and then patches the wrong abstraction, the final diff may look like a coding problem. The real failure happened during retrieval.
Traditional code search handles known strings well. ripgrep is excellent when the agent knows the symbol, route, filename, or error text. But many real tasks start with intent, not a string: “find where onboarding emails are scheduled,” “locate the retry policy for payment webhooks,” or “change the component that renders the empty dashboard state.” Keyword search can miss those because the code may not use the same words as the task.
Vector search helps with that intent gap, but pure semantic search can be too loose for code. It may find something conceptually related while missing the exact caller or file that has to change. BM25 helps with lexical relevance. ripgrep handles literal certainty. The useful move is putting those routes together and letting the agent choose the right path.
What zg ships
The public launch describes zg as an Apache 2.0, npm-installable tool under the zvec-ai organization. It requires Node.js 22 or newer, runs on macOS, Linux, and Windows, and does not need a GPU with its default local embedding model.
The architecture is simple enough to understand:
- Index the workspace once.
- Query it through hybrid search, BM25 full-text search, vector search, or raw ripgrep.
- Return compact results grouped by file and line span.
- Keep the index local by default.
The MCP piece is the part that matters here. The launch notes that zg install detects Codex, Claude Code, Cursor, and OpenCode, then wires up a loopback MCP server at http://127.0.0.1:7999/mcp. The default agent toolset exposes two tools: one for intent-based search and one for literal or regex search.
That restraint is good design. A search server does not need to hand an agent ten lifecycle tools by default. Index creation, rebuilds, drops, and status checks are operational actions. Keeping them in the CLI reduces the chance that an agent silently rebuilds or deletes a persistent index while trying to answer a coding question.
Why local-first matters
A lot of agent infrastructure is moving remote: hosted MCP servers, cloud sandboxes, browser sessions, managed queues, and remote memory stores. That makes sense for many workflows. But source code search has different pressure.
Repositories often contain secrets, customer logic, private roadmap clues, and half-built work. Shipping all of that to a remote embedding provider should not be the default path. Even when it is allowed, it changes the trust model.
zg’s model is local-first. The index lives inside the workspace. Embeddings run on-device by default. Remote embedding options exist, but the launch describes explicit authorization gates for remote use. That is the right posture for coding-agent tools: local unless the developer makes a conscious exception.
This fits the broader MCP direction. Remote servers are getting better for production services, and Streamable HTTP is becoming the normal shape for hosted integrations. Local servers still matter when the resource is the developer’s machine, private repo, shell, or editor state. The likely future is mixed: remote MCP for cloud systems, local MCP for workspace context.
AgentNDX already tracks that split across servers like AgentNDX, GitHub MCP, Playwright MCP, and Docker MCP. Search belongs in that same infrastructure layer. It is not a side utility once the caller is an autonomous agent.
The benchmark claim to watch
The launch post reports large reductions in tool calls and input tokens on small benchmark samples when zg is added to an agent workflow. The reported numbers are directionally plausible: better retrieval should cut wandering. But the samples are still small, and the results come from the vendor’s own runs.
So the useful takeaway is not “zg solved code search.” It is narrower and more important: retrieval quality is measurable in agent economics. Tool calls, input tokens, wall-clock time, and patch accuracy are now product metrics for developer tools.
That changes how teams should evaluate MCP servers for coding work. A server that exposes twenty tools may look powerful in a directory listing. A server that helps the agent find the right three lines faster may save more time in practice.
What builders should copy
Even if zg never becomes the standard local search layer, its shape is a useful blueprint.
First, expose a small agent-facing surface. Agents do better with clear tools than with giant menus. If the main use case is search, two or three search tools may be enough.
Second, separate agent actions from admin actions. Creating, rebuilding, and deleting persistent indexes should not be casual model decisions. Put those behind explicit CLI commands, approvals, or separate toolsets.
Third, return compact output. A coding agent does not need a full file dump when it asked for likely locations. File paths, line spans, small previews, and freshness flags are better default context.
Fourth, support both exact and semantic retrieval. Codebases are half language and half structure. Good agent search needs both.
That same pattern applies outside code. Documentation servers, knowledge-base servers, issue trackers, and CRM servers all face the same problem: agents need to find the right slice before they can act well. See what MCP tools are and what MCP resources are for the underlying primitives.
What this means for MCP directories
Directories should not only ask whether a server exists. They should ask what kind of agent behavior it enables.
For search tools, the important metadata is not just install command and transport. Developers need to know whether indexing is local or remote, whether embeddings leave the machine, how results are compressed, whether the server supports exact search, and which actions the agent can take without approval.
That is where MCP discovery is heading. As the number of servers grows, the question changes from “can my agent call this API?” to “can my agent safely use this tool without wasting context or taking actions it should not take?”
Local-first search is one of the first places that question becomes concrete.
FAQ
Q: Is zg an MCP server? A: It is a local-first search tool with an MCP interface. The launch describes a loopback Streamable HTTP MCP server that coding agents can use for search.
Q: Why not just use ripgrep? A: ripgrep is still the right tool when the agent knows the exact string, symbol, path, or regex. The gap is intent-based search, where the task describes behavior but not the exact code terms.
Q: Should code search run locally or remotely? A: Local should be the default for private repositories. Remote embeddings can be useful, but they need explicit authorization because source code often contains sensitive business context.
Q: What should MCP builders learn from this release? A: Keep agent tool surfaces small, separate admin actions from task actions, return compact results, and measure whether the tool reduces tokens, calls, and mistakes.