Skip to main content

Using tools

On their own, AI models can only produce text. Tools are what let an agent actually do things — read and write documents, browse the web, query a database, open a pull request, check a calendar, control a machine. OtoDock's tools are built on the open Model Context Protocol (MCP), so the platform speaks a common language with a huge ecosystem of existing tools, and you can build your own.

What a tool is​

A tool (an MCP) is a small server that exposes one or more abilities to an agent. OtoDock ships with a solid set built in, integrates with popular services, and lets you install more from the community catalog. The agent doesn't care how a tool is implemented — it just sees a set of abilities it can use, with instructions on how.

Two switches: authorized and enabled​

Whether an agent can use a given tool comes down to two independent decisions:

  1. Authorized (admin) — the tool is made available to agents. Many tools are available to every agent automatically once installed (an admin can still enable or disable any optional tool platform-wide). Others — those that need admin-managed setup, like an SSH host or a metrics server — become available only after an admin configures and assigns them to an agent (or to all agents) from Admin → MCP Servers.
  2. Enabled (manager) — the agent's manager turns an available tool on for that agent, from the agent's MCPs settings.

A tool runs only when it's both authorized and enabled. This split keeps everyone's intent intact: if an admin temporarily removes a tool, a manager's choice to use it is remembered and springs back when it's available again.

How an agent knows how to use a tool​

When a tool is enabled for an agent, OtoDock loads any instructions it ships into the agent's prompt — short how-to guidance so the agent knows what the tool does and how to call it (not every tool needs them). Some tools also inject live context — like which account is connected — so the agent starts each session already informed.

Credentials and configuration​

Tools vary in what they need:

  • Nothing — many tools just work once enabled.
  • An account — services like Google or GitHub need you to connect an account. See Integrations.
  • Configuration — infrastructure tools (a metrics server, an SSH host) need an address and credentials, set up by an admin.

Some tools support more than one setup: an admin can configure several instances of an infrastructure tool (for example multiple SSH hosts, each with its own key) and assign them to agents, and you can connect multiple accounts to an integration — marking one as your default, and optionally pinning a specific account to a specific agent. OtoDock uses the right one for each session.

Where a tool runs​

Tools run in a few different ways, and OtoDock handles the differences for you:

  • Local tools run alongside the agent, inside its sandbox.
  • Service tools connect over the network to a service — for example a vendor's hosted MCP endpoint.
  • Containerized tools run in their own isolated container for heavier jobs like browser automation or document conversion.

Core vs. optional​

  • Core tools are on by default for every agent — the essentials most agents rely on (see Built-in Tools). A manager can still turn a core tool off for a specific agent that doesn't need it.
  • Everything else is opt-in — turned on per agent by its manager.

Next steps​