Skip to main content
Version: v2.0

Tools and integrations

Tools are how an agent does anything outside the chat. This page covers what a tool is, how the agent chooses one, and the two places tools come from.

A tool is one action, not one product​

An agent does not get "GitHub". It gets "create an issue", "read a pull request", and "comment on a pull request", each as its own tool with its own name and description.

Actions are the right size for two reasons.

The agent picks per action. When it needs to leave a comment, it calls the comment tool. Nothing forces it to reason about an entire product surface to find the one thing it needs.

Permissions apply per action. An agent can read pull requests on its own and still wait for your approval before it writes anything, because reading and writing are different tools.

Built-in integrations​

Agenta ships with hundreds of built-in integrations, covering mail, chat, calendars, documents, issue trackers, and CRMs. Connect the account once, add the actions you want to the agent, and the agent can take them.

Adding tools is one of the things you can ask the agent to do while you build it. Say you want it working with GitHub, and it can find the matching tools, add them to its own configuration, and ask you to connect the account. See Build your first agent.

MCP servers​

The Model Context Protocol (MCP) is an open standard for offering tools to an agent. An MCP server is a small program that publishes a set of actions over that standard. Point an agent at the server and it gains those actions, described the same way every other tool is described.

Add one when the agent needs a system that has no built-in integration: an internal service, a database, a product niche enough that nobody built an integration for it. Many products and open-source projects publish their own MCP server, and those work in Agenta without any code from you. If none exists, you can write one.

Add an MCP server covers connecting one.

How the agent chooses​

Every turn, the agent sees the list of tools it has, with each tool's name, description, and arguments. It matches those descriptions against the task in front of it and calls the ones that fit.

The harness does the calling. When the model says it wants to run a tool, the harness runs it, takes the result, and hands it back so the model can continue. The agent then decides what to do next, which is often another tool call.

This has a cost. Tool names and descriptions are part of the always-loaded context, so every tool you add is paid for on every turn, whether or not it gets used. A long tool list also gives the model more near-matches to choose between. See one budget: the context window.