Integration

Arca integration

Arca (getarca.app) is a task and workspace management app for teams. Read your workspaces, members, custom fields, folders, lists, tasks (with subtasks, labels, attachment metadata and custom field values) and task comments; create, update and delete folders, lists, tasks, statuses and labels, and post comments on tasks. Writes follow your workspace role: viewers can only read, while deleting folders and lists, managing statuses, and editing or deleting labels are for owners and admins. Authentication: an Arca API key (it starts with arca_) created in the Arca app under Settings, API Keys, with the scopes it needs (tasks:read, tasks:write and so on), sent as a Bearer token. All routes share 600 requests per minute per key.

Connect Arca How integrations work

Ask it in chat

Say what should happen.
The workflow builds itself.

When this happens, do that in Arca.Built from the 28 Arca tools below, on the connection you add once.

What you can do with Arca

Each of these is one operation on one endpoint, available both as a workflow step and as a tool an AI agent can call on its own. Nothing bundles several operations into one action, so what a run did stays readable afterwards.

Each badge shows the default agent permission of an endpoint (allowed: an agent calls it without asking; ask first: you are asked before an agent calls it, when the agent or chat asks permission for sensitive actions; never: no agent may call it), which every user can change endpoint by endpoint in their credential settings.

Most endpoints run on the free plan. A few, mainly the ones that publish on your behalf, need a paid plan.

Task, 5 operations

create_taskCreate taskPOSTAgents: ask firstCreates a task in a list, with optional HTML description, priority, status, dates, assignees and custom field values; it gets the workspace's next task number. Viewers cannot create tasks. Needs tasks:write.
delete_taskDelete taskDELETEAgents: ask firstPermanently deletes a task; this cannot be undone. Viewers cannot delete tasks, and access-restricted members get 403 outside their lists. Needs the tasks:write scope.
get_taskGet taskGETAgents: ask firstReturns one task with its HTML description, status, assignees, labels, direct subtasks, attachment metadata and custom field values. Access-restricted members get 403 outside their lists. Needs the tasks:read scope.
list_tasksList tasksGETAgents: ask firstLists the top-level tasks of a workspace, newest first, 50 per page unless limit says otherwise, each with status, assignees, direct subtasks and custom field values. Filter with list_id. Needs tasks:read.
update_taskUpdate taskPATCHAgents: ask firstUpdates a task: title, description, priority, status, list (moves it), dates, assignees (replaces them all) or custom field values. Only the fields you send change. Viewers cannot edit tasks. Needs tasks:write.

Folder, 4 operations

create_folderCreate folderPOSTAgents: ask firstCreates a folder in a workspace; its position is set after the workspace's last folder. Viewers cannot create folders. Needs the folders:write scope.
delete_folderDelete folderDELETEAgents: ask firstPermanently deletes a folder and every list and task inside it; this cannot be undone. Only workspace owners and admins can delete folders. Needs the folders:write scope.
list_foldersList foldersGETAgents: ask firstLists the folders of a workspace, ordered by position then name. Access-restricted members receive only the folders granted to them. Needs the folders:read scope.
update_folderUpdate folderPATCHAgents: ask firstChanges a folder's name, icon or color; only the fields you send change, the position never does. Viewers cannot edit folders. Needs the folders:write scope.

Label, 4 operations

create_labelCreate labelPOSTAgents: ask firstCreates a label in a workspace; label names are unique per workspace (409 otherwise). Any workspace member can create labels. Needs the workspaces:write scope.
delete_labelDelete labelDELETEAgents: ask firstPermanently deletes a label from its workspace; this cannot be undone. Only workspace owners and admins can delete labels. Needs the workspaces:write scope.
list_labelsList labelsGETAgents: ask firstLists the labels defined in a workspace, alphabetically by name: id, name, color and creation time. Needs the workspaces:read scope.
update_labelUpdate labelPATCHAgents: ask firstRenames a label or changes its color; only the fields you send change, and names stay unique per workspace. Only workspace owners and admins can update labels. Needs the workspaces:write scope.

List, 4 operations

create_listCreate listPOSTAgents: ask firstCreates a list inside a folder of a workspace (the API requires folder_id); its position is set after the last list. Viewers cannot create lists. Needs the lists:write scope.
delete_listDelete listDELETEAgents: ask firstPermanently deletes a list and every task in it; this cannot be undone. Only workspace owners and admins can delete lists. Needs the lists:write scope.
list_listsList listsGETAgents: ask firstLists the lists of a workspace, ordered by position then name, with the folder each belongs to. Access-restricted members receive only the lists they may access. Needs the lists:read scope.
update_listUpdate listPATCHAgents: ask firstRenames a list, changes its icon or color, or moves it to another folder; only the fields you send change. Viewers cannot edit lists. Needs the lists:write scope.

Status, 4 operations

create_statusCreate statusPOSTAgents: ask firstCreates a task status in a workspace with its category; status names are unique per workspace (409 otherwise). Only workspace owners and admins can create statuses. Needs the workspaces:write scope.
delete_statusDelete statusDELETEAgents: ask firstPermanently deletes a status. If any task still has it, pass reassign_to (another status of the workspace) or the call is refused. The last completed status cannot be deleted. Owners and admins only. Needs workspaces:write.
list_statusesList statusesGETAgents: ask firstLists the task statuses of a workspace in position order: id, name, icon, color, category and position. Use an id as status_id in create_task or update_task. Needs the workspaces:read scope.
update_statusUpdate statusPATCHAgents: ask firstChanges a status's name, category, icon, color or position; only the fields you send change. The last completed status cannot change category. Only workspace owners and admins. Needs workspaces:write.

Comment, 2 operations

create_commentCreate commentPOSTAgents: ask firstPosts a top-level comment on a task as the API key owner, visible to the task's workspace; replies are not supported through the API. Viewers cannot comment. Needs the comments:write scope.
list_commentsList commentsGETAgents: ask firstLists the comments on a task, oldest first: author id and name, HTML content, parent comment for replies, resolved flag and time. Needs the comments:read scope.

Workspace, 2 operations

get_workspaceGet workspaceGETAgents: ask firstReturns one workspace by id: name, slug, description, icon, color, cover image, owner id, your role and creation time. You must be a member of it. Needs the workspaces:read scope.
list_workspacesList workspacesGETAgents: ask firstLists every workspace the API key owner belongs to, alphabetically, with your role in each (owner, admin, member or viewer). Use an id as workspace_id in the other tools. Needs the workspaces:read scope.

Custom field, 1 operation

list_custom_fieldsList custom fieldsGETAgents: ask firstLists the task custom fields of a workspace that the key's user may see, by position: id, name, type, config and where each applies. Use the ids in the custom_fields of create_task and update_task. Needs tasks:read.

Me, 1 operation

get_current_userGet current userGETAgents: ask firstReturns the Arca user who owns the API key: id, email, display name, avatar URL and sign-up time (personal data). Needs the users:read scope.

Member, 1 operation

list_workspace_membersList workspace membersGETAgents: ask firstLists the members of a workspace, oldest first: user id, name, avatar, role and join time; email only when you own the workspace (personal data). Use the ids as assignee_ids. Needs workspaces:read.

Use Arca from Claude Code, Cursor or Codex

Connect Arca in LiveContext, create an API key in Settings, then add the LiveContext MCP server to your client. Its Arca operations become tools the client can call, next to every other integration you connected.

Claude Code

claude mcp add --transport http livecontext https://livecontext.ai/mcp --header "X-API-Key: YOUR_API_KEY"

Codex (~/.codex/config.toml)

[mcp_servers.livecontext]
url = "https://livecontext.ai/mcp"

[mcp_servers.livecontext.http_headers]
"X-API-Key" = "YOUR_API_KEY"

Cursor, Claude Desktop and other JSON configs

{
  "mcpServers": {
    "livecontext": {
      "type": "http",
      "url": "https://livecontext.ai/mcp",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Set up the MCP server step by step

How to connect Arca

Create your workspace
Sign up free. Nothing to install.
Connect Arca once
Add your Arca connection in Settings. Every tool from this integration reuses it, and secrets are encrypted at rest and visible only to you.
Describe the job in chat
The workflow builds itself in front of you and picks the endpoints it needs. Drag the steps yourself on the canvas whenever you would rather be explicit.