Built-in tools

Tools are functions the model can decide to call while answering. Every agent on the platform gets two built-ins — run_python and search_memory — and can bring its own. This page covers what the built-ins do, how tool calls show up in responses, and where your tool code actually runs.

The two built-in tools

Tool	What it does	Limits
run_python(code)	Runs a Python snippet in an isolated, single-use code sandbox pod and returns its output	20 s execution timeout; no network access except DNS
search_memory(query)	Searches this agent's long-term memory bank and returns the top 5 matching snippets	Read-only; searches only this agent's own collection

run_python is how an agent does real computation — math, parsing, data wrangling — instead of guessing. Each snippet runs in a throwaway pod that is destroyed afterward and never reused, so model-generated code can't touch your agent's credentials or the network. See security and limits for the isolation details.

Give your agent the tools

The built-ins ship in the platform SDK baked into every agent image. Import them per framework:

ADK — pass them to your agent:

from google.adk.agents import Agent
from crusoe_adk.foundry import foundry_model
from crusoe_adk.tools import run_python, search_memory

root_agent = Agent(
    name="my_agent",
    model=foundry_model(),
    instruction="Use run_python for math and search_memory to recall facts.",
    tools=[run_python, search_memory],
)

LangGraph — the helpers live in the crusoe_langchain package:

import crusoe_langchain as crusoe

CrewAI — the helpers live in the crusoe_crewai package:

import crusoe_crewai as crusoe

See the framework guides for full working examples: ADK, LangGraph, CrewAI.

How tool calls appear in responses

A plain invoke response lists every tool the agent used in tool_calls:

{
  "output": "2**32 is 4294967296.",
  "tool_calls": [
    {"name": "run_python", "summary": "called with args={'code': 'print(2**32)'}"}
  ]
}

A streaming invoke emits two dedicated line types, in order, as they happen:

{"type":"tool_call",  "name":"run_python", "args":{"code":"print(2**32)"}}
{"type":"tool_result","name":"run_python", "result":"4294967296\n"}

The full detail — arguments and results as the model saw them — is also in the transcript: session events carry function_call and function_response parts. The CLI prints one tool_call: <name> called with args={...} line per call.

Your own tools run in a sandbox too

Agents can define their own tools (any function your framework registers). By default the platform relocates user-defined tool code into single-use sandbox pods at startup — a feature called tool-call sandboxing, controlled by the TOOL_SANDBOX environment variable (on by default).

How it works: when the model calls one of your tools, the platform starts a one-use pod from your agent's own image — same code, same dependencies — but stripped of every platform credential. The empty environment is the security boundary: a prompt-injected or buggy tool can't read your API keys or reach internal services.

What that means in practice:

• Tool calls default to a 30-second timeout, with a maximum of 120 seconds.
• Sandboxed tool pods can reach the public internet (so tools that call external APIs work), but not cloud metadata or private network ranges.
• There is no warm pool for tool pods: every sandboxed tool call pays pod scheduling and image pull, so the first call is slow (the pod gets up to 110 seconds to become ready).
• If the sandbox is unreachable, the harness fails closed — it never silently runs the tool in the agent pod instead.
• Set the env var TOOL_SANDBOX=false on the agent to opt out and run tool code inside the agent pod, next to its credentials. Only do this for tools you fully trust.

Credentials inside sandboxed tools

A sandboxed tool pod has no platform env vars, so a tool that needs a credential should fetch it at call time from the secrets manager rather than read os.environ.

Tools from MCP servers

The platform also hosts MCP servers — a standard way to publish tools that agents and other clients (like desktop AI apps) can call over the network. If you want to share one set of tools across several agents, or expose tools to clients outside the platform, publish them as an MCP server instead of baking them into one agent. See connect agents and clients.

Quick reference

Question	Answer
What tools does every agent get?	run_python and search_memory
Where does run_python code run?	A single-use sandbox pod, 20 s limit, DNS-only network
Where do my own tools run?	Single-use pods from your agent's image, credential-free (TOOL_SANDBOX, on by default)
How do I see tool calls?	tool_calls in the invoke response, tool_call/tool_result stream lines, function_call parts in transcripts
Sharing tools across agents?	Publish an MCP server