Strands Agents Tools

Strands Agents Tools is the official companion library to the Strands Agents SDK, packaging dozens of ready-to-use tools an agent can call directly — file editing, shell execution, HTTP requests, Python REPL, AWS service calls, web search via Tavily and Exa, and persistent memory backed by Mem0, Bedrock Knowledge Bases, Elasticsearch, or MongoDB Atlas. Rather than every team re-implementing the same file-read/write, HTTP client, or memory-store tool from scratch, this package gives agents system, mathematical, web, and multi-agent orchestration capabilities behind a single pip install.

The project is under active migration as the Strands SDK absorbs more of this surface natively: shell, calculator, and several other tools are already marked deprecated in favor of SDK-native equivalents (strands.vended_tools), with warnings escalating to errors as adoption catches up. What remains and what’s actively growing — browser and desktop automation, multi-agent swarm/graph orchestration, and provider-specific memory/search integrations — reflects tools the SDK doesn’t (yet) own natively.

What You Get

• File & code tools: syntax-highlighted file read/write/edit, a stateful Python REPL, and shell execution
• Web & search tools: Tavily- and Exa-powered search, extraction, and crawling, plus a general HTTP client with auth support
• Memory backends: Mem0, Amazon Bedrock Knowledge Bases, Elasticsearch, and MongoDB Atlas memory tools with semantic search via Bedrock Titan embeddings
• AWS integration: use_aws for generic boto3-backed service calls, Bedrock Nova Reel video generation, and Bedrock AgentCore memory/code interpreter
• Multi-agent orchestration: swarm, graph, and agent_graph tools for coordinating multiple agents with shared state
• Browser & desktop automation: a Chromium-based browser tool and use_computer for GUI interaction

Common Use Cases

• Give an agent filesystem access to read, write, and edit project files as part of a coding assistant
• Wire an agent up to live web search and page extraction for research tasks via Tavily or Exa
• Persist user preferences and conversation history across sessions using a memory-backed tool
• Coordinate a swarm or DAG of specialized sub-agents on a complex multi-step task
• Call AWS services directly from an agent without writing boto3 glue code

Under The Hood

Architecture Each tool in src/strands_tools is a flat, independent, self-contained module exposing a single @tool-decorated function (e.g. file_read.py, http_request.py) with shared helpers factored into a small utils/ package. There is no central dispatcher or class hierarchy — tools are plain functions imported individually or in bulk and passed into Agent(tools=[...]). A few stateful capabilities (browser, code_interpreter) instead expose small provider classes (LocalChromiumBrowser, AgentCoreCodeInterpreter) that the caller instantiates and whose bound methods are the actual tools, giving a class-based extension point where plain functions aren’t enough. This flat-module design makes adding or retiring a capability additive and low-risk — one file per capability, with no interdependency between tool modules beyond the shared utils.

Tech Stack Python 3.10+, built with hatchling/hatch-vcs (git-tag-derived versioning) and published to PyPI. The core dependency is strands-agents itself, which supplies the @tool decorator and ToolUse/ToolResult contract every module implements against; rich drives console output, sympy backs the calculator, boto3/botocore cover AWS, requests/aiohttp handle HTTP, and smaller libraries (slack_bolt, PyJWT, watchdog, tenacity, pillow, markdownify) each back one specific tool. Heavier optional dependencies (Playwright for browser automation, mem0ai, opensearch-py) are segregated into pip install extras so a minimal install stays lightweight.

Code Quality tests/ mirrors src/strands_tools roughly one-to-one (test_file_read.py, test_http_request.py, etc.) with a separate tests_integ/ directory for integration tests and shared conftest.py fixtures. mypy runs in strict mode (disallow_untyped_defs, disallow_incomplete_defs, warn_unreachable) and ruff lints for pycodestyle/pyflakes/isort/bugbear, both enforced in CI alongside dedicated pytest and package-build workflows. The majority of tool modules wrap their core logic in explicit try/except blocks so failures surface back to the agent as a structured ToolResult rather than raising, and coverage reporting (branch mode, HTML/XML output) is wired into the build.

API Design Every tool follows the same calling convention — agent.tool.<name>(...) via the SDK’s @tool decorator — so switching between file, web, memory, and AWS tools costs nothing in mental model. The deprecation path is unusually disciplined for an OSS toolkit: retired tools keep working, log a warning starting at a named version, escalate to an error log at a later one, and carry @typing_extensions.deprecated markers so mypy --enable-error-code deprecated can enumerate every call site that still needs migrating — turning a breaking change into a gradual, tool-assisted one.