search_documents is the qualitative tool. Your assistant hands it a question in plain language, and it
searches research, news, and curated sources for the documents relevant to that question, then returns the
documents themselves.
It retrieves; it does not write the answer. Your assistant reads the documents and answers from them. That is
why a result is a document set rather than a paragraph, and why you can always ask which document a claim rests on.
Reach for it when the answer is written down somewhere rather than sitting in a table: what a protocol does, what
changed in a launch, how an event played out, what has been published on a theme.
What comes back
sources holds the retrieved documents. Each one carries:
error is set only when a run finds no usable document, and explains why.
Because url and published_at travel with every document, you can ask your assistant to cite what it used and
verify an answer is grounded in a real source rather than in the model’s own knowledge.
Example queries
Phrase these to your assistant directly, and it decides to call the tool.Concepts and protocols
News and events
Market and sector coverage
Best practices
- Ask one thing at a time. Several focused searches usually beat one loaded question.
- Name the entity precisely. “Uniswap v4” and “Uniswap” pull different documents.
- Ask for sources. Requesting the URLs makes it obvious which documents an answer rests on.
When to use something else
- You want a number that is true right now, such as a price, a ranking, or a TVL figure. Use the tabular tools.
- You want a numeric series at a stated granularity over an exact window. Use the timeseries tools.
Which sources your key can reach follows its entitlements. If a search comes back thin, the material may sit
outside what your key covers rather than outside the platform.