docs: replace deprecated strands_tools references in samples

[yonib05]

Description

strands-agents/tools is deprecating calculator, current_time, memory, retrieve, and think (strands-agents/tools#566, following #550). These samples import them, so anyone working through the tutorials — starting with 01-first-agent — would hit deprecation warnings.

37 files updated: 26 .py, 14 .ipynb, 1 .md.

calculator is replaced with a small self-contained @tool that evaluates an arithmetic AST:

import ast
import operator

from strands import Agent, tool

_OPS = {ast.Add: operator.add, ...}


def _eval(node: ast.AST) -> float:
    """Evaluate an arithmetic AST node, rejecting anything that is not arithmetic."""
    ...


@tool
def calculator(expression: str) -> str:
    """Evaluate an arithmetic expression such as "144 ** 0.5" or "450 / 120"."""
    return str(_eval(ast.parse(expression, mode="eval").body))

The samples prompt for real arithmetic, so the demo tool has to compute something — a placeholder like a letter-counter would have made the prompts nonsensical. This keeps every prompt working while dropping the strands_tools dependency, so the samples run with just the SDK installed.

current_time, memory, retrieve, and think are removed from the tool lists that used them. Their replacements are SDK configuration rather than tools (ContextInjector, MemoryManager, native extended thinking), which doesn't fit inline in a sample.

mem0_memory is intentionally untouched — different tool, not deprecated.

Testing

Docs changes still need to actually work, so:

• All 16 generated helpers were executed, not just parsed: each returns 12.0 for "144 ** 0.5" and raises ValueError on __import__('os').system('id'). Zero failures.
• Every touched Python unit parses (24 units across files, notebook cells, and markdown blocks).
• All notebooks remain valid JSON, with no metadata, execution_count, or output churn — verified the diffs touch only source lines, so review stays readable.
• Notebook cell structure preserved: files that defined the tool once and reused it in later cells kept exactly that shape. Confirmed against origin/main rather than assumed — e.g. streaming.ipynb had 1 import cell and 3 use cells before, and has 1 def cell and 3 use cells after.
• Caught one file (websocket_example.py) where an automated edit landed the helper inside a multi-line parenthesized import and broke the module; fixed by hand and re-verified.

Related

• feat: deprecate 11 tools superseded by SDK capability, MCP servers, or nothing tools#566 — the deprecations themselves
• docs: replace deprecated strands_tools examples with self-contained equivalents harness-sdk#3631 — same cleanup in the docs site

Safe to merge independently of both; it only removes usages.

[github-actions]

Latest scan for commit: f8cc957 | Updated: 2026-08-06 00:47:17 UTC

✅ Security Scan Report (PR Files Only)

Scanned Files

• python/01-learn/01-first-agent/01-first-agent.ipynb
• python/01-learn/01-first-agent/README.md
• python/01-learn/02-tools-and-mcp/02-custom-tools/custom-tools-with-strands-agents.ipynb
• python/01-learn/02-tools-and-mcp/02-custom-tools/requirements.txt
• python/01-learn/04-streaming/requirements.txt
• python/01-learn/04-streaming/streaming.ipynb
• python/01-learn/09-bidi-streaming/README.md
• python/01-learn/09-bidi-streaming/test_simple_gemini.py
• python/01-learn/09-bidi-streaming/test_simple_novasonic.py
• python/01-learn/09-bidi-streaming/test_simple_openai.py
• ... and 23 more files

---

Security Scan Results

Critical	High	Medium	Low	Info
0	0	0	0	0

Threshold: High

No security issues detected in your changes. Great job!

This scan only covers files changed in this PR.

[yonib05]

@strandly-the-agent can you review this PR?

[strandly-the-agent]

Verified against pr-296 @ 924da59 (base main @ 04b9f02), 34 files, 5 independent passes.

• ✅ Every file:line below re-checked against this diff by hand (git diff, sed -n) — anchors are exact.
• ✅ 25 changed .py files py_compile clean, 8 changed .ipynb valid JSON, no cell-ordering or %%writefile breakage from the 16 helper insertions. The calculator swap itself is solid.
• ✅ Confirmed chat.py's tools=[retrieve] → tools=[] is introduced here, and that the unbounded-** CPU/RAM hang reproduces identically on the deprecated calculator (so: pre-existing, not yours).
• 🔴 Not verified by any pass: no live Bedrock run. CONTRIBUTING.md:35's actual gate ("run the code end-to-end… produce the correct output") wasn't exercised.

The headline: "Safe to merge… it only removes usages" doesn't hold. Two retrieve.retrieve(...) call sites were left behind after their imports were deleted (silent NameError, swallowed by broad except), and three KB-backed samples lost their only path to a Knowledge Base the tutorial still provisions. All fixable; none is a redesign.

Per-pass breakdown (5 passes)

• Correctness/safety — found the 3 dead-retrieve call sites (2 NameError, 1 silently-ungrounded agent); confirmed everything compiles/parses.
• Adversarial/repro — @tool catches every exception from the body (strands/tools/decorator.py:641-668), so 1/0, 1 % 0, 10.0 ** 400, RecursionError are recoverable tool-errors, not crashes. The real regressions are behavioral. The ** CPU bomb is real but pre-existing (9 ** 9 ** 9 SIGKILLs the old strands_tools calculator too).
• Docs accuracy — independently found the same two NameErrors; added the "built-in vs custom" teaching-point breakage in 01-first-agent (4 spots) and the 3 deploy-notebook KB tests going dead.
• LLM-context — the docstring under-specifies what's accepted (primes sqrt/sin////^), and rejection returns raw ast.dump() at the model: Error: unsupported expression: Call(func=Name(id='sqrt', ctx=Load()), ...). 6+ system prompts still instruct tools that no longer exist.
• Issue alignment — partial against its own claim: strands-playground/app/main.py:11-15 still wires up all five deprecated tools, research-agent/agent.py:532-588 four of five, plus 4 stray notebooks. Also: body says 37 files (actual 34), and upstream tools#566/#550 are warning-only with no removal date — so there's room to split this rather than rush it.

Questions

• Blocking-ish: retrieve is load-bearing, not incidental, in 5+ places (kb_rag.py, the Lambda error-analyzer, chat.py, and the 3 deploy-agent.ipynb KB tutorials). Would it be cleaner to land the calculator swap + the genuinely incidental current_time/think deletions now, and hold the retrieve-dependent samples for a follow-up that wires in the replacement upstream itself names (MemoryManager(BedrockKnowledgeBaseStore(writable=False)))? Given the deprecation is warning-only with no removal date, there seems to be time.
• Non-blocking: is a ~30-line AST walker the right first thing a beginner reads in 01-first-agent cell 7, when a 4-line restricted-eval pattern already lives in-repo at 18-self-improving-agents/code/step-01-tools/tools/calculator.py:5-19? It'd preserve every prompt in that notebook without opening the first tools lesson with an ast tutorial.
• Non-blocking: worth fixing the description's file count (37 → 34) and noting which samples the sweep intentionally leaves behind?

Appendix — non-blocking (6 groups)

• Doc staleness long tail (all confirmed, none inline): 01-first-agent.ipynb:11,20,32,116,455 + README.md:13,44 (the notebook now has no built-in tool, so "built-in and custom tools" is false in 5 places); structured-output.ipynb:552 + 19-structured-output/README.md:17; Observability-and-Evaluation-sample.ipynb:24 and :434 — the RAGAS tool_usage_effectiveness rubric still scores the agent on "using retrieve for menu questions and current_time for time questions", which changes eval semantics, not just prose; 02-tools-and-mcp/README.md:17; streamlit-template/README.md:136; data-warehouse-optimizer/README.md:17; aws-assistant-mcp/README.md:12; personal-assistant/README.md:16; 02-deploy/03-agentcore/deploy-agent.ipynb:624 (dead comment describing an import deleted right below it). Past deprecation sweeps here (31889ea/#234, ce803f1/#230) updated the READMEs alongside the code.
• Dead current_time UI branches (unreachable, harmless): chat.py:1103, video-games-sales-assistant/.../docker/src/app.py:208.
• Completeness gaps left behind: strands-playground/app/main.py:11-15,61-115; research-agent/src/strands_research_agent/agent.py:532-588; 01-learn/07-aws-services/connecting-with-aws-services.ipynb:477; arize/Arize-Observability-openinference-strands.ipynb:240; retail/restaurant-assistant/restaurant-assistant.ipynb:483; corrective-rag/1-corrective-rag-agent.ipynb:60.
• Dead strands-agents-tools dependency now unused but still installed in 9 places: 04-streaming/requirements.txt:4, 19-structured-output/requirements.txt:2, 09-bidi-streaming/requirements.txt:78, 02-custom-tools/requirements.txt:2, data-warehouse-optimizer/pyproject.toml:8, strands-spot-agent/requirements.txt:12, streamlit-template/docker_app/requirements.txt:5, video-games-sales-assistant/.../docker/requirements.txt:2, 01-first-agent/README.md:44.
• Calculator quirks, no reachable sample prompt hits them: True → "True" (bool is an int subclass, so it passes the isinstance check), (-8) ** 0.5 → complex despite -> float, unrounded output (0.1 + 0.2 → "0.30000000000000004", 144 ** 0.5 → "12.0" where the old tool gave 12). No sandbox escape found — the AST allow-list holds against __import__('os').system('id') and friends.
• Pre-existing, not filed: unbounded ** hangs the new and the old calculator identically (9 ** 9 ** 9 → SIGKILL; 2 ** 10000000000 → ~1 GB RSS), and it holds the GIL, so a 2.3 s call froze an asyncio heartbeat for 2.4 s in a repro. Not a regression — but this PR does bake unguarded operator.pow into 15 files as the house pattern, several of them long-running servers (slack-assistant, streamlit-template, a2a-native/server.py, websocket_example.py). Might be worth a small shared guard in a follow-up; happy to file an issue if useful.
• Minor: import ast/import operator land ahead of the existing stdlib block in 6 files (no lint config enforces it), and a2a-native/server.py:38 now has an import sitting after a function definition — valid, just unusual.

Context for the tone: the sweep itself is careful and the PR body's testing section is unusually thorough — the 16-helper execution check is exactly the right instinct. It just couldn't catch a deleted import whose module attribute is still called elsewhere in the file, which is where 3 of the 5 blockers live. As always, this is agent review output — worth a human's judgment before acting on it.

[yonib05]

@strandly-the-agent please re-review. Note this PR already shipped the AST evaluator (not the sympy version that was the problem in the harness-sdk PR).

Your 9 inline comments flagged retrieve samples where removing the import left retrieve.retrieve(...) calls dangling — I reverted the KB-retrieval samples entirely for that reason, since porting them to MemoryManager is a redesign rather than a reference swap. Worth confirming that's the split you'd expect.

[strandly-the-agent]

The revert isn't on the branch — head is still 924da59, one commit, 34 files, +664/−87, byte-identical to what I reviewed yesterday. All 9 threads are still open and none is marked outdated. So there's nothing new for me to re-review yet; I think the revert is still local (or on another branch/fork — if so, point me at it).

On the split: yes, that's exactly the one I'd expect — and reverting is better than the follow-up-PR framing I used, because it keeps main working today instead of leaving a half-migrated state. Since the deprecation is warning-only with no removal date (tools#550/#566), there's no cost to holding those samples.

Precise list — 8 files carry a retrieve removal; 7 should come out, 1 can stay

Classified every file in the diff by which deprecated tool its removal touches:

Take out (7):

file	why
.../multi-modal-email-assistant-agent/kb_rag.py	dangling retrieve.retrieve() → NameError
.../lambda-error-analysis-agent/cdk/lambda/error-analyzer-agent/agent.py	dangling retrieve.retrieve() → NameError
.../genai-powered-financial-advisor-tools/application/chat.py	tools=[retrieve] → [], silent grounding loss
python/02-deploy/01-lambda/deploy-agent.ipynb	KB provisioned, agent can't reach it
python/02-deploy/02-fargate/deploy-agent.ipynb	same
python/02-deploy/03-agentcore/deploy-agent.ipynb	same, plus a KB test cell at :919
python/01-learn/08-observability/Observability-and-Evaluation-sample.ipynb	removes current_time + retrieve, and its RAGAS tool_usage_effectiveness rubric at :434 still scores the agent on exactly those two tools

Can stay (1): .../genai-powered-financial-advisor-tools/application/mcp_server_kb.py — I checked, from strands_tools import current_time, retrieve was entirely unused there (zero remaining references in the module), so that one really is a pure reference removal.

The other 26 files only touch calculator / current_time / think / memory, which is the reference-swap half.

On the sympy note — no disagreement, but 4 findings are independent of the split and still stand

To be clear, I reviewed the AST evaluator as shipped here; I didn't think this PR had sympy in it. Where sympy came up was describing the old strands_tools.calculator that got removed — which matters for one finding: 01-first-agent.ipynb:206 (cell 9) still calls agent.tool.calculator(expression="sin(x)", mode="derive", wrt="x", order=2). That's a leftover caller of the sympy-backed signature, and it's broken against the AST tool no matter what replaced it (pydantic drops the extra kwargs, then _eval rejects sin(x) → status: "error" instead of the documented derivative).

These four are unrelated to retrieve and survive the revert:

1. slack-assistant/app.py:45,84 — docstring doesn't state the supported grammar, rejection returns raw ast.dump() to the model, and the demo's own suggested prompt "What is sin(0.4487)?" now errors while the Slack card still renders status="complete".
2. 01-first-agent.ipynb:161,206 — same docstring gap in the copy newcomers read first, plus cell 9 above.
3. custom-tools-with-strands-agents.ipynb:596 — heading "Import built-in tools" now contradicts its own body (:598); system prompts at :545/:1102 still promise current_time.
4. calendar_assistant.py:28,57 and finance_assistant_swarm.py:145 — prompts/banners still name tools that were removed; the think one is phrased as a numbered imperative, so a model following it literally gets Unknown tool: think.

Push the revert and I'll re-review just the new diff.

[yonib05]

@strandly-the-agent all 9 addressed and resolved — please re-review. The four KB-retrieval samples are reverted rather than patched, since each either calls retrieve.retrieve() directly or provisions a real Bedrock KB.

[strandly-the-agent]

Re-reviewed 7fc7155 (was 924da59), delta only: 22 files, +149/−41. Most of it checks out — two things don't.

✅ Verified fixed

• All 4 reverts are byte-identical to main (md5-compared agentcore/deploy-agent.ipynb, chat.py, kb_rag.py, error-analyzer-agent/agent.py). A repo-wide AST bind/load scan over every changed .py now reports zero unbound retrieve/current_time/think/memory/calculator names — the NameError class is gone.
• Docstring hardening landed in all 16 copies, still byte-identical (one variant, sha256[:12]=0d9be87cadf9) — no copy-paste drift, which is the thing that usually goes wrong on a 16-site edit.
• calendar_assistant.py (prompt + banner line), finance_assistant_swarm.py:145 ("Synthesize the findings into deep strategic insights"), and the 02-custom-tools heading are all genuinely fixed.

🔴 The revert covered 4 of the 7 files that needed it. It hit exactly the 4 that had their own inline thread and missed the 3 that were named inside those threads and in my follow-up table: 02-deploy/01-lambda, 02-deploy/02-fargate, and 01-learn/08-observability. All three still drop retrieve while provisioning a real Bedrock KB and still instruct the agent to use it — the identical defect you reverted 03-agentcore for. I've put a separate comment on each rather than folding them, since folding is what caused the miss.

🟡 The new ** cap doesn't hold, and it breaks ordinary input. abs(exponent) > 64 bounds the exponent, not the work: (((9**64)**64)**64)**64 — 23 chars, exponent literally 64 at every node — ran 14.4 s and froze a concurrent asyncio loop for 13.98 s (@tool can't catch a CPU burn). Meanwhile 2 ** 100, 2 ** 128, 10 ** 100, 1.05 ** 360 and 2 ** -70 now all error — ordinary calculator questions the previous revision answered. Details + a validated 2-line alternative in the comment on slack-assistant/app.py:37.

What ran, and what didn't

• Reviewed the delta git diff 924da59 pr-296 only, not the whole PR again. Threads you resolved were re-checked against the new SHA rather than taken on trust — which is how the three partial fixes below surfaced.
• Adversarial pass on the new cap: real repros, wall-clock and peak-RSS measured, driven through an actual @tool-decorated copy on strands-agents with Python 3.13.14, two cold runs byte-identical.
• Still not verified: no live Bedrock run, so CONTRIBUTING.md:35 ("run the code end-to-end… produce the correct output") remains unexercised by me. The KB findings are read from the notebooks' own provisioning/test cells, not from a deploy.

Appendix — non-blocking (4)

• The guard's own error path is unreachable in the case it describes. 2 ** (((10**64)**64)**64) → formatting f"exponent too large: {exponent}" needs str() of a 262,145-digit int, which trips int_max_str_digits, so the model gets a CPython limit message instead of the intended one. And 2 ** ((10**64)**64) does produce the intended message — 4,117 characters of digits into the model's context. Contrived input; noting it because it's inside new code.
• str() on an allowed result can still flood context: (10**64)**64 returns status: "success" with a 4,097-character digit string (~1k tokens). A digit-count bound would cover this too.
• -> float still returns int, complex, inf and nan: (-8) ** 0.5 → complex; 2 ** (1e308*10 - 1e308*10) → nan, and since abs(nan) > 64 is False that one slips past the cap entirely. All harmless computationally, all returned to the model as successful answers. Pre-existing-adjacent, contrived.
• Everything from the last round's appendix that isn't in the diff — the doc-staleness long tail, the completeness gaps (strands-playground/app/main.py still wires all five), the 9 dead strands-agents-tools dependencies — is unchanged. Not re-raising any of it; it was non-blocking then and still is.

The split you landed is the right one, and the reverts are clean. It's the three siblings plus the cap standing between this and an approve.

[yonib05]

@strandly-the-agent can you re-review this PR?

[strandly-the-agent]

Approving. Re-reviewed 1870a16 (was 7fc7155); delta is 41 files, +247/−650. Every blocker from both prior rounds is resolved and verified, and nothing new blocks. Five non-blocking comments below.

✅ Verified, not taken on trust

• All 4 KB-retrieval notebooks are byte-identical to main (md5-compared). The three I flagged last round — 01-lambda, 02-fargate, 08-observability — are reverted alongside 03-agentcore.
• You ran it against live Bedrock, and it found things reading couldn't. f8cc957's message is the most useful artifact in this PR: the 02-custom-tools notebook dying at cell 42 on json.loads("No appointment available") with cells 31–42 dead, and the personal assistant's own README prompt returning zero tool calls. That's the CONTRIBUTING.md:35 gate my last two reviews said was unexercised — closed properly.
• strands.vended_tools.sleep exists at 1.50.0 and not at 1.48.0 (installed both, imported both). So the >=1.23.0 → >=1.50.0 bump in 09-bidi-streaming/requirements.txt:77 is correct and necessary. Audited all 8 touched requirements/pyproject files: every strands-agents-tools drop is safe, and no file that imports vended_tools is left below the floor.
• The two-operand tool fails clean. A bad op → Error: KeyError - '%', b=0 → ZeroDivisionError, non-numeric → pydantic message — all recoverable status: "error", nothing escapes into the host process. pyflakes over all 18 changed .py files: zero undefined names. All 7 changed notebooks valid JSON, every code cell parses, no leftover _eval/import ast.
• The unbounded-** item I carried as an appendix note across two reviews is now fixed by design, not by a guard. float ** float has no bignum path, so 1e308 ** 10 raises OverflowError immediately and the (((9**64)**64)**64)**64 tower I broke the interim cap with is structurally inexpressible in a two-operand tool — while 2 ** 100, which the cap wrongly rejected, works again. Better outcome than what I proposed.

One correction to my own earlier reviews: I implied removing the calculator from aws-audit-assistant dropped a capability. Wrong — it was imported but never in either file's tools=[...] on main, so it was already dead code. That removal is correct cleanup.

What ran, and what I did not verify

Full pipeline on the delta — correctness/safety, API-DevX (advanced), docs-accuracy, plus an independent skeptic pass whose only job was to attack my own scope call on the bidi README (it caught a real imprecision, reflected below). All findings re-anchored against 1870a16 by hand.

Not verified by me: I did not run a live Bedrock session myself — the end-to-end evidence here is yours, and I'm taking the commit messages at their word on the specific model behaviours they describe. The docs pass did run structured-output.ipynb's compound-interest cell live and observed exactly 6 chained calculator calls.

Appendix — non-blocking (4)

• websocket_example.py didn't get the vended sleep its three CLI siblings did. The README calls it the recommended way to try the samples (:127), but its agent is still tools=[calculator] while test_simple_{gemini,novasonic,openai}.py all gained sleep. Not a bug — just an asymmetry a reader bouncing between them would notice, and "Adding New Tools" (:271-310) still demonstrates only calculator.
• complex results are stringified: {"a": -8, "b": 0.5, "op": "**"} → status: success with '(1.73e-16+2.83j)', because complex isn't JSON-serializable and the SDK falls back to str(). Thin reachability; a 9-line teaching sample shouldn't grow an isinstance branch for it.
• current_time's UTC basis is not a regression. strands_tools.current_time also defaulted to UTC (DEFAULT_TIMEZONE unset in every sample), so "what's my agenda for today" resolving against UTC predates this PR. Worth a timezone parameter eventually; out of scope here.
• Pre-existing, and I'd like to file one issue for them rather than clutter this PR — say the word and I will. Four more 09-bidi-streaming/README.md event shapes are wrong in text this PR never touched (verified byte-identical to main): bidi_audio_input (:207-213) omits format/sample_rate/channels, which BidiAudioInputEvent.__init__ requires — websocket_example.py:135 splats client JSON straight into it, so anyone writing their own client from the reference section crashes the handler (the shipped websocket_client.html sends all five keys, so the demo itself works); bidi_transcript_stream (:358-372) documents text as the accumulated transcript when the SDK says it's the delta and current_transcript holds the accumulation — the sample's own JS appends data.text, proving the doc backwards; bidi_interruption (:379-387) omits reason. Plus slack-assistant/app.py's complete_tool_use hook renders Slack status="complete" regardless of event.result["status"] — pre-existing and untouched by this PR (0 diff lines), though the demo prompt that used to expose it is now fixed.

Three revisions in, this is in good shape — the reverts are clean, the redesign is simpler and safer than what it replaced, and running it for real is what caught the bugs that mattered. Nothing below needs to hold the merge; a human should still give it the final look.

[strandly-the-agent]

🟡 Non-blocking, but this is the copy every newcomer reads first, so it's the one worth getting right. op is a stringly-typed enum whose valid set lives only in the docstring prose — so it isn't in the schema the model sees, and an unsupported op becomes a bare KeyError.

I generated both specs against 1.50.2. Same function, same docstring, only the annotation differs:

	op: str (as shipped)	op: Literal["+","-","*","/","**"]
properties.op	{"description": "One of \"+\"…", "type": "string"}	{…, "enum": ["+","-","*","/","**"], "type": "string"}
model sees on op="^"	Error: KeyError - '^'	Input should be '+', '-', '*', '/' or '**' [type=literal_error, input_value='^']

Both are recoverable errors — nothing crashes — so this is about whether the model is told the valid set up front instead of discovering it by failing a call.

Three things make it more than taste here: the SDK solves this exact shape this way (strands/vended_tools/file_editor/file_editor.py:60 — command: Literal["view","create","str_replace","insert"], prose and Literal); the 02-custom-tools guide hand-writes "enum": ["circle","rectangle"] for a constrained string; and :116 of this very notebook teaches "A tool's typed arguments and docstring become the schema the model reads" — then the next cell ships a parameter whose valid set is deliberately outside the type.

Suggested change

	"def calculator(a: float, b: float, op: str) -> float:\n",
	"def calculator(a: float, b: float, op: Literal[\"+\", \"-\", \"*\", \"/\", \"**\"]) -> float:\n",

Needs from typing import Literal in the same cell. If you take it, it wants a sweep — the tool body is byte-identical in 12 files (a80187b5ec83), and the copies drifting apart would be worse than leaving all twelve as-is.

(For what it's worth on the bigger question: I think the two-operand redesign is the right call and teaches better than the AST walker did — 30 lines about ast dispatch in the notebook where a reader is learning what a tool is was the wrong lesson. Also confirmed -> float is pure documentation: the generated schema is byte-identical with -> float, no annotation, or a deliberately wrong one.)

[strandly-the-agent]

🟡 This row is now correct — and it makes the surrounding prose self-contradictory, since there genuinely is no built-in tool left in the notebook. Three spots in this file and two in its README still promise one:

• :32 — "* Add built-in and custom tools"
• :442 — "you built your first Strands agent, added built-in and custom tools…"
• :11 — "…from a simple agent to one that uses built-in and custom tools"
• README.md:49 — "- Adding built-in and custom tools"
• README.md:3 — same framing in the opening paragraph

Dropping "built-in and" in each covers it. README.md:13 and :44 are already fixed, so this is the last of that thread.

[strandly-the-agent]

🟡 Same as 01-first-agent: this row is right now, and :526 still says "provide it with built-in and custom tools" a few cells down, which no longer describes the notebook — it defines both tools itself. Worth dropping "built-in and" there too.

The heading fix landed well, by the way — "Define the tools our agent needs" reads correctly, and current_time being defined here and wired into tools=[...] closes the prompt/tool mismatch I flagged last round.

For context one level up: python/01-learn/02-tools-and-mcp/README.md:11,17 still says "Built-in tools: Ready-made tools from the strands-agents-tools package, such as calculator and current_time", which now contradicts both sub-notebooks. Outside this file, so I'm not asking for it here — flagging in case you want it in the same sweep.

[strandly-the-agent]

🟡 1870a16 rewrote this example's keys from tool_name/tool_input (which don't exist on the wire) to the real current_tool_use/tool_result — good fix. Two fields are still missing from the new text, and both are always present:

• tool_result here omits status and toolUseId, which are non-optional on ToolResult (strands/types/tools.py).
• tool_use_stream at :249 omits delta, a required field of ToolUseStreamEvent.__init__ (strands/types/_events.py:148) — confirmed by constructing one and dumping it.

I'd normally leave this alone as pre-existing incompleteness, but this commit's own message says you "drove the real bidi loop and tool executor and captured the wire" and names toolUseId as part of the shape — so the missing field was in hand while these lines were being rewritten. Cheap to close while you're here.

The status omission is the one I'd prioritise: this repo already has a bug from exactly that field being ignored (slack-assistant/app.py's complete_tool_use renders "complete" on failed calls), and a reference doc that doesn't show status is how the next implementer repeats it.

Four other event shapes in this README are wrong in text this PR never touched — I've kept those out of here and offered to file one issue instead; see the appendix on the summary.

[strandly-the-agent]

🟡 Lowest-priority of the five — this is the one sample where the two-operand shape genuinely costs something, so it's worth a deliberate decision rather than an accident.

The compound-interest prompt was one call under the old expression tool. Run live against Claude Sonnet 4.5 on this revision, it now takes exactly 6 chained calculator calls (+, **, *, -, /, *) before the structured-output call, because :608's system prompt says "Use the calculator tool for all math operations" and removes any shortcut. Two consequences:

1. Precision depends on the model re-keying intermediates faithfully. Rounding 1.07 ** 15 = 2.7590315… to 2.76 before multiplying by 10,000 shifts the answer by about $9.68 on a ~$27,590 result. Plausible rather than certain, but it's a financial example.
2. :630's "The agent used the calculator tool to compute compound interest" is now a fair bit undersold for a 6-call chain.

Any of these is fine by me: leave it (a 6-call chain is arguably a better tool-loop demo, and worth saying so at :630), narrow :608 so the model can do trivial steps itself, or give this one notebook a small compound_interest(...) tool. Your call — I mainly want it to be chosen rather than inherited.