Tools and agent protocols

A tool gives a model access to a capability outside text generation: retrieving data, computing a result, or requesting an action. The model selects a tool and arguments; the runtime executes the call and returns its result as context.

Local and remote capabilities

Function tools run application methods. Components offered as tools give the model access to your domain state and processes, with the persistence and concurrency behavior of those components. Share tool implementations when several agents need the same capability.

The Model Context Protocol (MCP) connects agents to remote tools. An Akka agent can consume a remote MCP server, while an MCP endpoint exposes tools, resources, and prompts from your service to clients. These are opposite directions of the same integration.

Agent-to-Agent (A2A) supports communication across agent systems. Inside an Akka service, the component client and coordination capabilities provide direct access without requiring a remote protocol for every call.

Discovery and coordination

The agent registry identifies the agents in a service and supports lookup by identifier or role. Dynamic lookup is useful for a custom planner, but request compatibility is checked at runtime rather than by a typed method call.

A tool is appropriate for a lookup or action within an interaction. A task gives work its own identity and observable lifecycle. A separate agent adds its own purpose and context. Choose the smallest unit that captures those needs.

For a process that must survive failure, make remote work part of a workflow step or a durable agent task. Network protocols alone do not provide recovery of the calling process.

Limits and trade-offs

A broad tool set increases prompt size and makes selection harder. Remote tools add network latency and another system’s failure modes. Limit tool-call steps, validate arguments, and apply controls before allowing consequential actions. Support for media in tool results depends on the model provider.

Next steps