1d ago
MCP oddities
I'm no expert, so not filing in GitHub.
Claude will occasionally tell me the NotePlan MCP is not available, and restarting NotePlan fixes that. But much more often it will fail to search when a note is large. About this, Claude says:
```
When noteplan_search can't find ripgrep, it falls back to a simple local search. That fallback appears to silently fail on large notes — returning count: 0 and an empty results array even when the search terms are definitely present in the content.
The response includes a warning ("ripgrep unavailable; using fallback local search") buried in a warnings array, but the top-level success field is still true and count is 0. From the caller's perspective it looks like a successful search that found nothing, not a degraded search that couldn't find anything.
To reproduce
Run noteplan_search with a query that matches content in a large note (100+ KB).
Observe: success: true, count: 0, results: [], with warnings: ["ripgrep unavailable; using fallback local search"].
The content is present — searching manually confirms it.
Expected behavior
Either:
The fallback search should actually work on large notes, or
The response should make the degradation unambiguous — e.g. set success: false, or surface the warning at a level that forces the caller to handle it explicitly, rather than burying it in a warnings array alongside a count: 0 that looks like "no results."
Silent false negatives are harder to debug than explicit errors.
Context
Note size: ~242 KB (a long-running project log)
Search terms were definitely present (confirmed by reading the note directly)
MCP server version: whatever ships with the current Cowork/Claude desktop integration
```
This is on
NotePlan 3.21.1
Claude for Mac 2.2553.1
MacOS 26.6.2
Pending