Updated 2026-07-06
DeepSeek tool call Python example: start from the official sample, not from wrapper folklore
DeepSeek's official docs now publish a dedicated Python sample page for thinking-mode tool calls. That matters because it gives developers a first-party baseline for the exact payload shape, tool schema contract, and multi-step call loop before they add frameworks, agents, or retries. This page targets the concrete search intent behind queries like DeepSeek tool call example, DeepSeek function calling Python example, and DeepSeek thinking mode tool call sample.
1. What the official sample actually proves
The new sample is not just a toy weather demo. It proves that DeepSeek's official Python path for tool use still goes through the OpenAI-compatible client, keeps thinking mode active, and expects tools to be declared in the request rather than hidden in a wrapper.
The first-party value is operational clarity: you can see the model reason, call `get_date`, then call `get_weather` with the derived date. That makes the sample a better debugging baseline than generic function-calling blog posts that never show how the model progresses across multiple turns.
Sources checked
- DeepSeek official tool-call Python sample - Official first-party sample for a multi-step thinking-mode tool-call loop.
2. Keep the tool schema small and explicit
DeepSeek's sample uses a narrow function schema: a zero-argument `get_date` helper and a `get_weather` helper that requires `location` and `date`. That is the right pattern for production debugging too. If your first prototype uses a giant function schema, you make it harder to tell whether the failure is in the model, your validation rules, or your application.
Treat the sample as a schema-design hint: start with one or two tightly scoped tools, confirm that the model calls them correctly, then add more fields only after the basic loop is stable.
| Sample choice | Why it matters |
|---|---|
| One tool with no arguments | Shows the model can fetch missing state before it answers. |
| One tool with required arguments | Shows the model must emit a structured call, not vague text. |
| Simple JSON-schema objects | Keeps the failure surface narrow while you verify the loop. |
tools = [
{
"type": "function",
"function": {
"name": "get_date",
"description": "Get the current date",
"parameters": {"type": "object", "properties": {}},
},
},
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get weather of a location and date",
"parameters": {
"type": "object",
"properties": {
"location": {"type": "string"},
"date": {"type": "string"},
},
"required": ["location", "date"],
},
},
},
]3. The real pattern is multi-step, not single-shot
A lot of low-quality function-calling tutorials show one model response, one tool call, and one final answer. DeepSeek's official sample is more realistic: the model first fetches the date, then uses that state to produce a second tool call, then answers the user.
That matters because many DeepSeek production bugs only show up in the second or third step. If your app only ever tests one tool round-trip, it can look healthy while still breaking once the model has to chain calls.
4. Use the sample as your first regression fixture
If your agent runtime keeps failing, recreate the official weather example before you blame the provider, model, or framework. If the minimal sample works and your stack does not, the problem is usually in your orchestration code rather than in DeepSeek.
For the protocol rules behind this sample, continue with `/guides/deepseek-thinking-mode-tool-calls`. For the replay transcript that shows how `reasoning_content` evolves across turns, continue with `/guides/deepseek-reasoning-content-output-example`.
5. Do not confuse this guide with storefront inventory
This page is integration guidance only. It explains how to structure DeepSeek tool calls in Python and how to debug the official sample loop.
It does not create a new Coding Plan, a new model card on `/pricing`, or any promise that a specific plan is currently in stock. Commerce still depends on the repo's existing inventory rules.
FAQ
What is the official DeepSeek tool call Python example?
DeepSeek's docs publish a dedicated sample page that uses Python, the OpenAI-compatible client, and two simple functions to demonstrate a multi-step thinking-mode tool-call flow.
Why does the sample call `get_date` before `get_weather`?
Because the model first needs a concrete date, then uses that state to construct a valid weather function call. The sample shows a chained workflow instead of a one-step demo.
Should I start with a large tool schema?
No. The official sample suggests the opposite: keep the schema narrow until the basic tool loop is stable.
Is this the same as DeepSeek's generic function-calling guide?
No. The function-calling guide explains the feature at a higher level, while this sample gives a concrete thinking-mode Python implementation path.
The safest way to build DeepSeek tool use in Python is to copy the official small-schema sample first, prove the multi-step loop works, and only then scale up to broader agent orchestration.
Related model comparisons
Continue from this guide into structured DeepSeek-first comparison pages with model tables, routing advice, and pricing context.