Actions

An action is a named operation with defined inputs and outputs. It might read a calendar, post a message, update a ticket, call your HTTPS endpoint, or run code on one of your workers.

The definition makes calls consistent and inspectable. It does not guarantee the same result every time: credentials, external state, rate limits, network failures, and the supplied inputs can all change the outcome.

Actions live with the thing that provides them. Open Build > Integrations, pick a provider, and its Capabilities section lists the actions and events it offers. Expand an action to read its parameters without leaving the page.

Where actions come from

Source	Where you find it
A connected provider	Build > Integrations, then the provider, such as Gmail or Slack. Its Capabilities section lists what it can do.
Mobius itself	Build > Integrations > Mobius, a built-in provider with nothing to connect. Its action names start with mobius.: Runtime Context, tables, memory, artifacts.
The environment	Build > Integrations > Environment, another built-in provider, present only when your deployment enables environments.
Your own code	Build > Custom actions, where you define an HTTP action backed by an HTTPS endpoint, or a worker action.

Tools from a remote Model Context Protocol (MCP) server are the one thing that does not appear here. An MCP server discovers its tools live rather than registering named actions, so it has its own sidebar entry: Build > MCP servers, then the server, which lists the tools it currently offers. See MCP server.

Built-in providers sit under the Built in category in the catalog. They need no sign-in, no key, and no install, so their actions are ready as soon as your organization exists.

For a provider you do connect, readiness is per account. A connected account shows Ready when Mobius has the configuration needed to attempt the action, which is not a promise that the external service will succeed on the next call. Needs setup names the missing piece. Connecting a provider makes its capabilities available, but one entry may still need particular scopes or provider-side setup, so read the Needs setup message rather than assuming one connection enables everything.

Try a harmless action

This walkthrough uses Runtime Context, a read-only action that Mobius itself provides. It has no external account and does not change outside data.

1. Open Build > Integrations > Mobius and find Runtime Context in the Capabilities section. Expand it to see what it returns.
2. Open Build > Agents and select an assistant you can edit.
3. On the assistant's Configure tab, select Edit.
4. In the Tools card, select the Runtime Context action, then select Save.
5. Open New chat with that assistant and ask it: Call Runtime Context and show me the result.

In the reply, confirm that:

• the transcript shows a tool call to mobius.runtime.get_context;
• its result contains org_id and the session's own identifiers; and
• the turn finished rather than failing.

This proves that the catalog entry was ready, the assistant could reach it, and the call and result were recorded in the transcript. It does not test an integration or a custom endpoint.

When you are finished, remove the action from the assistant again. The transcript stays available for inspection.

Selecting an action makes it a tool

An assistant can only call actions selected on its definition. Selection turns a catalog entry into a tool the model may choose during a turn, and it happens in one place: the assistant's Configure tab, in the Tools card.

The model decides whether and when to call it, which is why selection is the control. Give an assistant only the actions it needs, with the narrowest provider permissions and input schema you can use. An action's Read-only, Idempotent, and Destructive annotations describe expected behavior; they do not turn a mutating endpoint into a safe one.

Tool calls are not invisible. Each call and its result stay in the session transcript beside the assistant's reply, so you can see what was sent and what came back.

For an integration-backed call, Mobius freezes the selected account and checks the live connection, current assistant selection, and result audience immediately before dispatch. A failed check stops the call instead of trying another account.

Mobius does not insert an automatic human confirmation before a built-in, integration, MCP, custom HTTP, or worker action. When the work needs a business decision, tell the assistant to open an interaction and wait for the answer. That review is instruction-driven: the interaction does not bind itself to the later tool call or enforce what the assistant does next. Withhold the tool, narrow the provider permission, or enforce the rule in the receiving system when you need a hard boundary.

Inputs and results

The assistant fills in an action's inputs from the action's input schema and what it knows in the turn. Mobius validates the declared shape; the receiving system remains responsible for its own business rules.

The response comes back to the assistant as the tool result and stays in the transcript. Inspect a real result before you rely on its shape. A provider may return an empty value, a partial result, or a structured error, and an HTTP 202 response may mean only that another system accepted work rather than finished it.

Create a custom action

Create a custom action when Mobius needs to call an operation that is not in the catalog.

1. Open Build > Custom actions and select New action.
2. Enter an immutable Name using the dotted action-name format, such as tickets.search.
3. Add a clear Title and Description. Assistants use these to decide whether the action fits their task.
4. Choose HTTP endpoint or Worker-backed.
5. Define the input and output with JSON Schema.
6. Set the behavior annotations accurately, then select Create action.

For an HTTP action, enter a public HTTPS Endpoint URL. Signed context is the default request-body format and includes authenticated organization, action, actor, and invocation details. Use Legacy only for a receiver that already implements the older body contract.

Mobius generates an HMAC signing secret when the action is created and shows it once. Store it in the receiving service's secret manager before leaving the page. The receiver must verify the signature over the exact request body and reject invalid signatures and replayed deliveries. The Actions API defines the body, signature headers, limits, and response behavior.

There is no dry-run button that makes an arbitrary endpoint harmless. Test a new receiver with a disposable, read-only operation and non-sensitive input. Verify both sides:

• the assistant's tool call completed with the expected result; and
• Build > Activity shows the action name, status, source, retry count, parameters, and output summary. Filter it by provider, action, status, or assistant when the log is busy.

Activity is open to everyone in the organization, not only administrators. You see calls from your own conversations and assistants, calls made by team-owned assistants and routines, and calls whose owner opened them to the organization. An administrator sees every call, but not the parameters of a call that ran in someone else's private conversation. Activity never keeps what an action returned, only the top-level keys of the result, so open the session to see what came back.

The custom action's own page keeps the same detail beside its configuration: the input and output schemas, secret rotation, and its recent invocations.

Only then add credentials or state-changing behavior.

If a person should review a custom HTTP call, add an explicit interaction to the assistant's instructions. Enforce the decision in the receiving service when review is mandatory. Treat the signed request as authenticated context, not as proof that somebody approved the business operation.

A Worker-backed action has no endpoint URL or signing secret. A connected worker must advertise the exact action name and meet the action's location and capability requirements. If no eligible worker is active, the action cannot run.

Retries and irreversible effects

An action attempt can fail after the external system already performed the change, for example when the response is lost after a successful update. Treat a timeout or connection loss as an unknown outcome until you check the remote system.

For a change that supports idempotency:

• derive one stable key for the logical change;
• reuse that key for every retry of the same change;
• use a different key for different work; and
• confirm the provider's retention window and duplicate behavior.

Mobius retries cannot unsend a message or generally reverse a remote change. When a provider has no idempotency support, reconcile the remote state before retrying. For MCP tools, Mobius automatically retries a failed call only when the remote server positively marks it read-only and idempotent and does not mark it destructive. An idempotent hint alone never makes a mutation eligible for an automatic retry.

An instruction can put an explicit interaction before a high-risk action, while the receiving system enforces any mandatory decision. Review does not make a provider call idempotent or undo an earlier effect.

Return application context to an assistant

A signed custom HTTP action used as an assistant tool can return named application context alongside its normal result. Mobius adds that context to the active assistant turn so the model can see the updated application state on its next move.

This mechanism does not make a mutating tool safer. It only tells the assistant what changed. Use an explicit interaction when a person should review the change, and enforce the decision in the receiving system when the review is mandatory. The Actions API defines the response media type, size limits, and SDK helpers.

Next

• Connect provider accounts with Connect accounts.
• Select actions for an assistant with tools and skills.
• Implement and verify custom receivers with the Actions API.
• Run action commands from the CLI command reference.