{"path":"/guide/reading/search","content":{"title":"Search and browse","summary":"Use the public discovery tools and understand the underlying search choices.","breadcrumbs":"[Everything guide](/guide) / [Finding and reading](/guide/reading)","body":"Use [Search](/search) for a question or topic, and [Browse](/browse) to explore published pages without a query. MCP offers the same public discovery through `search_pages` and `list_pages`, with optional page-type or collection filters.\n\nThe website Search and simple MCP `search_pages` tool use wf-store's **Auto** policy: semantic and lexical retrieval with bounded exact evidence. Advanced MCP passage search also offers explicit modes and policy-scoped Boolean tag filters, as described below.\n\nAt the underlying service level, Exact means a literal string and Semantic matches meaning. Lexical requires every distinct normalized query term in the same rendition chunk and ranks those matches with BM25. Common words remain part of the query. Hybrid composes semantic and lexical evidence. See [Search families and tradeoffs](/guide/how-it-works/wf-store/search-families) for the distinction.\n\nDiscovery is bounded. A batch may contain fewer pages than requested after outdated or ineligible hits are removed, while still returning a continuation. Continue with the same inputs and the returned opaque cursor; do not invent or edit it.\n\nFresh uploads need ingestion and publication visibility before discovery can find them. If readiness is explicitly false, wait or inspect a specific asset rather than issuing a rapid series of searches.\n\n## Advanced searches from an agent\n\nThe simple tools remain available. Call `retrieval_capabilities` to discover the advanced public tools and their limits:\n\n- `search_chunks` searches passages using **Auto**, **Hybrid**, **Semantic**, **Lexical**, or literal **Exact** matching. Auto is the general default; Lexical suits terminology, Semantic suits paraphrases, and Exact suits a specific phrase or identifier. Exact is not regular-expression search.\n- `select_pages` explores published metadata without a text query or query embedding. It accepts Boolean tag filters and supported facet comparisons/order.\n- `get_page_chunks` reads a bounded passage or its neighbouring text from a public page, without fetching a large source document.\n\nFor example, a small terminology search within this guide topic:\n\n```json\n{\"query\":\"consistency\",\"mode\":\"lexical\",\"collection\":\"about-everything\",\"limit\":8}\n```\n\nUse the actual tags returned with public results. Boolean filters use `{\"op\":\"tag\",\"value\":\"exact:tag\"}`, `and`/`or` with an `args` list, and `not` with an `arg`. Colon-separated tags are exact strings, not implicit prefixes. Facets belong to selection, not text search: if pages carry tags such as `year:1885`, a selection can compare facet `year` as a string. There is no automatic numeric/date coercion.\n\nAdvanced search returns an ordered chunk stream, so one article may have several useful hits. Each result's `asset_ref` identifies an entry in `assets`, containing its canonical link, tags and display information. Use that entry's `revision_ref` and matching `path` with `get_page_chunks`, plus the hit's ordinal, to inspect context. Coordinates are UTF-8 bytes in the search rendition, not necessarily positions in an original binary document. A snippet is a preview, not the whole article or a precise Semantic highlight.\n\nContinue a returned search/selection cursor with the **same inputs**, including mode, filters, ordering, page size and options. A short or empty filtered batch may still have another page. Advanced chunk traversal has no fixed 20-page/100-result walk ceiling, although request sizes, work bounds and cursor expiry still apply. An ended bounded ranked stream does not establish corpus-wide absence.\n\n**Filtered Exact is the current exception:** public Exact searches require publication filters and have no continuation. Too many literal matches return `too_large`; narrow the pattern or filters, or deliberately choose another mode. The service does not silently switch modes or pretend a truncated prefix is complete.\n\nThe website Search and simple page-card tools retain their existing behavior. Advanced tools do not grant access to private drafts or arbitrary storage assets. If your client cached an older tool list, refresh its server tools or reconnect before trying the new names.\n\n## Search in the site and in a template\n\n**Search** in the title bar opens this built-in discovery view; **Explore** opens Browse. Search forms participate in the site's [progressive navigation](/guide/reading/navigation-and-loading), so the shell stays available while results load.\n\nThe guide's **On a related note** panel is different: its template queries a prefix of the page summary using one bounded **lexical** request, without query embeddings. It displays up to three other eligible pages and may return a short batch without refilling. See [Search inside templates](/guide/templates/inline-search). Curated **Guide links** come directly from content, not a search.\n\nMCP's `get_related_pages` is another interface: it uses collection membership, otherwise page type. Do not assume it returns the same ranking as the lexical sidebar or the full auto Search page.\n\n## Topics and enriched results\n\nUse [the guide topic](/browse?collection=about-everything), or pass `collection=about-everything` to public search/list MCP tools. Search consumes pre-enriched metadata/text in **one wf-store call**, with local filtering and deduplication rather than per-result lookups. A related sidebar uses source selection plus one lexical query. Stale result metadata is tolerated; a newly opened route can show a newer page.\n\n## Incomplete results and restarting\n\nSearch can return useful results while reporting incomplete coverage. When too many recent assets or chunks exceed the bounded semantic pending tail (32 assets or 2,048 chunks), wf-store uses the allowed portion and returns degradation notices instead of failing the entire search. The website shows an incomplete-results notice; MCP preserves safe `degradations`, `partial` and `message` fields. A short filtered batch alone is not proof of a backend failure.\n\nLexical traversal is a separate limit from indexing lag. Inspect `families.lexical.traversal.complete`: `false` means the engine searched a bounded subset and may have omitted better matches, even if the index is fully caught up. Matching still requires all query terms in one chunk. Incomplete zero-hit results do **not** prove absence; narrow with more specific terms. Safe traversal reasons and `query_semantics: strict-and-bm25-v1` explain this behavior without exposing storage internals.\n\nWhen a traversal-limited response supplies a cursor, continue it with identical inputs to page through the **same fixed searched subset**. Paging does not expand coverage or recover omitted material. Read `partial`, `degradations`, the traversal fields and `message` together. Do not invent a cursor or treat the end of an incomplete stream as exhaustive.\n\nSemantic pending-tail limits and supported transient-service degradations still suppress continuation. Read the available results, then start a fresh search after indexing or the dependency recovers, or narrow the request; do not poll rapidly. A fresh Auto or Hybrid query can keep useful results from one ranked family when the other's initial worker call has a supported transient failure. Invalid requests, authorization failures, unusable required state and unsupported or late failures remain errors. If any cursor expires or is rejected, restart without it.","navigation":"[Everything guide](/guide) · Section: [Finding and reading](/guide/reading) · Previous: [Finding and reading](/guide/reading) · Next: [How public visibility works](/guide/reading/visibility)","related":[{"title":"How public visibility works","url":"/guide/reading/visibility"},{"title":"Ingestion and search readiness","url":"/guide/how-it-works/wf-store/readiness"}]}}