strands-agents/tools: four tools the feature list sells are deprecated in its own table

Four tools in the feature list are marked deprecated in the same table

The bullet list at the top sells file operations with syntax highlighting and intelligent modifications, shell integration, an HTTP client, and Tavily-powered web search. Lower down, the tools table marks four of those same entries with a warning glyph and a deprecation note pointing at a Deprecations section: `editor` for advanced file operations, `shell` for command execution, `http_request` for API calls, and `tavily_search` for real-time web search. The bullets above were never changed to match. Two halves of the same document therefore promise different things about the same four capabilities, and nothing visible in the file says what replaces `shell` or `http_request` when they go. One row is marked twice: `shell*` carries an asterisk in its name as well as the warning marker, and no legend on the page explains what the asterisk means.

What the table does give is the call shape for each tool, which is the most usable thing in it:

agent.tool.editor(command="view", path="path/to/file.py")

Every call shown goes through one `agent.tool.<name>` namespace, so what a deprecation actually changes is a name the model calls at runtime, not an import path you can grep for ahead of time.

The base install already carries botocore, pillow and slack_bolt

The quick install is a single line, and what that line drags in is not:

pip install strands-agents-tools

The runtime list behind it includes `strands-agents>=1.0.0`, `rich`, `sympy`, `prompt_toolkit`, `aws_requests_auth`, `PyJWT`, `dill`, `pillow`, `tenacity`, `watchdog`, `slack_bolt`, `markdownify`, `requests`, `aiohttp`, `typing_extensions` and `botocore`. An install that never touches AWS still pulls botocore, and one that never opens an image still pulls pillow. Windows adds `tzdata` on top, pinned unconditionally by the marker `tzdata ; platform_system == 'Windows'`, with a comment above it saying the latest is always wanted.

Optional capabilities are handled through extras instead of the base list:

pip install "strands-agents-tools[mem0_memory, use_browser, rss, use_computer]"

Four extras cover four optional areas. Tavily and Exa search, the Bedrock Knowledge Base, Elasticsearch and MongoDB Atlas memory backends, the Slack client, and the image, video and audio tools have no extra named in that command and no client library in the base list, so what they need is written down in neither place.

Deprecation is a typing marker, and nothing else says so at install time

Deprecation here is a typing feature rather than a removal. The dependency list carries a comment explaining that version 4.5.0 introduced `typing_extensions.deprecated`, used to mark deprecated tools, and pins `typing_extensions>=4.5.0,<5.0.0`. The four deprecated tools therefore stay importable and stay callable, and the file gives no removal date for any of them. That is the honest shape of a deprecation, and it is also why the document can keep a deprecated tool in its usage table without anything breaking.

The install surface carries no equivalent signal. Neither pip command mentions that four tools are on the way out, and the four extras are unrelated to them. A caller who installs the package, wires an agent to `shell` or `http_request` because the table shows how, and reads nothing else gets no warning from pip and no warning from the extras:

agent.tool.shell(command="ls -la")

The only place the deprecation appears anywhere in the file is the table row itself, which is the one part of the document a new user is least likely to read.

A 0.x tool pack that depends on a 1.x SDK

The package sits on a version boundary worth knowing about. It depends on `strands-agents>=1.0.0`, a released SDK line, while its own releases are v0.8.7 on 2026-08-28, v0.8.8 on 2026-09-04 and v0.8.9 on 2026-09-15, with no upper bound on that dependency. Version is declared dynamic and the build backend is hatchling with hatch-vcs, so the number in a release tag comes from the tag rather than from a literal in the project file. Python 3.10 is the floor and the classifiers run through 3.14. The wheel target packages `src/strands_tools` and nothing else, and the source tree sits beside two separate test directories, `tests/` and `tests_integ/`. The build metadata also sets `allow-direct-references = true`, which lets a dependency point at a URL or repository instead of an index.

The development path is a clone, a virtual environment, an editable install with the dev extra, and pre-commit:

# Clone the repository
git clone https://github.com/strands-agents/tools.git
cd tools

# Create and activate virtual environment
python3 -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

# Install in development mode
pip install -e ".[dev]"

# Install pre-commit hooks
pre-commit install

The root carries `docs/`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and `NOTICE` beside the Apache-2.0 `LICENSE`, and the responsible AI guidance that the tools notice links to is hosted on the project site.

State between Python snippets is kept in a pickle, and confirmation rides on prompt_toolkit

The Python execution tool is described as running snippets with state persistence, user confirmation for code execution, and safety features. The dependency list explains the mechanics: `dill` is a serializer, so it is what lets state survive from one snippet to the next, and `prompt_toolkit` is the interactive layer a confirmation prompt needs. Both are unconditional dependencies, so that confirmation path is installed for everyone, including callers who only wanted to read files.

What the confirmation is worth depends on everything else within reach. The notice near the top of the file labels the tools experimental and names the capabilities that carry real weight: executing code, accessing the file system, calling AWS APIs, connecting to external servers, and automating browsers and desktops. It says any production use should be preceded by an independent security review and that use is at your own risk.

agent.tool.file_read(path="path/to/file.txt")
agent.tool.file_write(path="path/to/file.txt", content="file content")

The call shapes are short and take plain arguments, which means a model that can call one of these can pass any string it produces into a shell, a file path or a URL. Nothing in the rows shown takes an allowlist, a path root or a confirmation flag, and the only safety option named anywhere in the file belongs to the Python tool.

Tools arrive at runtime from MCP servers, known agent URLs and nested agents

Several entries change the shape of the agent rather than adding a verb to it. The dynamic MCP client connects to external MCP servers at runtime and loads whatever tools they expose; it is the only bullet in the feature list that carries its own warning and a pointer to the security warnings. Traffic to other agents goes through a provider built from a fixed list of known URLs:

provider = A2AClientToolProvider(known_agent_urls=["http://localhost:9000"]); agent = Agent(tools=provider.tools)

The multi-agent graph builds deterministic DAG pipelines with output propagation and a model configured per node, the swarm coordinates several agents over shared memory, and agent as tool creates nested agent instances with model switching for specialized sub-tasks. Batch Tool lets one model response call several other tools at once.

All of those are runtime decisions rather than a fixed pipeline. The browser and computer tools push the reach further out: one gives an agent automated actions in chromium, the other moves the mouse, types, takes screenshots and manages applications on a desktop. The file shows no configuration surface for any of it beyond the tool names, and the A2A example seeds its allowlist with a plain HTTP localhost address.

The tools table stops partway through the tavily_extract row

The feature list and the tools table cover very different amounts of ground. The bullets name twenty-five capabilities, from file operations to an RSS feed manager, each with one line of description and a named backend where there is one: memory runs on Mem0, Amazon Bedrock Knowledge Bases, Elasticsearch or MongoDB Atlas, and web work runs on Tavily or Exa. The table gives the call shape for seven tools, a2a_client, file_read, file_write, editor, shell, http_request and tavily_search, then stops partway through the tavily_extract row, with the extract options cut off inside the argument list. Nothing after that row is in the file.

That leaves most of the advertised surface without a documented invocation. Memory, browser, computer, Slack, AWS, image, video, audio, diagram, journal, cron, reasoning, swarm, graph, agent as tool and batch all have names and one-line descriptions but no usage line here. Someone working from the table alone would conclude this is a package about files, shells and HTTP, which is a different product from the one the bullets describe, and the two most consequential entries, the MCP client and the graph, appear in the bullets only.

Editorial conclusion

Taken as a bag of building blocks rather than a finished product, this pack is worth a trial: one line installs the base set, four extras keep the heavy optional pieces out of it, and deprecation is marked in the type system instead of being left to a changelog. Against that, the document contradicts itself in four places, the base dependency list carries AWS, imaging and Slack libraries for tools most callers will never open, and the runtime surface reaches the shell, the file system, AWS APIs, remote MCP servers, a browser and a desktop. Read the Deprecations section before wiring anything to it, confirm the tools you actually need are not on that list, and pin strands-agents yourself, since the pack is at 0.x while its SDK floor is 1.x with no upper bound.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. strands-agents/tools on GitHub