Tools and MCP
A tool in AEL, the Agent Engineering Language, will be a typed operation that a model-driven node may ask to call, with its own permission. The model will propose a call; your program will check it and decide whether it runs. A built-in MCP client will discover and call MCP tools, and an optional package will expose your agents as MCP tools.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
Package names on this page are preview naming and may change before launch.
What a tool declares
Each tool will be 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 will list the tools its model may use. The model will be able to propose only those; a name outside the list will be refused. A deterministic node will call functions directly and need no tool list.
How a tool is declared, and how a node lists its tools, will be confirmed when the syntax is final. tool is a reserved word of the language.
Every call will be checked
Before a proposed call runs, AEL will check, 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 will be checked again immediately before the tool acts. A tool's result will go back to the model as data, within a size limit. Neither a tool's description nor its result will be able to widen what the node is allowed to do.
The tool loop
With the bounded loop model policy, a node will repeat 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 will always be bounded: there will be no "keep going until done". Under the exactly-one-call policy, a tool that would need a second model call will be refused. Models and providers lists the policies.
Retrying tools
Each tool will say 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 will name 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 will be part of the language: calling MCP tools will need no package.
- It will list the tools an MCP server offers and call the ones you authorize, over a network connection.
- Each tool's input and output schemas will become AEL types, with bounded decoding. A schema that cannot be represented, or a tool definition that changes, will be refused before any call.
- Tool descriptions and results will be untrusted data. They will not be able to expand a node's permissions, reset its attempts or become instructions.
- Every call will carry the run's tenant, permissions and budget, and a disconnect, a cancellation, a denied tool or a malformed response will be a typed outcome.
- Starting a local MCP server as a separate process will need the optional package for running processes; see Files and processes. Listing tools over the network will never grant the right to start processes.
Exposing agents as MCP tools
The optional server/mcp package will let other programs call your agents as MCP tools. You will add it to pack.ael only when you want that: the MCP client will never bring 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 will call a typed service, and the deployment will decide whether it runs in the same process, on another machine, over HTTPS or over gRPC. Moving a service will change its deployment, not the code that calls it.
Connections will be resilient, with idempotency-aware retries, backpressure, circuit breakers and health checks. A timed-out call will never be taken to mean that the other side did nothing.
Your own connectors
You will write your own connectors for services, models, knowledge sources, transports and log sinks, in AEL. A connector will declare its types, its permissions and its limits like any other code, and run within the same budget and checks as the node that uses it.