WIP Tool packages

[tcdent]

Tool Packages

This PR introduces a new way of packaging tools in AgentStack. Tools are now wrapped in a framework-specific layer to allow for our implementations to remain completely generic. Some tools have been reimplemented to work with all frameworks instead of just importing from crewai-tools.

Core Changes

• Tools now get wrapped in a framework-specific layer
• Reimplemented tools to work with all frameworks instead of just importing from crewai-tools
• Removed tools_bundled from ToolConfig as all tools are now bundled for namespacing
• agentstack.tools is not part of the public API and is to be used inside a user project to access tools

Directory Search Implementation

As part of this effort, the directory search tool has been reimplemented as framework-agnostic functions:

• Added two core functions:
  • search_directory(directory: str, query: str): Search any directory
  • search_fixed_directory(query: str): Search preconfigured directory
• Removed dependency on CrewAI's BaseTool
• Uses embedchain.loaders.DirectoryLoader directly
• Framework-specific wrapping handled by frameworks.crewai.get_tool_callables

Environment Variables

• DIRECTORY_SEARCH_PATH: Optional. Path to directory for fixed directory search.

Composio Tool Implementation

The composio tool has been reimplemented as framework-agnostic functions:

• Added core functions:
  • execute_action: Execute specified Composio actions with parameters
  • get_action_schema: Retrieve schema for Composio actions
  • find_actions_by_use_case: Find actions based on use case
  • find_actions_by_tags: Locate actions by specified tags
• Removed dependency on CrewAI's BaseTool
• Uses composio library directly for core functionality
• Framework-specific wrapping handled automatically by agentstack.tools['composio']
• Updated config.json with proper dependencies and CTA field

Environment Variables

• COMPOSIO_API_KEY: Required. API key for Composio service access.

Stripe Tool Implementation

The Stripe tool has been reimplemented as framework-agnostic functions:

• Removed framework-specific dependencies
• Implemented core functions for:
  • Payment links (create/read)
  • Products (create/update)
  • Prices (create/update)
• Uses stripe library directly for core functionality
• Framework-specific wrapping handled automatically

Environment Variables

• STRIPE_SECRET_KEY: Required. API key for Stripe service access.

Link to Devin run: https://app.devin.ai/sessions/24be273939424e7eacea38661326111e

[bboynton97]

lets save this for 0.3 because it will require the project upgrade script. we can merge it now though and create a 0.2 branch for bug fixes and small features

[bboynton97]

one challenge with this implementation is that by not copying the tool into the user's project, we remove the ability for them to modify the tool to best fit their use-case. So for Composio for example, there are a number of ways in which the tool can be adjusted for a specific implementation.

additionally, bundling all tools isn't the best idea. if a tool provider exports 20 tools and the developer only wants one of them, it consumes additional context to give the LLM all 20 tools, as well as creating the opportunity for the LLM to pick the wrong tool.

[tcdent]

one challenge with this implementation is that by not copying the tool into the user's project, we remove the ability for them to modify the tool to best fit their use-case. So for Composio for example, there are a number of ways in which the tool can be adjusted for a specific implementation.

totally. it does have tradeoffs, but adds a few more bonuses:

• as we increase the capability of the tools, users get that for free on upgrade.
• since the docstrings, etc. are dynamically generated and passed to an LLM, we don't need to worry about backwards compatibility
• wrapping the tool with the framework-specific tool format at runtime prevents us form having to maintain multiple tool implementations
• users can still copy the tool source into their project tools dir to modify the implementation

additionally, bundling all tools isn't the best idea. if a tool provider exports 20 tools and the developer only wants one of them, it consumes additional context to give the LLM all 20 tools, as well as creating the opportunity for the LLM to pick the wrong tool.

will think about this. I wanted to incorporate namespacing so it was clear which tool the function was coming from. previously, installing a tool added all of the functions inside the tool package.

after playing with the stripe_agent_toolkit to include their implementation, there might be something to the config format they're using. perhaps our tools get a similar config to indicate what access rights the agents get.

[tcdent]

users can still copy the tool source into their project tools dir to modify the implementation

We can add an -e --editable flag to copy the source to the user's project.

I've been thinking about how we handle custom tools in templates. Still don't have a bright idea, but it would be cool to still be able to package up a project with custom tools and share the template.

additionally, bundling all tools isn't the best idea. if a tool provider exports 20 tools and the developer only wants one of them, it consumes additional context to give the LLM all 20 tools, as well as creating the opportunity for the LLM to pick the wrong tool.

will think about this. I wanted to incorporate namespacing so it was clear which tool the function was coming from. previously, installing a tool added all of the functions inside the tool package.

allowing the user to select which functions they're installing, in addition to the tool, using the new interactive agentstack tools add interface would be easy enough.

*agentstack.tools['tool_name'] for all tools
agentstack.tools['tool_name']['function_name'], ... for selected tools
tools.function_name for tools inside the user's project

just make the branching inside the framework ast editability a bit more complex, but very doable.

moving the installed tools from agentstack.json to conf/tools.yaml would let us track this better