CrewAI Tools: The 75+ Catalog, Custom Tools and MCP Setup

CrewAI gives agents actions through tools, and the open-source crewai-tools package holds a catalog of 75+ of them ^[1]. You install them with the crewai[tools] extra, pick ready-made tools for files, search, scraping, databases and automation, and write your own when nothing fits, either by subclassing BaseTool or with the @tool decorator. MCP servers plug in through an agent's mcps field or through MCPServerAdapter. The catalog itself costs nothing. Many of its tools, though, call paid third-party APIs on your own key.

Our verdict: the tool layer is one of the more careful parts of CrewAI. File tools stay inside the working directory, scraping tools block private addresses, and result caching is now something you switch on. Two traps remain. The built-in code interpreter is gone, so code runs in outside sandboxes. Several search tools still carry an experimental label. Read that label before you build a research pipeline on one, and treat every MCP server as code you are choosing to trust.

Install the package and see what the 75+ tools cover

The tools ship separately from the core framework. Adding the crewai[tools] extra to your project installs the standard set. Some tools need an extra of their own on top: the E2B and Daytona sandboxes, MongoDB vector search and SingleStore each install with a named extra of crewai-tools. If you have not scaffolded a project yet, the CrewAI tutorial covers Python versions and crewai create crew first. Once installed, tools attach to an agent through its tools list. Tools, MCP servers and AMP Apps all resolve into the same internal BaseTool format, so an agent treats them alike.

Two newer additions are not in the category overviews above. URLReadTool, added in August 2026, reads an arbitrary URL and extracts text from PDF, DOCX and XLSX files, with a 5 MiB response cap and a 30-second timeout by default; it does not authenticate. Spreadsheet reading arrived in November 2026 through the crewai[spreadsheets] extra. A few listed tools need care. PGSearchTool is still under development and not yet in the package. WebsiteSearchTool, CSVSearchTool and JSONSearchTool are labeled experimental, and the WebsiteSearchTool page warns it may not be accessible yet.

Which tools run without a key, and which bill you elsewhere

A good share of the catalog needs no third-party account. ScrapeWebsiteTool and ScrapeElementFromWebsiteTool fetch pages directly, Selenium drives a local Chrome, ArxivPaperTool queries the public arXiv API, WaitTool pauses an agent, and the file read and write tools work on local disk. Everything that touches an outside service runs on your key. Serper (a free tier exists), Tavily, Exa, Firecrawl, Brave, Bright Data, Browserbase, Apify, Composio, Zapier and the E2B and Daytona sandboxes are billed by those providers, never by CrewAI. Zapier's rate limits also follow your Zapier plan.

The RAG search tools hide a second cost. Tools that search your own files, sites or repos (PDF, CSV, JSON, TXT, Directory, Website, GitHub, Code Docs and YouTube search) create OpenAI embeddings by default, so that path also needs an OpenAI key. API search tools such as Serper, Tavily, Exa and Brave need only their own key. For the RAG tools you can switch the embedder to Ollama, Google, Cohere or others, and store vectors in ChromaDB or Qdrant. Teams building literature or market research pipelines will find the provider-by-provider picture in CrewAI for research teams. Running the framework stays free, while model and tool bills stay yours, as our guide to whether CrewAI is free explains.

Writing a custom tool in four decisions

When the catalog lacks what you need, CrewAI offers two shapes. Subclass BaseTool and implement _run when the tool needs configuration or state. Use the @tool decorator on a plain function when it does not; that function then needs a docstring and type annotations, which describe the tool to the agent. Both can run async, through _arun or an async function. The crewai create tool command scaffolds a tool project and replaces the older crewai tool create, which still works with a warning. Four settings then shape how the tool behaves in a run:

• Required keys. Declare the environment variables the tool needs with EnvVar.
• Typed output. result_schema returns a typed result, sent to the agent as JSON.
• Failure handling. A tool can return a typed ToolFailure; tool_failure_policy picks ignore, warn (the default) or raise, and failures appear on the task and crew output.
• Final answer. result_as_answer=True passes the tool's output straight through as the task result, with no rewrite by the agent.

Two spend controls belong on any tool that calls a paid API. max_usage_count caps how many times an agent may call the tool; by default usage is unlimited. Caching changed in July 2026, when tool-result caching became opt-in in release 1.15.3 ^[2]. Older pages that show it on by default are out of date. Turn it on where repeat calls are expected, and add a cache_function to decide which results are worth keeping. A finished tool can go to PyPI under a crewai- prefix or to the AMP Tool Repository.

The safety defaults, and the code interpreter that left

The file tools validate every path against the working directory and raise an error for anything outside it. File URIs and private IP ranges are blocked to stop server-side request forgery, and the scraping tools check every redirect hop, cloud metadata addresses included. FileWriterTool does not overwrite an existing file unless told to. URLReadTool rejects private and loopback addresses unless a host is allowed by name. One switch, CREWAI_TOOLS_ALLOW_UNSAFE_PATHS=true, turns this off for every tool in the process. On managed workers the docs recommend the opposite setting, CREWAI_TOOLS_FORCE_SAFE_PATHS=true.

Database access is cautious too. NL2SQLTool runs model-generated SQL directly against your database, so it is read-only by default and, in that mode, refuses multi-statement queries; writes need allow_dml. The docs still advise a read-only database user or a replica. Code execution changed in April 2026. CodeInterpreterTool was removed and the agent's code-execution parameters were deprecated. Running code now goes through the E2B or Daytona sandbox tools, which give shell, Python and file operations in isolated sandboxes. Each needs its own account and API key. Daytona sandboxes are ephemeral by default, created and deleted on every call.

One more guard sits in the agent rather than the tool. Since October 2026 the fifth identical tool call, meaning the same tool with the same arguments and the same result, stops the task. That limit is fixed. For finer control, a pre-tool hook can block a call or ask a human to approve it before an email or a payment goes out. Agent-level limits such as max_rpm and max_execution_time work alongside both, and a crew-level max_rpm overrides the agents'.

Plugging in MCP servers

CrewAI has supported MCP as a first-class feature since November 2025, and it offers two ways in ^[3]. The recommended route is the mcps field on an agent: list server URLs or connected catalog slugs, and add a hash suffix to pick a single tool. It needs the mcp library. The advanced route is MCPServerAdapter from crewai-tools[mcp], which connects several servers at once and pools their tools. Both handle Stdio for local servers, plus SSE and Streamable HTTP for remote ones.

The two behave differently in a run. With the mcps field, tool schemas are cached for five minutes, connections open only when a tool is actually used, an unreachable server is skipped with a warning instead of crashing the agent, and tool names get a server prefix to avoid clashes. The adapter does not cache the tool list by default, supports allow and block filters, and adapts tools only, not MCP prompts or resources. Some servers need it. You.com's contents tool, for one, works only through the adapter.

Security deserves a slow read. An MCP server can run code and reach systems through its tools, and a malicious one can inject instructions through tool metadata, so the docs say to connect only servers you fully trust. SSE transports can be open to DNS rebinding; the fixes are validating Origin headers, binding local servers to 127.0.0.1 and adding authentication. On AMP, a custom MCP server must be reachable from the internet and speak Streamable HTTP. Any deployed automation can itself be exported as an MCP server, on both plans.

Sharing tools across a team with the AMP Tool Repository

Once a custom tool is worth reusing, CrewAI AMP (Agent Management Platform), the paid platform around the framework, offers a Tool Repository that works like a package manager for crews and flows. It needs an AMP account, the CLI after crewai login, uv 0.5.0 or newer and Git. A private tools repository is listed on both the free Basic plan and Enterprise. Published tools stay private to your organization unless you add the --public flag, which opens them to every CrewAI user ^[4].

Every published version passes automated security checks before anyone can install it. Two quirks catch people out. Extra packages for an installed tool must be added with the crewai uv command, because plain uv fails on the repository's authentication. Deleting a tool is permanent. It cannot be restored, so keep the source in your own Git repository as well. AMP's Basic plan also includes only 2 automations and 50 workflow executions a month, with no additional executions, which matters once those tools run inside deployed crews rather than on your own machine.

Where the tool layer earns its keep

Start with the no-key tools and one search key, then write a custom @tool function the first time an agent needs your own system. Switch caching on only where repeat calls happen, and set max_usage_count on anything that bills per call. Reach for MCP when a trusted server already exposes what you need, and prefer the mcps field unless you need the adapter's filters or a server only it supports. Leave the unsafe-paths switch off. Move tools to the Tool Repository once two crews need the same one.