Most of what an agent does with NoVo’s server is reading. The alert tools are the exception. They let an agent arm a standing watch on your key and cancel it again. Nothing is traded. A setting is changed on NoVo’s side. It is still the one place where an agent changes something, so it is worth knowing how the pieces fit.
The alert tools
All of them are paid. get_alerts returns every standing watch on your key and says whether a delivery webhook is registered. create_alert arms a new watch. cancel_alert removes one, by the id that get_alerts returned.
What can be watched
A watch has a kind. The kinds are equity_level, vix_level, crypto_level and crypto_block. The crypto plan opens the crypto kinds only. The equity and VIX kinds need the full API plan. If your plan does not cover a kind, the refusal names which plan would. What makes a good condition is a subject of its own, covered in a standing alert should watch a condition, not a price.
Delivery comes first
An alert is delivered to a webhook, an https address on a server you control. The webhook is registered over REST, before any alert is armed. This matters because of one fact: an alert with no webhook still arms. It is live, it can fire, and it arrives nowhere.
So the first thing an agent should do is call get_alerts and read whether a webhook is registered. If none is, it should say so before arming anything. The payload states this in plain terms. An agent that arms a watch and reports success without checking has given you false comfort.
A refusal at creation
Conditions are checked against the live map when the alert is created. An alert the evaluator could never fire is refused, with a reason. It is not saved. This is a kindness. A watch on a level that cannot be evaluated would sit silent forever, and silence from an alert reads as nothing happened.
The agent should pass the refusal on as written. It should not adjust the condition and try again without asking you. A changed condition is a different alert.
Confirming and cancelling
After arming, ask for three things back. The id of the new watch. The exact condition as the server stored it. Whether a webhook is registered. Then have it call get_alerts once more and show you the list. You now have a record of what is armed.
Cancel by id. Have the agent list first, show you the watch it intends to remove, and wait. A model matching on a description may pick the wrong one of two similar alerts. The id removes the doubt.
Housekeeping
Watches accumulate. A level that mattered last month is noise now. Once a week, ask the agent to list every watch and say what each is for. Cancel the ones you would ignore if they fired. An alert you have learned to ignore is worse than none, a point made in the hardest part of an alert is making it shut up.
When a watch fires, it reports that a level was crossed. It never says what to do about it. The overall design is described in standing alerts without a browser, and how to tell a quiet alert from a broken one is in how do you know an alert is still working. Plans and the alert endpoints are on the MCP & API page.