Problem A — Most-used search tools have no path scoping. pattern_search only has glob (unintuitive for directories, ripgrep still walks the entire tree so no performance gain). search_code has nothing at all. Meanwhile, low-frequency tools like dead_code (scope) and list_todos (path_filter) already support it.
Why this is a problem: Without path scoping, every search returns results from the entire project. In a project with 2000+ files, searching for handleClick in src/auth/ returns hits from src/auth/, tests/auth/, docs/, README.md, etc. — often 80+ hits across 24 files when only 3 matter. This wastes tokens (AI must read and filter noise), increases latency, and degrades answer quality (the agent may focus on the wrong file simply because it appeared first in results). For search_code there is no workaround at all; for pattern_search, glob="src/**" partially works but is fragile and non-obvious.
Problem B — Path parameters are named inconsistently. The same concept ("limit to a path") uses 6 different names: path / file / target / file_filter / scope / path_filter.
Why this is a problem: AI agents must memorize or look up the correct parameter name for each tool. In practice, they frequently guess wrong — passing path to outline (which expects file), or file_filter to find_references (which has no such param, silently ignored per Issue 1). This produces either errors (wasting a round-trip) or silent misbehavior, both of which degrade reliability.
Proposed:
- Add path parameter to pattern_search and search_code
- Standardize naming convention: path for primary file input, path_filter for optional result filtering
Problem A — Most-used search tools have no path scoping. pattern_search only has glob (unintuitive for directories, ripgrep still walks the entire tree so no performance gain). search_code has nothing at all. Meanwhile, low-frequency tools like dead_code (scope) and list_todos (path_filter) already support it.
Why this is a problem: Without path scoping, every search returns results from the entire project. In a project with 2000+ files, searching for handleClick in src/auth/ returns hits from src/auth/, tests/auth/, docs/, README.md, etc. — often 80+ hits across 24 files when only 3 matter. This wastes tokens (AI must read and filter noise), increases latency, and degrades answer quality (the agent may focus on the wrong file simply because it appeared first in results). For search_code there is no workaround at all; for pattern_search, glob="src/**" partially works but is fragile and non-obvious.
Problem B — Path parameters are named inconsistently. The same concept ("limit to a path") uses 6 different names: path / file / target / file_filter / scope / path_filter.
Why this is a problem: AI agents must memorize or look up the correct parameter name for each tool. In practice, they frequently guess wrong — passing path to outline (which expects file), or file_filter to find_references (which has no such param, silently ignored per Issue 1). This produces either errors (wasting a round-trip) or silent misbehavior, both of which degrade reliability.
Proposed: