# Write Once, Run Anywhere: Universal Tools for AI Agents

> Source: <https://dev.to/agent-kernel/write-once-run-anywhere-universal-tools-for-ai-agents-1mmg>
> Published: 2026-10-06 10:32:57+00:00

*By [Yaala Labs](https://github.com/yaalalabs)*

**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:

``` php
# OpenAI version
@function_tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# CrewAI version  
@tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# LangGraph version
@tool
def get_weather(city: str) -> str:
    return f"Weather in {city}: sunny"

# Google ADK version
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:

``` php
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:

``` python
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:

```
# Sync tools use 'func' parameter
StructuredTool.from_function(func=my_tool)

# Async tools use 'coroutine' parameter
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:

```
# Set once before calling agent
context.set()

# Access anywhere in your tool
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:

``` python
# ADK calls your tool like this:
def my_tool(city: str, tool_context: ADKToolContext):
    # ADK's context, not yours
```

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 automatically`ToolContext`
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:

``` python
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:

``` php
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:

``` php
from agentkernel.core import ToolContext

def get_weather(city: str) -> str:
    """Returns the weather for a given city."""
    # Get information about the current execution
    ctx = ToolContext.get()

    session = ctx.session      # Who's asking?
    agent = ctx.agent          # Which agent is calling this?

    # Example: Use session data for personalization
    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:

``` python
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}."

# Create agents
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:

``` python
from agentkernel.langgraph import LangGraphModule, LangGraphToolBuilder
from langgraph.prebuilt import create_react_agent

# Same get_weather function - no changes!

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.",
)

# Define other agents...
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:

``` php
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)

# Works with any framework automatically
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:

``` python
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:

``` python
# Local tool - just a function
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)

# Use it immediately
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.

```
# Local: Direct call, ~microseconds
result = calculate_price(100, "widget")

# MCP: Network round-trip, ~10-100ms
result = await mcp_client.call_tool("calculate_price", {...})
python
# Test local tools like any Python function
def test_bulk_discount():
    price = calculate_price(quantity=100, item_type="widget")
    assert price < calculate_price(quantity=10, item_type="widget")

# MCP tools require running a server, mocking network calls, etc.
```

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 for your business logic
local_tools = OpenAIToolBuilder.bind([
    calculate_price,
    format_invoice,
    check_inventory,
])

# MCP tools for external services (if needed)
# Connect to MCP server for shared document search
mcp_tools = await connect_to_mcp_server("company-docs")

# Use both together
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."""
    # Your code here
    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](https://kernel.yaala.ai/blog/framework-agnostic-tool-binding) on February 18, 2026.*