feat: add Klavis tools

[zihaolin96]

Add Klavis MCP Server Tools Integration

Summary

This PR adds support for integrating CrewAI agents with Tools from Klavis MCP servers, enabling agents to interact with hundreds of integration and automate complex workflows.

What's Added

• KlavisMcpServerTool: A new tool class that wraps Klavis MCP server functionality
• KlavisMcpServerAdapter: Adapter class for connecting to and managing Klavis MCP servers
• KlavisMcpServerTools: Factory function for creating CrewAI-compatible tools from MCP servers

Appendix

• Klavis AI repo
• Klavis AI docs
• Klavis AI website

Demo

https://www.youtube.com/watch?v=hZ5oqBMk-fQ

[joaomdmoura]

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

Code Review Comment for Klavis Tools Integration PR

Overview

The integration of Klavis MCP (Model Context Protocol) servers into the CrewAI tools is a significant enhancement. The changes introduced a new tool class in Python along with comprehensive documentation. Here's a detailed review based on the analysis of each modified file.

1. crewai_tools/tools/init.py

• Change Summary: The addition of the KlavisMcpServerTools import.
• Review: The change is straightforward and appears to be implemented correctly, enabling access to the new tools functionality.

2. crewai_tools/tools/klavis_tool/README.md

Strengths

• Structured Documentation: The README is well-organized, making it easy for users to follow.
• Examples Provided: The inclusion of code examples enhances usability.
• Comprehensive Sections: Covers installation, usage, and configuration thoroughly.

Suggestions

• Version Compatibility: Include explicit version compatibility with CrewAI to guide developers.
• Error Handling: Add examples illustrating common error handling scenarios when using the tools.
• Examples for Specific MCP Servers: Provide tailored examples for various types of MCP servers, enhancing practical usage guidance.

3. crewai_tools/tools/klavis_tool/klavis_tool.py

Code Quality Issues

1. Type Hints Improvement:

   • Current: klavis_client: Any = Field(description="Klavis client instance")
   • Suggestion: Specify type as Klavis for clarity.

2. Enhancement of Error Handling:

   • Current Handling: General error handling in the _run method.
   • Suggestion: Distinguish exceptions such as ConnectionError for better debugging.

3. Input Validation Necessity:

   • Current State: Lack of parameter validation for API keys and URLs.
   • Suggestion: Validate inputs for klavis_api_key and mcp_server_url to ensure they conform to expected formats.

4. Logging Improvements:

   • Current Implementation: Utilizes print statements.
   • Suggestion: Employ structured logging (e.g., using logger) to maintain consistent logging practices.

5. Documentation Expansion:

   • Enhance class and method docstrings to include detail about attributes and exceptions raised, improving maintainability.

General Recommendations

1. Testing: Implement thorough unit and integration tests for the KlavisMcpServerTool class. Testing edge cases will ensure robustness.
2. Code Organization: Consider modularizing the adapter logic for better maintainability.
3. Performance: Introduce caching for tool listings to enhance performance.
4. Security Measures: Strengthen security by implementing input validation, URL sanitization, and rate limiting for API calls.

Style and Standards

• The code adheres to PEP 8 guidelines and utilizes type hints effectively (though enhancements are possible).
• The naming conventions contribute positively to code readability, and error handling is generally in place.

Missing Features

1. Timeout Handling
2. Retry Mechanism
3. Rate Limiting
4. Tool Response Validation
5. Async Support

Summary of Changes Needed

1. Improve type hints for clarity and accuracy.
2. Strengthen error handling by refining exception specificity.
3. Transition from print statements to logging.
4. Validate inputs thoroughly for critical parameters.
5. Expand documentation to cover additional use cases.
6. Increase test coverage from unit testing to integration testing.
7. Consider caching solutions for optimal performance.
8. Implement security best practices proactively.

The Klavis tools integration represents a robust addition to the CrewAI ecosystem. Addressing the highlighted improvements will further enhance the quality and readiness for production use, ensuring the implementation is both resilient and user-friendly.

[lucasgomide]

Hey @zihaolin96, that's an amazing feature; great work! I'd love to discuss how we can integrate it more smoothly with our official MCPServer.

Instead of adding multiple MCPServer tools, each with its own implementation and specification, I think it would be better to define a unified interface for communicating with them. This could be a huge improvement, especially now that we've already integrated the official version into the main repo.

I'm totally open to supporting multiple enterprise server tools, but I think we should give some more attention to how they're used, so we can keep things simple and consistent.

Another point of view is that MCP Enterprise servers are so unique that it might not be worth integrating them using the official MCPServer approach from CrewAI.

gentle ping @lorenzejay would love to hear your thoughts on this when you get a chance!

[lucasgomide]

@zihaolin96 would you mind sharing a Loom using this Tool with a CrewAI agent?

Just noticed you already did

[lucasgomide]

Ok.. I have a UX question after watching your demo

Can we make the OAuth flow smoother? From what I understand, requiring the user to open a browser to authorize isn't a great experience.. especially since many of our users run Crew in Docker containers. In those cases, the current solution just isn't feasible. It could also be frustrating for open-source and Enterprise users use that. Let me know if do you have another way to do that.

[zihaolin96]

Hey @zihaolin96, that's an amazing feature; great work! I'd love to discuss how we can integrate it more smoothly with our official MCPServer.

Instead of adding multiple MCPServer tools, each with its own implementation and specification, I think it would be better to define a unified interface for communicating with them. This could be a huge improvement, especially now that we've already integrated the official version into the main repo.

I'm totally open to supporting multiple enterprise server tools, but I think we should give some more attention to how they're used, so we can keep things simple and consistent.

Another point of view is that MCP Enterprise servers are so unique that it might not be worth integrating them using the official MCPServer approach from CrewAI.

gentle ping @lorenzejay would love to hear your thoughts on this when you get a chance!

Thanks @lucasgomide
I'm not sure if I understand correctly, as a Klavis user experience, they just need to connect to MCP Server with same API and just change serverName , they don't have to worry about what tools since we'll work to handle all their needs.

And within Klavis tool design, are you suggesting to have a generic tool schema for all ? (reminds me of merge.dev)

would appreciate your reply and feedback!

[zihaolin96]

Ok.. I have a UX question after watching your demo

Can we make the OAuth flow smoother? From what I understand, requiring the user to open a browser to authorize isn't a great experience.. especially since many of our users run Crew in Docker containers. In those cases, the current solution just isn't feasible. It could also be frustrating for open-source and Enterprise users use that. Let me know if do you have another way to do that.

@lucasgomide good question!

technically seems doable - e.g. "Non-interactive grants (Client-Credentials, Service-Account / JWT Bearer, Refresh-Token reuse) can be completed 100 % server-to-server." from LLM.

honestly, at Klavis we did think this before, but haven’t implemented it yet, as none of our customers have needed it so far. But it’s def something we plan to look into. e.g. one of our enterprise customers wants to support fine-grained control over MCP servers for different departments / levels, which likely falls into this technical category.

[lucasgomide]

@zihaolin96 Got it

Let's consider that these operations will be performed by Agents/automation processes, which in most cases don't have a person available to click through or authorize OAuth2 (or any other interactive authentication). That's why I suggested the API_KEY approach.. it’s much more feasible in this context.

Your code looks fine to me, but I'm not sure we should allow it to be executed by a Crew, since it doesn't seem ready to be run by an Agent.

[zihaolin96]

@zihaolin96 Got it

Let's consider that these operations will be performed by Agents/automation processes, which in most cases don't have a person available to click through or authorize OAuth2 (or any other interactive authentication). That's why I suggested the API_KEY approach.. it’s much more feasible in this context.

Your code looks fine to me, but I'm not sure we should allow it to be executed by a Crew, since it doesn't seem ready to be run by an Agent.

@lucasgomide thanks for the update! we also support API_Key for sure with just one api call, and that's how our no-code platform works for MCP Server / Apps (e.g. firecrawl, resend, openrouter, etc...) that doesn't support OAuth. And in this PR I only demo the OAuth because it's more complicated from coding perspective.

let me know if you have any question! Thank you!