Rohini Gaonkar published a developer tutorial on September 16, 2026 explaining how tool calling lets a foundation model use live information through application code, using Amazon Bedrock, Claude through the Converse API, and sample code in a GitHub repo folder named `ep07-tool-calling`. The tutorial starts from the problem that a foundation model is frozen at its training cutoff, so it cannot answer live questions such as whether it will rain, what a live price is, or what today's date is without outside context.

The tutorial says a model does not run code by itself when it "calls a tool." The model reads a prompt and tool descriptions, then returns a structured request such as `call get_weather, city is Toronto`; the developer's code reads that request, runs the actual function, and sends the result back so the model can write an answer or request another tool. The article describes a 4-step loop: send the user question plus tool descriptions, receive a structured tool request, run the real function, and return the result to the model.

The setup uses Amazon Bedrock's `bedrock.converse` call with a Claude model, `toolConfig={"tools": [WEATHER_TOOL]}`, `inferenceConfig={"maxTokens": 2048}`, and `additionalModelRequestFields=THINKING`. The weather tool is described with 3 parts: the name `get_weather`, the description "Get the current weather for a single city," and a JSON input schema requiring one `city` string, with examples such as Toronto or Paris. The real `get_weather(city: str)` function is ordinary Python code using `requests`; it calls Open-Meteo's geocoding API with `count: 1`, then calls the forecast API for `temperature_2m`, `weather_code`, and `wind_speed_10m`.

In the first demo, the user asks, "Do I need an umbrella in Toronto today?" The model returns a `stopReason` of `tool_use` and a `toolUse` request with `toolUseId` set to `tooluse_abc123`, `name` set to `get_weather`, and `input` set to `{ "city": "Toronto" }`. The application then runs `get_weather("Toronto")` and sends back a `toolResult` containing Toronto, Canada, `temperature_c: 23.8`, `conditions: overcast`, and `wind_kph: 3.9`. The model's final answer says the user probably does not need an umbrella right now because the weather is overcast with no rain.

The tutorial adds a second tool after showing that the weather-only setup cannot answer "What's today's date?" The `get_current_datetime` tool has the description "Get the current date and time," an empty object input schema, and a Python function that returns `date` in `%Y-%m-%d`, `day_of_week` in `%A`, and `time` in `%H:%M`. When asked "Do I need an umbrella in Toronto? And what is today's date?", the model requests 2 tools: `get_weather` with `{"city": "Toronto"}` and `get_current_datetime` with `{}`. The screenshoted run returns clear sky, `23.5C`, and Thursday, `2026-08-20`, then combines both results into one answer.

The tutorial says multiple tools require a `while True` loop because the developer no longer knows which tool the model will choose, how many requests it will make, or whether it will request more after seeing a result. The sample code maps tool names to real functions in `TOOLS`, calls `bedrock.converse`, stops when `stopReason` is not `tool_use`, and otherwise iterates through every `toolUse` block, runs the named function with the provided input, and appends all `toolResult` objects to the message history.

The tutorial closes by separating tool calls from prompt injection. It cites Anthropic release notes saying Claude's web and mobile apps receive up-to-date information such as the current date through a system prompt at the start of every conversation. A script can do the same by setting a system prompt like `Today's date is {datetime.now():%A, %d %B %Y}.` The article's rule is to inject cheap and static facts such as today's date, but use a tool for live and always-changing facts such as weather.

Rohini Gaonkar published a developer tutorial on September 16, 2026 explaining how tool calling lets a foundation model use live information through application code, using Amazon Bedrock, Claude through the Converse API, and sample code in a GitHub repo folder named `ep07-tool-calling`. The tutorial starts from the problem that a foundation model is frozen at its training cutoff, so it cannot answer live questions such as whether it will rain, what a live price is, or what today's date is without outside context.

The tutorial says a model does not run code by itself when it "calls a tool." The model reads a prompt and tool descriptions, then returns a structured request such as `call get_weather, city is Toronto`; the developer's code reads that request, runs the actual function, and sends the result back so the model can write an answer or request another tool. The article describes a 4-step loop: send the user question plus tool descriptions, receive a structured tool request, run the real function, and return the result to the model.

The setup uses Amazon Bedrock's `bedrock.converse` call with a Claude model, `toolConfig={"tools": [WEATHER_TOOL]}`, `inferenceConfig={"maxTokens": 2048}`, and `additionalModelRequestFields=THINKING`. The weather tool is described with 3 parts: the name `get_weather`, the description "Get the current weather for a single city," and a JSON input schema requiring one `city` string, with examples such as Toronto or Paris. The real `get_weather(city: str)` function is ordinary Python code using `requests`; it calls Open-Meteo's geocoding API with `count: 1`, then calls the forecast API for `temperature_2m`, `weather_code`, and `wind_speed_10m`.

In the first demo, the user asks, "Do I need an umbrella in Toronto today?" The model returns a `stopReason` of `tool_use` and a `toolUse` request with `toolUseId` set to `tooluse_abc123`, `name` set to `get_weather`, and `input` set to `{ "city": "Toronto" }`. The application then runs `get_weather("Toronto")` and sends back a `toolResult` containing Toronto, Canada, `temperature_c: 23.8`, `conditions: overcast`, and `wind_kph: 3.9`. The model's final answer says the user probably does not need an umbrella right now because the weather is overcast with no rain.

The tutorial adds a second tool after showing that the weather-only setup cannot answer "What's today's date?" The `get_current_datetime` tool has the description "Get the current date and time," an empty object input schema, and a Python function that returns `date` in `%Y-%m-%d`, `day_of_week` in `%A`, and `time` in `%H:%M`. When asked "Do I need an umbrella in Toronto? And what is today's date?", the model requests 2 tools: `get_weather` with `{"city": "Toronto"}` and `get_current_datetime` with `{}`. The screenshoted run returns clear sky, `23.5C`, and Thursday, `2026-08-20`, then combines both results into one answer.

The tutorial says multiple tools require a `while True` loop because the developer no longer knows which tool the model will choose, how many requests it will make, or whether it will request more after seeing a result. The sample code maps tool names to real functions in `TOOLS`, calls `bedrock.converse`, stops when `stopReason` is not `tool_use`, and otherwise iterates through every `toolUse` block, runs the named function with the provided input, and appends all `toolResult` objects to the message history.

The tutorial closes by separating tool calls from prompt injection. It cites Anthropic release notes saying Claude's web and mobile apps receive up-to-date information such as the current date through a system prompt at the start of every conversation. A script can do the same by setting a system prompt like `Today's date is {datetime.now():%A, %d %B %Y}.` The article's rule is to inject cheap and static facts such as today's date, but use a tool for live and always-changing facts such as weather.