Actions in connected apps

When an end user connects an app (see Connectors), an agent can also act in it as them: list their meetings, search their mail, open an issue, post to a channel. The tools are the actions of the apps that end user connected, and nothing else.

https://api.alexein.ai/v1/actions/mcp

Connect a clientCopy Anchor Link

The same two headers as memory's MCP server: your key and the end user.

claude mcp add --transport http alexein-actions "https://api.alexein.ai/v1/actions/mcp?providers=github,slack" \
  --header "Authorization: Bearer $ALEXEIN_API_KEY" \
  --header "X-Alexein-User: me"

• Transport. MCP over Streamable HTTP, protocol versions 2024-11-05 through 2025-11-25, a JSON response to each POST, no session. GET and DELETE answer 405.
• One end user per connection. X-Alexein-User fixes whose apps the tools act in. The app's own sign-in never leaves Alexein: the agent holds your key, not their Google or GitHub token.
• Only what is connected. The tool list is built for the end user on each request: an app they have not connected, or that needs reconnecting, lists no tools.
• Their browser too. With the Alexein Agent extension paired and agents turned on, browser is one more app: the agent reads pages, clicks and fills in the end user's own browser, asking them first where their settings say so. See Browser agents.

Which tools a client is givenCopy Anchor Link

An action that cannot be undone reaches another person or removes something for good: sending a message or an email, merging, deleting. These are listed only when the URL asks for them, and their description says so, so a model that was not meant to take them is never offered them.

Add ?providers= with app ids, comma-separated, to list only those apps' tools. Every connected app together can be several hundred tools, more than a model chooses between well.

Or let the agent find them. With ?mode=search the actions are not listed: the agent finds one with search_actions and runs it with run_read_action, run_write_action or run_irreversible_action, each offered only where the action it runs would be. ?mode=auto lists every tool up to 40 and searches past that, where clients start dropping tools and models choose badly. The default, ?mode=flat, lists every tool. The browser's tools are listed in every mode.

Each tool is named for its action, for example github_issues_create or google_calendar_list-events, and takes the app's own arguments. When an end user has connected two accounts at one app, each tool takes one more argument, account, naming which.

Over HTTPCopy Anchor Link

The same tools without an MCP client, with the same headers and query parameters.

GET /v1/actions/tools?providers=github
Authorization: Bearer tm_...
X-Alexein-User: me

POST /v1/actions/call
Authorization: Bearer tm_...
X-Alexein-User: me
Idempotency-Key: run_81:call_3
Content-Type: application/json

{ "name": "github_issues_create", "arguments": { "repo": "acme/app", "title": "Flaky test" } }

The answer is { "output": ..., "replayed": false }, output being what the app returned.

Retries and idempotencyCopy Anchor Link

Send an Idempotency-Key with every write, on HTTP and on MCP alike: a retry with the same key is answered with the first call's result ("replayed": true) and does not act again. A key that is still running answers 409. Without one, each call is a new attempt. Reads need no key.

ErrorsCopy Anchor Link

Over MCP, a failed call is a tool result with isError, its text saying what went wrong, so the model can recover. Over HTTP it is a status with a JSON body.