[Lorenze Jay (lorenzejay)]

Resolves OSS-270.

What

• crewai create agent (JSON/YAML, interactive terminal) now opens the same tool picker and CrewAI Platform setup as crewai create crew: accordion picker, per-app action selection, and AMP sign-in plus integration validation. Picking and auth run before any files are written, so a cancelled sign-in leaves no partial project.
• crewai tool add [TOOLS...] adds tools to an existing agent project. With no arguments it opens the picker; otherwise it takes references such as SerperDevTool, platform:gmail/send-email or custom:my_tool. Platform app and action names are checked against the catalog, and new platform apps are validated on AMP before the definition changes.
• crewai tool setup reads the platform: tools already in the agent definition, validates them on AMP and saves CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN to .env (for example after cloning a project).
• Docs: concepts/cli.mdx and guides/agents/standalone-agent-projects.mdx, synced to ar, ko and pt-BR.

How

The new crewai_cli/agent_tools.py reuses the existing onboarding helpers from create_json_crew.py (_select_tools, _select_platform_actions, _setup_platform_auth), so the crew and agent flows share one picker and one AMP setup path. It only adds the code that edits the definition:

• New tools are appended to the definition's tools list; tools already present are skipped.
• agent.json is rewritten with 2-space indentation; agent.yaml keeps the scaffold's layout (block scalars for multi-line strings, indented lists).
• The crewai dependency becomes crewai[tools] when a non-custom: tool is added, since crewai_tools and platform tools need that extra.

Reviewer notes

• Python agents (--format python) skip the picker, and tool add points the user to Agent(tools=[...]); editing agent.py safely is out of scope.
• Comments: definitions are rewritten as plain JSON/YAML, so comments are not preserved. An unparseable file (for example JSON with comments) gets a clear error instead of being overwritten.
• Non-interactive runs (CI, piped stdin, CREWAI_DMN) are unchanged for create agent; tool add without arguments asks for tool names there.
• JSON crews: tool add targets standalone agent projects only. Adding tools to an existing JSON crew would need an agent-selection prompt; that could be a follow-up.
• Shared private helpers: agent_tools.py imports underscore-prefixed functions from create_json_crew.py to keep this diff small. They could move to a shared module later.

Testing

• lib/cli/tests/test_agent_tools.py (18 tests) covers JSON and YAML tool add, skipping tools already present, invalid platform references, unparseable definitions, cancelled AMP setup leaving files untouched, tool setup, onboarding during create agent, and the Python-agent paths.
• The CLI suites (test_create_agent, test_create_crew, test_cli, test_create_unified, tests/tools) pass: 392 tests. ruff, ruff-format and mypy are clean.
• End to end: scaffolded JSON and YAML agents, ran crewai tool add SerperDevTool FileReadTool, and loaded the JSON agent with load_agent_project, which resolved all 5 tools. The interactive picker was opened in a real terminal.

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches CLI auth/platform integration and writes agent definitions plus .env tokens; changes are well-tested but affect security-sensitive AMP setup paths.

Overview
Extends standalone JSON/YAML agent workflows so tool selection and CrewAI Platform setup match crewai create crew: interactive crewai create agent now runs the shared picker and AMP validation before writing files, avoiding partial projects when sign-in is cancelled.

Adds crewai tool add and crewai tool setup to append tools to agent.json/agent.yaml, bump crewai[tools] when needed, validate platform apps/actions, and persist CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN in .env. Python agents are excluded from definition editing.

Introduces crewai_cli/agent_tools.py reusing crew onboarding helpers, plus a fix in _setup_platform_auth that restores machine proxy/CA/TLS settings after crewai_tools import-time load_dotenv() so project .env cannot steer AMP requests.

Documentation is updated for en, ar, ko, and pt-BR; coverage adds test_agent_tools.py and a transport regression test in test_create_crew.py.

^{Reviewed by Cursor Bugbot for commit a4752ff. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
crewai	🟢 Ready	View Preview	Nov 12, 2026, 7:04 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[strix-security]

Strix Security Review

Warning

This pull request has 17 commits after the last Strix review (cc27ce0). Strix has not reviewed these changes.
Automatic review on push is off for this repository. To review the latest changes, tag @strix-security in a comment, or turn on re-review on push.

To fix before merging (1)

• 🔵 MEDIUM Project .env can redirect the credentialed AMP request in crewai tool add / crewai tool setup — lib/cli/src/crewai_cli/agent_tools.py:36-38

PR summary: Adds a tool picker to `crewai create agent` and two new commands, `crewai tool add` and `crewai tool setup`, which append tool references to a standalone agent project's JSON/YAML definition, validate CrewAI Platform applications on AMP, and persist the Enterprise Action Auth Token to `.env`.

Review summary

Reviewed the new agent-tool management code and the platform-auth helpers it reuses. Definition handling is sound: the JSON/YAML path is confined to the project root, parsed with safe loaders, and written through a SafeDumper, and the .env writer keeps the token owner-only and refuses symlinks. The one substantive issue is Project .env can redirect the credentialed AMP request in crewai tool add / crewai tool setup: because these commands run in a directory the user did not author (the docs pitch tool setup as the post-clone step), an untrusted project's .env is pulled into the CLI process by an unrelated import-time load_dotenv(), and the AMP client's plain requests call honours the proxy and CA settings it injects — so the user's bearer token is sent to a destination the repository chose. The run and eval paths already guard against exactly this with restore_machine_transport, but the new commands do not. Other candidates — attacker-supplied auth tokens, .env rewrite fidelity, .gitignore coverage, pyproject.toml rewriting, and path or tool-reference resolution — were investigated and did not hold up as exploitable.

Ruled out (6)

• Can a cloned project's `.env` supply `CREWAI_ENTERPRISE_ACTION_AUTH_TOKEN` and hijack which AMP account the agent's tools run against?
  The project `.env` is the designed credential location and is already applied when the project runs, so the new commands re-validate and re-save the value the run would use anyway and add no capability an attacker who can plant that file does not already have.
• Does rewriting an existing `.env` when saving the token truncate quoted multi-line secrets?
  The round-trip does drop comments and collapse multi-line values, but it only touches the invoking user's own current-directory file with no third-party attacker and no disclosure, making it a data-integrity defect rather than a vulnerability.
• Can the platform token be exfiltrated by writing it into an untrusted clone's `.env` that is later committed?
  The file is written owner-only and symlink-safe, scaffolded projects already ignore `.env`, and an attacker who controls the repository also controls its executable content, so a missing ignore entry grants nothing extra.
• Is the `pyproject.toml` dependency rewrite in `_require_tools_extra` exploitable or able to inject content?
  The replacement text is derived from the file's own packaging-validated requirement and installation uses list-form `uv` without a shell, so the demonstrated effects are mis-targeted edits and non-atomic writes confined to the user's own manifest.
• Can a crafted agent definition path read or overwrite files outside the project?
  Entrypoint resolution rejects `~` and absolute paths, resolves symlinks, and enforces containment inside the project root before the same resolved path is written.
• Can a tool reference written into the definition reach an unsafe import or code-execution sink?
  The loader's `custom:` and `module:qualname` resolution sinks already existed and are reachable from the definition file itself, so the new commands add persistence rather than new reachability.

_{Fixed the findings? re-run the review, or tag @strix-security in a PR comment to run a fresh review.}

_{Review 1 on this PR · cc27ce0 · requested Nov 10 23:22 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[linear]

OSS-270

[strix-security]

Strix flagged a new security finding below. See the pinned summary comment for the full PR status.

[Vidit Ostwal (Vidit-Ostwal)]

lgtm

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a4752ff. Configure here.}

[cursor]

Partial tool add on later failure

Medium Severity

add_tools_to_agent_project writes the agent definition before it saves the AMP token or adds the crewai[tools] extra. A later failure (for example save_platform_token refusing a symlink .env, or _require_tools_extra hitting invalid TOML) leaves new tools in the definition without the matching extra or token, even though the command errors out. AMP setup is correctly done first; these follow-on writes are not.

 

^{Reviewed by Cursor Bugbot for commit a4752ff. Configure here.}