Tools and MCP
A tool in AEL, the Agent Engineering Language, is a typed operation that a model-driven node may ask to call, with its own permission. The model proposes a call; your program checks it and decides whether it runs. A built-in MCP client discovers and calls MCP tools, and an optional package exposes your agents as MCP tools.
What a tool declares
Each tool is ordinary AEL code with:
| Part | Meaning |
|---|---|
| Name | How the model and your settings refer to it. |
| Input type | The typed arguments it accepts. |
| Output type | The typed result it returns. |
| Permission | The one capability it needs, which the node must have been granted. |
| Repeat safety | Whether a call can be repeated safely: see Retrying tools. |
A model-driven node lists the tools its model may use. The model can propose only those; a name outside the list is refused. A deterministic node calls functions directly and needs no tool list.
tool is a reserved word of the language.
Every call is checked
Before a proposed call runs, AEL checks, in this order, that:
- the tool is on the node's list;
- the arguments decode into the tool's input type, within their size limits;
- the permission is granted to this node, for this caller and this tenant;
- the run's budget has room for the call.
The permission is checked again immediately before the tool acts. A tool's result goes back to the model as data, within a size limit. Neither a tool's description nor its result can widen what the node is allowed to do.
Tools from skills
A skill is a versioned, reusable bundle of instructions, typed tools and functions that an agent or subagent loads through the skills it declares; its tools run only where the agent's permissions allow, and it adds nothing the agent did not declare. A skill's tool goes through the same checks as every other tool, and the check refuses a skill whose tool needs a permission the agent does not have. Skills describes them.
The tool loop
With the bounded loop model policy, a node repeats these steps:
- Call the model with the input, the tool descriptions and the results so far.
- If the model returns a final result, check it and finish.
- If it proposes a tool call, check the call, run the tool and add its result.
- Stop at completion, cancellation, the deadline or the end of the budget.
The number of steps and of tool calls is always bounded: there is no "keep going until done". Under the exactly-one-call policy, a tool that would need a second model call is refused. Models and providers lists the policies.
Retrying tools
Each tool says how a failed call may be repeated:
| Repeat safety | Meaning | After a failure |
|---|---|---|
| Never | The call must not be repeated automatically. | No retry. |
| Idempotent | Repeating the call has the same effect as making it once, so a temporary failure can be retried. | Retried within your attempts and budget. |
| Reconcile | The call may have changed something outside the program before its reply was lost. | No blind retry: the outcome is reported as uncertain, for your code to reconcile. |
An idempotency key names one logical effect across attempts, so a service can recognize a repeat. Budgets, retries and validation describes retries in full.
MCP tools
The MCP client is part of the language: calling MCP tools needs no package.
- It lists the tools an MCP server offers and calls the ones you authorize, over a network connection.
- Each tool's input and output schemas become AEL types, with bounded decoding. A schema that cannot be represented, or a tool definition that changes, is refused before any call.
- Tool descriptions and results are untrusted data. They cannot expand a node's permissions, reset its attempts or become instructions.
- Every call carries the run's tenant, permissions and budget, and a disconnect, a cancellation, a denied tool or a malformed response is a typed outcome.
- Starting a local MCP server as a separate process needs the optional package for running processes; see Files and processes. Listing tools over the network never grants the right to start processes.
Exposing agents as MCP tools
The optional server/mcp package lets other programs call your agents as MCP tools. You add it to pack.ael only when you want that: the MCP client never brings a server with it. Using packages describes how to add a package, and Services and APIs how one agent can serve several protocols.
Services
Code calls a typed service, and the deployment decides whether it runs in the same process, on another machine, over HTTPS or over gRPC. Moving a service changes its deployment, not the code that calls it.
Your own edges are placed the same way: the same edge runs in one process, between processes or over the network, as your deployment places it, with no change to your source. Communication between agents describes the channel every edge gets.
Connections are resilient, with idempotency-aware retries, backpressure, circuit breakers and health checks. A timed-out call is never taken to mean that the other side did nothing.
Your own connectors
You write your own connectors for services, models, knowledge sources, transports and log sinks, in AEL. A connector declares its types, its permissions and its limits like any other code, and runs within the same budget and checks as the node that uses it.