docs: remove CrewStructuredTool from public documentation

[lucasgomide]

Currently, CrewStructuredTool is described as a third option for defining a Task’s tool. However, this is not entirely true because a Task’s tools must inherit from BaseTool.

Since CrewStructuredTool is used internally it should not be recommended for building tools intended for Agent.

From now on, we will keep only two supported ways to create/define tools: Subclassing & Decorator

[mplachta]

Disclaimer: This review was made by a crew of AI Agents.

Code Review for PR #2707: Removal of CrewStructuredTool from Public Documentation

Summary of Key Findings

This PR removes the entire "Structured Tools" section from docs/concepts/tools.mdx, including all descriptions, example code, and references to the CrewStructuredTool class. The main stated reason is that CrewStructuredTool is intended for internal use only and should not be recommended for building tools for Agent consumption.

The deletion is precise and clean, encompassing titles, paragraphs, code samples, and comments related to the class without leftover references or formatting issues. The rest of the documentation file and other unrelated documentation sections remain untouched.

Detailed Code Quality and Documentation Findings

• Accuracy & Completeness: All mentions of CrewStructuredTool within the sampled documentation file are removed, preventing confusion over supported public APIs.
• Clarity: The PR clearly aligns the public documentation with internal design choices, avoiding accidental endorsement of an internal class.
• Formatting: The Markdown structure remains valid and well-formed after the removal.
• Change Isolation: Only the relevant docs segment is modified; no unrelated parts are affected.

Historical Context and Related PR Considerations

• Removal suggests a shift to mark CrewStructuredTool as a purely internal API.
• Prior user misunderstandings or misuse may have led to this clarifying removal.
• No accompanying changelog or release notes updates are part of this PR, which is recommended for informing users about the change.
• The example code removed could have served as a valuable tutorial; its absence may create a documentation gap.

Implications for Related Files and Project

• Potential stale links or sidebar entries referencing the "Structured Tools" section elsewhere in the documentation should be checked and updated.
• If CrewStructuredTool remains a public import in the codebase, code comments or renaming conventions (e.g., leading underscore) are advised to mark it as internal.
• Users seeking structured tool guidance will need alternative supported examples or references, currently absent.

Specific Improvement Suggestions

1. Cross-References:
   Search the entire documentation set to remove or update any references, links, or navigation items that point to the removed CrewStructuredTool documentation.

2. User Notice or Deprecation Notice:
   Add a brief note in the docs at the former location or in a relevant section, e.g.:

   Note:
   The CrewStructuredTool is intended for internal use only and is not recommended for building tools for Agent consumption. Please use the standard [Tool] class or other supported methods for custom tool creation.

3. Changelog/Release Notes:
   Document this change in the project’s changelog or release notes to communicate this removal and guidance to users upgrading or referencing documentation.

4. Codebase Clarity:
   If not already done, mark CrewStructuredTool as private/internal in the source with naming conventions or internal docstrings to match the documentation scope.

5. Alternative Documentation:
   If structured tool creation remains supported via other approaches, consider adding or improving alternative docs to avoid user confusion.

Conclusion

This PR effectively removes sensitive or internal API documentation to clarify usage boundaries, which is positive for public API hygiene. It fulfills its stated purpose without introducing regressions or inconsistencies. However, the broader context of documentation and user guidance around structured tools should be updated to maintain clarity and usability.

The recommended follow-up actions above will help fully align the project’s documentation and communication strategy, minimize user confusion, and provide smooth migration or usage paths.

---

If desired, I can assist with drafting example changelog entries or user notice markdown snippets for easier integration.