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 builds code actions.
  • Trigger = SCHEDULED (interval, days, time and an explicit time zone) or a record event (CREATE, UPDATE, DELETE on a module, with optional conditions). Webhook triggers are added in the ACT app, on the automation's Webhooks tab, and fire code actions only.
  • Run = one execution: status, duration, the returned result, or error plus stderr.
  • 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
  • input is the data payload, never the secrets. On a test run it is the input you 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 in stderr.
  • 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_secret with 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_code runs 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 with get_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.