feat: add content filter to MCP - #247
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
🚀 New features to boost your workflow:
|
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Reviews (2): Last reviewed commit: "refactor: build MCP content indexes lazi..." | Re-trigger Greptile |
stephantul
left a comment
There was a problem hiding this comment.
Two small and speculative comments, but looks good to me otherwise regardless, thanks!
| """Find an exact content index in the cache for a project path.""" | ||
| cache_dir = resolve_cache_folder() / cache_key(path) | ||
| return cache_dir / "index" | ||
| scope = "-".join(content_type.value for content_type in ContentType if content_type in content) |
There was a problem hiding this comment.
Maybe a sort would be safer here. I can imagine us adding things which might change the Enum order. (I think Enums are safely sortable though).
There was a problem hiding this comment.
Oh yeah that's a bit nicer, willdo
|
|
||
| _CACHE_MAX_SIZE = 10 # Max number of cached indexes to keep in memory | ||
| _MIN_REVALIDATE_FACTOR = 3 # Don't recheck staleness sooner than this many times the last build's duration | ||
| ContentSelection = Literal["code", "docs", "config", "all"] |
There was a problem hiding this comment.
Can this be derived from the Enum? Not sure if it makes sense to do so.
There was a problem hiding this comment.
Yeah I thought about this but the answer is... not really, because the type would need to be a union of ContentType and the new "all", but we also cannot add "all" to contentype because it's not a contenttype.
This PR adds a
contentargument to MCP, just like the CLI, resolving #246. Searches still default to code. When docs, config, or all is explicitly requested, the MCP lazily builds an index containing exactly that content and caches it separately for reuse. This avoids making the default indexing path slower or unexpectedly indexing large non-code files.