Tools

A tool is a capability the agent can call: a function with a name, a description, and an input shape. Tools are how an agent takes action — search a database, send an email, file a ticket, run a shell command.

The shape of a tool

Every tool shares the same three fields:

• Name — how the agent refers to it (e.g. search_tickets).
• Description — what it does, written for the model.
• Input schema — the JSON shape of arguments the tool accepts.

From the agent's perspective, a tool is opaque: it calls the name, passes the arguments, and gets a result. The tool's implementation — local function, remote HTTP call, MCP server, shell command — is the platform's concern.

Where tools come from

Levain supports tools from several sources:

• MCP servers. Model Context Protocol servers connected as workspace integrations — register once, reuse across agents.
• Knowledge Base. A built-in tool every agent can use to search and read your workspace's wiki. The wiki holds the workspace-specific facts an agent should defer to at runtime — tone, policies, customer-specific context — so that a single agent template can serve many customers without baking those facts into the recipe.
• Shell commands. For infrastructure work, file manipulation, and scripts you already trust.
• Built-in tools. File reading, web search, and other common capabilities provided by Levain.

Why the same shape everywhere

Because tools share a single interface, swapping one for another doesn't require rewriting the agent. If you switch from one ticketing system to another, you register a new tool with the same name and the agent keeps working. The agent's instructions stay stable; the wiring changes underneath.

Tool management is workspace-scoped. See the Integrations guide for connecting MCP servers and OAuth providers, or reach out for help wiring up a custom tool.