Search API returns empty results for most thoughts in a 9K+ thought brain

[lonniev]

Summary

I'm building an MCP server that wraps TheBrain's REST API for use with AI assistants. The search endpoints (/search/{brainId} and the nameExact query parameter on /thoughts/{brainId}) return empty results for the vast majority of thoughts in my brain, including thoughts that are clearly accessible via other endpoints like /thoughts/{brainId}/{thoughtId}/graph.

My brain has 9,284 thoughts accumulated over many years, but search finds fewer than a dozen of them.

What We Tried

1. Full-text search (GET /search/{brainId})

GET /search/{brainId}?queryText=Claude&maxResults=5&onlySearchThoughtNames=false
→ 200 OK, body: []

GET /search/{brainId}?queryText=Social&maxResults=5
→ 200 OK, body: []

GET /search/{brainId}?queryText=Personal&maxResults=5
→ 200 OK, body: []

GET /search/{brainId}?queryText=My&maxResults=5
→ 200 OK, body: []

All of these thought names exist and are accessible via get_thought_graph on the home thought. "Claude Thoughts", "Social Thoughts", "Personal Thoughts" are all direct children of the home thought.

2. Progressive prefix search

"C"       → 3 results (Company, Collection, and one other)
"Cl"      → 0 results
"Cla"     → 0 results
"Claude"  → 0 results
"Career"  → 1 result
"Thoughts"→ 2 results

Search works for single-character queries (returning a few older thoughts) but breaks as soon as the query gets more specific. The few results that do appear are from thoughts created in 2009 and last modified in 2014.

3. Exact name match (nameExact parameter)

GET /thoughts/{brainId}?nameExact=Company
→ 200 OK (thought from 2009, modified 2014 — works!)

GET /thoughts/{brainId}?nameExact=Collection
→ 200 OK (thought from 2009, modified 2014 — works!)

GET /thoughts/{brainId}?nameExact=Claude Thoughts
→ 404 Not Found (thought exists — accessible via graph!)

GET /thoughts/{brainId}?nameExact=Social Thoughts
→ 404 Not Found (thought exists — accessible via graph!)

nameExact works for the same small subset of thoughts that appear in search, and returns 404 for everything else — even though the thoughts provably exist.

4. Structured/comma-separated names

My brain uses a naming convention with comma-separated fields for certain thoughts, e.g.:

YYYY,Month,DD,City,State,EventType,PersonName

Searched for individual fragments from these names (person name, event type, city) — all return zero results. These thoughts are also invisible to nameExact.

5. What DOES work

• GET /thoughts/{brainId}/{thoughtId} — always works when you have the ID
• GET /thoughts/{brainId}/{thoughtId}/graph — always works, returns full connection graph
• GET /thoughts/{brainId}/types — returns all type thoughts
• GET /thoughts/{brainId}/tags — returns all tags
• GET /brains/{brainId}/statistics — correctly reports 9,284 thoughts

So the API can access all thoughts — only the search index appears incomplete.

Observed Pattern

Thought	Created	Modified	Found by search?	Found by nameExact?	Found by graph?
Company	2009	2014	Yes	Yes	Yes
Collection	2009	2014	Yes	Yes	Yes
Claude Thoughts	Recent	Recent	No	No	Yes
Social Thoughts	Recent	Recent	No	No	Yes
Personal Thoughts	Recent	Recent	No	No	Yes
Structured names	Various	Various	No	No	Yes

The search index appears to cover only a small subset of thoughts — possibly limited to what was synced to the cloud via the desktop client in a particular way, or only what was indexed before a certain date.

Current Workaround

We use get_types to find type anchor thoughts, then traverse the graph via get_thought_graph to discover thoughts. This works reliably but requires multiple API calls and doesn't support free-text search.

Suggestion

It would be tremendously helpful if the search endpoint could search against the actual brain content rather than (what appears to be) a partial cloud sync index. Specifically:

1. Full coverage: Every thought accessible via GET /thoughts/{brainId}/{thoughtId} should also be discoverable via search and nameExact
2. Index refresh: If there's a way to trigger a re-index of the brain's search index via the API (or even just documentation on what causes thoughts to be indexed), that would help
3. Structured name support: Thought names with commas, numbers, or other non-natural-language patterns should be searchable by their component parts

For programmatic access (MCP servers, integrations, automations), reliable search is essential. Graph traversal is a workable fallback but it's slow for large brains and doesn't support the "find by name" use case that users expect.

Environment

• API base URL: https://api.bra.in
• Brain size: 9,284 thoughts, 548 notes, 15 tags
• Client: Python/httpx
• Authentication: Bearer token (API key)

[lonniev]

Follow-up: Search index sync hypothesis

After further research, we believe the root cause may not be the REST API itself, but rather a stale cloud-side search index that the API depends on.

Evidence from TheBrain Forums

Search index reliability is a well-documented, longstanding issue across multiple TheBrain versions:

• Search Index Incomplete — Error appeared after connecting to web/cloud services, suggesting sync and indexing are coupled
• Brain 8 does not index new thought — Newly created thoughts invisible to search
• Search indexing isn't reliable — General reliability concerns
• Re-indexed downloaded brain does not show thoughts — Re-indexing doesn't always resolve the issue
• Rebuilding search index unsuccessful — Multiple rebuild attempts still leave search broken
• How often do I have to rebuild search index? and Frequency rebuilding the Brain Index — Users asking about rebuild frequency, implying the index degrades over time

Hypothesis

The search index appears to be a separate data structure from the brain content, maintained by the desktop client. The REST API's /search/ and nameExact endpoints seem to query the cloud-side copy of this index. If the local index is stale when synced — or if the cloud never fully re-indexes after sync — the API inherits the gap.

This would explain why:

• Direct thought access (/thoughts/{id}, /thoughts/{id}/graph) always works (reads live brain data)
• Search only finds a handful of older thoughts (the ones that were indexed when the desktop client last built a complete index)

Questions for the team

1. Does the REST API search query the same index that the desktop client builds locally? Or does the cloud maintain its own independent index?
2. Is there a way to trigger a cloud-side search re-index via the API or the web interface?
3. If rebuilding the local search index (File > Utilities > Rebuild) and then syncing to cloud would fix the API search, that would be a useful workaround to document.