By Yaala Labs
Stop rewriting the same tools for different AI frameworks.
Imagine building a calculator app, then discovering you need to rebuild it from scratch every time you want to run it on a different device. That's what building AI agent tools feels like today.
Write a weather lookup tool for OpenAI? It won't work with Google's framework. Build it for CrewAI? Start over if you switch to LangGraph. This wastes time and creates headaches every time you want to try a new AI framework.
Agent Kernel solves this: write your tools once, use them everywhere.
Think of tools as capabilities you give your AI agent—like looking up weather, searching a database, or sending emails. Right now, each AI framework requires you to write these tools in a completely different way.
Here's the same weather tool written for four different frameworks:
@function_tool
def get_weather(city: str) -> str:
return f"Weather in {city}: sunny"
@tool
def get_weather(city: str) -> str:
return f"Weather in {city}: sunny"
@tool
def get_weather(city: str) -> str:
return f"Weather in {city}: sunny"
def _get_weather(city: str) -> str:
return f"Weather in {city}: sunny"
get_weather = FunctionTool(_get_weather)
It's the same weather lookup, but you have to write and maintain four different versions.
Want to switch frameworks? Rewrite everything. Want to try a new framework alongside your current one? Duplicate all your tools. Building 10 custom tools means maintaining 40 versions if you use all four frameworks.
With Agent Kernel, you write your tools as regular Python functions—no special decorators or framework-specific code:
def get_weather(city: str) -> str:
"""Returns the weather for a given city."""
return f"Weather in {city}: sunny, 25°C"
That's it. Just a normal Python function with a helpful description. Then use it with any framework you want.
Once you've written your tool as a normal Python function, you can add it to agents in any framework. The only thing that changes is one line of code:
from agents import Agent
from agentkernel.openai import OpenAIToolBuilder
weather_agent = Agent(
name="weather",
instructions="You provide weather information.",
tools=OpenAIToolBuilder.bind([get_weather]), # ← Add your tool here
)
python
from crewai import Agent
from agentkernel.crewai import CrewAIToolBuilder
weather_agent = Agent(
role="weather",
goal="You provide weather information",
backstory="Use the get_weather tool for queries.",
tools=CrewAIToolBuilder.bind([get_weather]), # ← Add your tool here
)
python
from langgraph.prebuilt import create_react_agent
from agentkernel.langgraph import LangGraphToolBuilder
weather_agent = create_react_agent(
name="weather",
tools=LangGraphToolBuilder.bind([get_weather]), # ← Add your tool here
model=model,
prompt="Use the get_weather tool for queries.",
)
python
from google.adk.agents import Agent
from agentkernel.adk import GoogleADKToolBuilder
weather_agent = Agent(
name="weather",
model="gemini-2.0-flash-exp",
description="You provide weather information",
tools=GoogleADKToolBuilder.bind([get_weather]), # ← Add your tool here
)
Same get_weather function. Works everywhere.
The .bind() method translates your normal Python function into whatever format each framework needs. You don't have to worry about the details—just write your function once and use it anywhere.
Making tools work across frameworks sounds simple, but it's actually quite challenging. Each framework has its own way of handling tools, and these differences create real technical problems.
Frameworks handle async/sync functions differently:
LangGraph (LangChain) requires you to specify whether a tool is async or sync upfront:
StructuredTool.from_function(func=my_tool)
StructuredTool.from_function(coroutine=my_async_tool)
OpenAI Agents SDK automatically handles both, but wraps them differently internally.
Google ADK expects all tools to potentially receive a tool_context parameter from the framework itself, which other frameworks don't provide.
Agent Kernel detects whether your function is async or sync and generates the right code for each framework automatically. You just write def or async def.
This is the hardest problem: frameworks provide execution context (session info, runtime state) in completely different ways.
OpenAI, CrewAI, LangGraph work well with Python's standard contextvars, which lets you set context in one place and access it anywhere in the call stack:
context.set()
ctx = ToolContext.get()
Google ADK manages its own execution context internally and doesn't reliably propagate Python's contextvars. Instead, it passes a tool_context parameter to every tool function:
def my_tool(city: str, tool_context: ADKToolContext):
This means your tool function signature must be different for ADK versus other frameworks. Or does it?
Agent Kernel solves this by:
tool_context parameter automaticallyToolContext
All this happens behind the scenes. You write one function, and it works everywhere.
Each framework expects different information about your tool:
| Framework | Name Source | Description Source | Schema Generation |
|---|---|---|---|
| OpenAI | Function name | Docstring | Automatic from type hints |
| CrewAI | Function name | Docstring | Automatic from type hints |
| LangGraph | Must specify | Must specify or falls back to function name | Must extract from function |
| Google ADK | Function name | Function name if no docstring | Type inspection required |
Agent Kernel extracts metadata once from your Python function (name, docstring, parameters, types) and formats it appropriately for each framework.
When a tool raises an exception, frameworks handle it differently:
Agent Kernel doesn't hide these differences (they're tied to framework behavior), but it ensures your tool code doesn't need to know which framework is calling it.
Each framework's tool classes come from different packages:
from agents import function_tool # OpenAI
from crewai_tools import tool # CrewAI
from langchain_core.tools import StructuredTool # LangGraph
from google.adk.tools import FunctionTool # Google ADK
If you write tools using framework-specific decorators, you're locked in. Agent Kernel's ToolBuilder classes handle these imports internally, so your tool code has zero framework dependencies.
Here's what Agent Kernel does behind the scenes for a single tool:
ToolContext.get() works in your tool
All so you can write this:
def my_tool(param: str) -> str:
"""Does something useful."""
return result
tools = AnyFrameworkToolBuilder.bind([my_tool])
This simplicity is hard-won. Framework-agnostic tools require handling edge cases most developers never see.
Sometimes your tools need to know things like "which user is asking?" or "what session is this?" Agent Kernel provides this information in a consistent way, regardless of which framework you're using:
from agentkernel.core import ToolContext
def get_weather(city: str) -> str:
"""Returns the weather for a given city."""
ctx = ToolContext.get()
session = ctx.session # Who's asking?
agent = ctx.agent # Which agent is calling this?
user_prefs = session.get_non_volatile_cache().get("preferences", {})
units = user_prefs.get("temperature_units", "celsius")
return f"Weather in {city}: sunny, 25°C"
This works the same way across all frameworks—you don't need to learn different methods for each one.
Here's a complete example using OpenAI:
from agentkernel.core import ToolContext
from agentkernel.openai import OpenAIModule, OpenAIToolBuilder
from agents import Agent
def get_weather(city: str) -> str:
"""Returns the weather for a given city."""
if city == "Tokyo":
return "The weather in Tokyo is sunny."
else:
return f"Cannot find weather for {city}."
weather_agent = Agent(
name="weather",
instructions="Use the get_weather tool for weather questions.",
tools=OpenAIToolBuilder.bind([get_weather]),
)
math_agent = Agent(
name="math",
instructions="You help with math problems.",
)
triage_agent = Agent(
name="triage",
instructions="Route questions to the right agent.",
handoffs=[math_agent, weather_agent],
)
OpenAIModule([triage_agent, math_agent, weather_agent])
Want to try LangGraph instead? Change just the framework-specific parts:
from agentkernel.langgraph import LangGraphModule, LangGraphToolBuilder
from langgraph.prebuilt import create_react_agent
weather_agent = create_react_agent(
name="weather",
tools=LangGraphToolBuilder.bind([get_weather]), # Different builder
model=ChatOpenAI(model="gpt-4o-mini"),
prompt="Use the get_weather tool for weather questions.",
)
LangGraphModule([triage_agent, math_agent, weather_agent])
Your get_weather function? Completely untouched. No rewriting. No debugging. Just works.
If your tool needs to do asynchronous work (like database queries or API calls), just write it as an async function:
async def search_database(query: str, limit: int = 10) -> str:
"""Searches the database for matching records."""
results = await db.search(query, limit=limit)
return str(results)
tools = OpenAIToolBuilder.bind([search_database])
tools = LangGraphToolBuilder.bind([search_database])
tools = GoogleADKToolBuilder.bind([search_database])
Agent Kernel handles the async details for you—just write your function normally.
Real agents usually need multiple tools. Just add them all to the list:
tools = OpenAIToolBuilder.bind([
get_weather,
search_database,
send_email,
get_user_profile,
])
agent = Agent(
name="assistant",
instructions="You're a helpful assistant with multiple tools.",
tools=tools,
)
All tools work together seamlessly, regardless of your framework.
Want to see if LangGraph is better than OpenAI for your use case? Just switch. Your tools keep working. No migration project needed.
Test your tools as regular Python functions:
def test_get_weather():
result = get_weather("Tokyo")
assert "sunny" in result.lower()
No complicated framework setup. No mocking. Just normal Python testing.
Your tools are just functions. Easy to read. Easy to understand. Easy to maintain. No framework magic hiding what your code does.
New developers don't need to learn framework-specific tool systems. They write regular Python functions. Everything else is handled automatically.
You might have heard of MCP (Model Context Protocol) and wonder: "Should I use MCP for my tools, or build them locally?"
The answer depends on what your tools do. Let's break it down simply:
MCP is designed for connecting to external tool servers that run as separate processes. Think of it like calling a web API or external service.
Use MCP when:
MCP Example:
Your Agent → Network → MCP Server → External Database
Agent Kernel's tool binding is for tools that are part of your agent's business logic—functions that live in your codebase alongside your agents.
Use local tool binding when:
Local Tool Example:
Your Agent → Direct Function Call → Your Code
For most business logic, building tools directly in your agent code is simpler and more efficient:
def calculate_price(quantity: int, item_type: str) -> float:
"""Calculate price with discounts."""
base_price = PRICES[item_type] * quantity
discount = get_bulk_discount(quantity)
return base_price * (1 - discount)
tools = OpenAIToolBuilder.bind([calculate_price])
With MCP, you'd need to:
Local tools are just function calls—microseconds. MCP involves network requests—milliseconds or more. For tools that run frequently, this adds up.
result = calculate_price(100, "widget")
result = await mcp_client.call_tool("calculate_price", {...})
python
def test_bulk_discount():
price = calculate_price(quantity=100, item_type="widget")
assert price < calculate_price(quantity=10, item_type="widget")
When something goes wrong with a local tool, your debugger works normally. Step through your code, inspect variables, see the full stack trace.
With MCP, you're debugging across process boundaries and network calls. Much harder.
Local tools deploy with your agent—one Docker container, one deployment. MCP tools need separate infrastructure, monitoring, and coordination.
Don't get us wrong—MCP is valuable for the right use cases:
Shared Corporate Tools:
Your company has a central "Employee Directory" service used by 50 different AI agents. One MCP server, everyone connects to it.
External Services:
You're integrating with a third-party tool provider (like a specialized search engine or data enrichment service) that offers MCP access.
Language Boundaries:
Your tool is written in Rust for performance, but your agent is in Python. MCP lets them communicate.
Heavy Resources:
Your tool needs 64GB of RAM and a GPU. Run it on a dedicated server via MCP instead of bundling it with every agent instance.
Start with local tools. They're simpler, faster, and easier to build and test.
Only use MCP when you have a specific reason:
For most business logic—data formatting, calculations, querying your own databases, calling your internal APIs—local tools are the right choice.
Agent Kernel supports both approaches. Use local tools for your custom logic, and connect to MCP servers when you need external capabilities:
local_tools = OpenAIToolBuilder.bind([
calculate_price,
format_invoice,
check_inventory,
])
mcp_tools = await connect_to_mcp_server("company-docs")
agent = Agent(
name="sales_assistant",
tools=local_tools + mcp_tools,
)
The key insight: Local tools and MCP serve different purposes. Don't add MCP complexity unless you need it. For most agent development, simple local tools are the better choice.
When you write a tool as a normal Python function, Agent Kernel automatically extracts everything the AI needs to know:
The AI sees the same tool, no matter which framework you use.
Using framework-agnostic tools is simple:
pip install agentkernel
php
def my_tool(param: str) -> str:
"""Description of what this tool does."""
return result
python
from agentkernel.openai import OpenAIToolBuilder
from agents import Agent
agent = Agent(
name="my_agent",
instructions="Use my_tool when needed.",
tools=OpenAIToolBuilder.bind([my_tool]),
)
That's all. Three steps, and your tool works across all frameworks.
Stop maintaining multiple versions of the same tool.
Write your tools once. Test them once. Use them everywhere. That's the promise of framework-agnostic tools in Agent Kernel.
Try different frameworks. Migrate painlessly. Focus on building great tools, not maintaining duplicates.
Start building framework-agnostic tools today. Your future self will thank you.
Originally published at kernel.yaala.ai on February 18, 2026.