Which search endpoint?
Four ways to search, and how to pick one.
Redpine Connect has four ways to run a search. They share the same retrieval pipeline underneath; what differs is when you pay, how many rounds it runs, and whether it's code or an agent driving it.
| Billed | Rounds | In the SDKs | Best when | |
|---|---|---|---|---|
SearchPOST /search/query | Always, win or lose | One pass | search() | You already trust the query and just want results fast |
Preview and unlockPOST /search/preview + /unlock | Only what you unlock | One pass | preview() then unlock() | You want to see relevance and cost before committing to either |
Assisted searchPOST /search/assisted | Only delivered, verified results | Multiple, agent-planned | assisted_search() | The query is a real question, not a keyword string, and you want every result checked before it's billed |
MCPsearch / preview / confirm tools | Same as their REST equivalents | Depends which tool the agent picks | n/a | You're connecting an agent rather than writing HTTP calls yourself |
A few rules of thumb:
- Default to
/search/queryfor anything you're confident is a well-formed query against a known collection. It's the fastest path and the one every other option builds on. - Reach for preview and unlock while you're still exploring: testing a new query shape, unsure if a filter is too narrow, or want to see the price before spending on a large
limit. - Reach for assisted search when the input is closer to a question than a query, and getting a wrong result is worse than getting no result. It plans its own internal searches and verifies each candidate before charging for it.
- MCP isn't a fifth option: it's the same three REST behaviors (
search,preview,confirm) reached through tool calls instead of HTTP requests, for agents that speak MCP. Nothing about billing or retrieval quality changes.
Was this page helpful?