ACT for AI agents
ACT works over MCP. Everything a person asks the ACT agent, your own agent can do with the same tools: build automations from intent, test code, wire triggers, run, read the history and fix failures. This page is the reference. For people, start at the Overview.
Endpoints
| What | Value |
|---|---|
| MCP server | https://mcp.boost.space/v2/{system}/sse (SSE transport) |
| MCP auth | OAuth: protected-resource metadata at https://mcp.boost.space/.well-known/oauth-protected-resource/v2/{system}, scopes all and offline_access. Or Authorization: Bearer <API token> |
| Webhook ingest | POST https://{system}.boost.space/api/hook/{token}, no auth: the token in the path is the credential |
| REST API | https://{system}.boost.space/api, Bearer token. Covers data (records, modules, spaces); automations are MCP-only. API reference |
| These docs | https://docs.boost.space/mcp (docs MCP), /llms.txt, any page as markdown at <page>/index.md |
{system} is the system name shown under API & MCP in ACT. API tokens are created there too
and carry the full access of the user who created them. See API & MCP.
The model
-
Automation = one action plus zero or more triggers. Action types:
email,notification,url,create,code. ACT's chat buildscodeactions. -
Trigger =
SCHEDULED(interval, days, time and an explicit time zone) or a record event (CREATE,UPDATE,DELETEon a module, with optional conditions). Webhook triggers are added in the ACT app, on the automation's Webhooks tab, and firecodeactions only. - Run = one execution: status, duration, the returned result, or
errorplusstderr. - Secret = a named Variable, stored encrypted, write-only for people. Code receives the ones an action lists, by name.
MCP tools
| Task | Tools |
|---|---|
| Build or change from natural language | build_automation (pass the full intent; include actionId to change an existing automation in place) |
| Inspect | list_automation_actions, list_automation_triggers, get_automation_runs |
| Create and edit directly | create_automation_action, update_automation_action, delete_automation_action, create_automation_trigger, update_automation_trigger, delete_automation_trigger |
| Run | run_automation_action (on demand), run_automation_code (test run, stores nothing) |
| Secrets | request_secret (one-time secure link for the user), variable_-_list_records |
| Data access from code | get_boostspace_sdk_reference (the Python SDK for this system's modules) |
| Help | about_this_mcp_server, get_help, search_documentation |
Prefer build_automation for anything non-trivial: it writes the code, test-runs it until it
passes, and creates or updates the trigger and action in one call.
The code contract
def main(input): # the runner calls main(); no __main__ block
key = connections["STRIPE_API_KEY"] # secrets listed on the action, by name
order = (input or {}).get("body") # a webhook's JSON body
return {"ok": True} # JSON-serialisable; becomes the run's result
inputis the data payload, never the secrets. On a test run it is theinputyou send.-
A webhook's JSON body is
input["body"]. Form posts arrive parsed, other bodies as a string, 1 MB at most. -
A failed run carries
error(type,message); the full traceback, with the failing line, is instderr. - Every run executes in its own isolated environment, created for that run and discarded after.
Rules for agents
-
Never ask for a secret in chat. Call
request_secretwith the secret's name and give the user the link; the value goes from their browser straight to the vault. -
Test before you save.
run_automation_coderuns the code exactly like a fired action, and stores nothing. - Pass the time zone on every schedule. A time without a zone is ambiguous for the user.
- A webhook caller gets
accepted, not the result. Read the outcome withget_automation_runs. - Triggers, manual runs and run history need an administrator. For other users those tools are refused.
- Check the token with a read tool. A revoked token is reported on the first tool call, not when the client connects.