Search Transports: GraphQL vs MCP — Consolidation Analysis

1. The actual call graph

There are three consumers of search, not two:

Surface	Entry point	Engine used
GraphQL search(input:)	internal/graph/schema.resolvers.go:3205-3207	sitesearch.Resolve — literally one line
HTML /search?q= page	internal/case/rendersearchpage/endpoint.go:35	sitesearch.Resolve (64-line endpoint, Env = sitesearch.Env)
MCP search tool	internal/case/mcp/resolve.go:489 (handleSearch)	its own pipeline, not sitesearch

Also: GraphQL notePaths(filter:{search}) reuses the Search resolver (schema.resolvers.go:3230), so GraphQL search has a second internal consumer.

2. What the frontend actually uses

Public site search is the $mol island $trip2g_user_search, mounted by the default template (internal/defaulttemplate/views.html:421-423). It fires the GraphQL query SiteSearch per keystroke (1s debounce, min 3 chars) via $trip2g_graphql_request and renders highlightedTitle / highlightedContent — HTML <mark> fragments from bleve (assets/ui/user/search/search.view.ts:2-14,56-76). Anonymous visitors work because GraphQL search needs no auth (CurrentUserToken handles anonymous; permission filtering is per-note).

Switching this widget to the MCP endpoint would require:

• a JSON-RPC 2.0 client in the template bundle (MCP is same-origin, so CORS is a non-issue, and anonymous MCP access exists — internal/case/mcp/endpoint.go:150-154);
• losing HTML match highlighting (MCP returns plain snippets — by design, agents must not get injectable remote HTML);
• losing the "closed material" placeholder UX and the live/latest draft logic;
• keeping GraphQL search anyway for notePaths(filter:{search}) and the /search HTML page — so nothing gets deleted.

3. Options

(a) Frontend → MCP, remove GraphQL search. Worst of all worlds. The MCP pipeline is the less correct of the two (always-latest corpus, no dim guard); the frontend loses highlighting and hidden-result UX; a JSON-RPC client must be added to the visitor bundle; notePaths and /search still need the engine so no code is deleted; and it contradicts the federated-search design (docs/dev/federated_search_ui.md), which — written today — proposes a new federatedSearch GraphQL query as the human-visitor transport. Effort: days. Value: negative.

(b) Status quo. Zero immediate effort, but the "two thin transports" framing is false — it is two engines, and they have already drifted (table above). Every retrieval improvement (reranker tuning, RRF changes, embedding-model migration) must be applied twice or silently applies once.

(c) Inverse consolidation — one engine, two thin adapters. Extract the candidate-generation pipeline (text lane + vector lane + RRF + BlendRRF rerank) into a single shared function; sitesearch.Resolve keeps its permission/placeholder/output logic on top, and MCP handleSearch calls the same engine then applies canReadMCPNote + buildSearchPayload. The transport-specific parts (GraphQL types with HTML highlighting vs MCP match_id/toc_path payload; session auth vs API-key/federation auth) are legitimately different and stay. Fold in the latest/live fix: anonymous MCP should search live notes like the site does; API-key/admin keeps latest.

4. Recommendation

Option (c). The owner's self-correction was directionally right but factually optimistic — the internals are not shared today, and that is precisely the problem worth fixing. Removing GraphQL search solves nothing (the engine must survive for /search and notePaths, and the fed-search UI plan builds on GraphQL), while unifying the retrieval core removes ~200 duplicated lines from internal/case/mcp, closes the dot/cosine and dim-guard drift, and gives the federated-search work a single engine to call. This also matches the in-flight internal/fedsearch extraction proposed in docs/dev/federated_search_ui.md §3 — the same service-package move, one layer down.

Migration sketch (0.5–1 day):

1. Extract retrieve(ctx, env, query, useLatest) ([]model.SearchResult, passageByURL, error) — the text+vector+RRF+rerank core — from sitesearch (either exported from sitesearch or a new internal/search service package per the gitapi pattern). sitesearch.Env already declares everything it needs.
2. sitesearch.Resolve becomes: corpus choice → retrieve → scope/permission filter → placeholders → caps. (Mostly unchanged.)
3. MCP handleSearch becomes: corpus choice (mcpAPIKeyAuthed → latest, else live) → retrieve → filterSearchResults → buildSearchPayload. Delete mcp copies of vectorSearch, vectorResultsFromChunks, mergeResults, snippetFromChunk, chunkPassage, trimWhitespace, lastIndexByte, cosineSimilarity (resolve.go:1216-1421).
4. Keep both transports' contract tests; add one test asserting both surfaces rank identically for the same query/corpus.

Trade-offs of (c): the shared engine gains a useLatest parameter and both callers' expectations become coupled — a retrieval change now affects agents and visitors simultaneously (that is the point, but it means rerank experiments hit both surfaces; if a surface ever needs different retrieval behavior, add an options struct, don't re-fork). The latest→live change for anonymous MCP is a user-visible behavior change for agent clients on draft-showing sites; it should be called out in the changelog.

References

• internal/case/sitesearch/resolve.go:50 — the site engine (text+vector+RRF+rerank+ACL)
• internal/graph/schema.resolvers.go:3205 — GraphQL wrapper (1 line)
• internal/graph/schema.resolvers.go:3230 — notePaths(search:) reuses it
• internal/case/rendersearchpage/endpoint.go:35 — /search HTML page, third consumer
• internal/case/mcp/resolve.go:489 — MCP handleSearch, parallel pipeline
• internal/case/mcp/resolve.go:1216-1421 — duplicated vector/RRF/snippet code
• internal/case/mcp/resolve.go:502,513 — MCP always-latest corpus
• assets/ui/user/search/search.view.ts:2 — frontend uses GraphQL search
• internal/defaulttemplate/views.html:421 — template mounts the widget
• docs/dev/federated_search_ui.md — in-flight design that extends GraphQL search