How an assistant's tool calls reach Asterobot, how it follows what happens through events and the log, and where the answers are cut.
You don't call the tools yourself, the assistant does. Knowing how they behave helps you read what it reports and understand why it sometimes asks for more.
How a call reaches Asterobot
A tool call is the same request Asteroboard would send, checked the same way. When the assistant gets an argument wrong, the answer tells it what's wrong, in the same words Asteroboard's own errors use, and it fixes its call. When Asterobot refuses something, the assistant reads the refusal: a call to move a bot that doesn't exist answers 404 Not Found: bot not found.
The arguments of a tool are the fields you'd fill in Asteroboard: the bot's name, the setting's key, the message to send. For two actions, sending a message on a bot's socket and copying a package, a field has the same name as the bot, so the assistant passes the whole form as one body argument. It can ask Asterobot for the exact shape of any action with the describe-operation tool, which also answers for the hidden actions, saying why they're hidden.
Three tools of their own
Besides the actions of Asterobot, the assistant gets three tools that Asteroboard has no need for:
| Tool | What it does |
|---|---|
describe-operation |
Every argument and the shape of the answers of one action, for when the short description isn't enough. |
watch-events |
The events Asterobot publishes: a bot changing state, a message on its socket, a download progressing, a setting changing. Each call returns the events after a position, waits up to 30 seconds for the first one when there's none yet, and answers with the position to continue from. |
read-logs |
Asterobot's own log, the one on Server > Console, from a chosen level up. |
Asterobot keeps the last 500 events of each kind. When an assistant comes back after that many have passed, watch-events tells it how many it missed, so it can look again rather than assume nothing happened.
Actions that finish later
Connecting a bot, playing a package or sending a message answers right away; what came of it arrives as an event later. The answer to such a call names the event to watch and the position to watch from, so the assistant can follow the outcome without guessing. That's why an assistant told to connect a bot usually reports the connection a little later, once it has seen the bot's state change.
Big answers
An answer larger than mcp.maxResponseBytes, 100,000 bytes by default, is cut down so it stays readable: whole entries are dropped from the end of the largest list in it, and the assistant is told how many, and which argument narrows that action when it has one. When there's nothing to drop, the answer is an error asking the assistant to narrow its request. The two answers that hit that in practice are the catalogue of game messages, which takes a name argument to return one message, and SQL queries, where LIMIT does the job.
Hidden actions
Two actions are hidden from every assistant unless you allow them: shutting Asterobot down and resetting every setting. Three are never tools, because an assistant has nothing to do with them: the live event stream Asteroboard uses (the assistant has watch-events instead), and exporting or importing a package as a zip file. MCP settings explains how to hide more actions, or allow the hidden ones.
The game protocol
The assistant can list every game message a bot can send, with every field, through the same catalogue the Send messages tab of a bot uses, and send one on a bot's socket. Asterobot checks the message against the game's own definition before it goes out, so a wrong field never reaches the game. The catalogue gives the shape of a message, not what it's for: the Dofus protocol reference has that, and you can point the assistant to a page of it. What the assistant can send is what a script can send; see Send messages.
Next: MCP settings.