The search result promises table export. The manual only mentions table import. An AI can fluently combine the two words into a convincing answer even though the crucial function remains unsupported by any evidence. It is at precisely this inconspicuous point that a research application proves whether it really helps: at the step from a link that has been found to a source that has been read.
According to its change log of 17 October 2026, DeepSeek opened its search interfaces to developers. The guide to Search and Fetch separates structured search results from retrieving a single web page as Markdown. This makes an important division of labour explicitly programmable.
Two calls, two kinds of knowledge
A search result is, to begin with, a pointer to where something might be found. Title, address and summary help you choose. The retrieved page content is the material against which the specific claim can be checked. Even this is not automatically a true answer: a page may be out of date, describe a different pricing plan or contain important limitations.
For an agent, an intermediate state is therefore worthwhile. It should neither mark a candidate it has found as confirmed straight away nor simply let it vanish into the next prompt. Instead, store the question, the source passage and the verification status separately. That way you can later explain why a result was discarded or a statement was worded more narrowly.
An experiment you can run, with a known expected answer
As a manageable start, you can research the interface using its own documentation: which number of results does Search use if count is missing? The guide, once opened, gives ten as the default. That gives you a target value from an original source without having to judge an unknown product feature.
Search with the question and a restriction to api-docs.deepseek.com. Choose a suitable original result, then retrieve it with Fetch and look in the content for the description of the count field. Read the neighbouring details too: the default value and the permitted range of values answer different questions. Record the specific passage instead of merely attaching the general start address.
For the first run you do not need a complex agent loop. You can carry out the calls documented in the guide one at a time and compare their results deliberately. Access and any charges are a matter for the external provider. This article describes the experiment; no such API run was carried out for this version.
An evidence card instead of a decorative source link
A research application of your own could, for example, store the verified state like this. The values are an explanatory data schema, not an API response generated here:
{
"frage": "Which count applies if none is given?",
"quelle": "https://api-docs.deepseek.com/guides/search/",
"gepruefter_wert": 10,
"status": "an_originalquelle_zu_pruefen",
"einschraenkung": "The default is not the maximum value"
}In an actual implementation, add the retrieval date and a short text passage. Then change the test question: what is the maximum number of results that may be requested? The same paragraph contains other details, and the answer must change accordingly. If the AI sticks with ten, it may simply have reused the previous answer.
This second pass tests an interesting property: can the process really tie the statement to the question? A neat block of sources on its own does not show this. Nor is a matching page title enough if the crucial passage does not appear in the retrieved content at all.
When the chain of evidence breaks
A result that cannot be retrieved remains unverified. A page without the passage you are looking for remains insufficient. Two contradictory versions call for clarification of which version applies. These states should exist in the data model so that the agent can name them instead of producing a smooth answer from missing material.
Also treat third-party page content as source material. If it contains instructions to an assistant, these do not change the original research task. The next action follows from your task and the tools you have permitted.
The real progress therefore lies in a visible chain: ask the question, find a candidate, read the content, limit the statement. DeepSeek’s interfaces provide two building blocks for this. How robust the result is depends on the link between them.
Sources and status
Sources as of 25 October 2026. DeepSeek Change Log — 2026-10-17 · Search & Fetch.
