# MCP capabilities and permissions

Adam MCP lets a connected AI client work with the projects, tasks, files, and
automations in your selected workspace. The client only receives the
capabilities covered by the permissions you approve and the workspace's current policy. Ownership, project access, subscription, and integration requirements still apply.

## Permission names

| Area | Read | Change |
| --- | --- | --- |
| Projects | `projects:read` | `projects:write` |
| Tasks | `tasks:read` | `tasks:write` |
| Files | `files:read` | `files:write` |
| Automations | `automations:read` | `automations:write` |
| Billing summary | `billing:read` | No billing-management scope |
| Integration status | `integrations:read` | No integration-management scope |

Direct execution additionally uses `tools:execute`. This is broad authority to run tools, including commands, connected accounts, paired devices, stored credentials, and billable operations. It is not limited to the individual resource scopes above. See [direct tool execution](/mcp/direct-tools) before enabling it.

## Workspace information

An authenticated, allowed connection can identify the selected workspace and list Adam models. Starting a model-driven task also requires task write access and the relevant usage entitlement. Optional read access can let the client:

- view the workspace's current plan and high-level usage;
- see which integrations are available and connected; and
- inspect existing automations and their latest status.

With `integrations:read`, `adam_list_devices` reports paired computers and the applications each reports, and `adam_fusion_status` checks the live Fusion add-in session. These setup reads do not create a task. Fusion's generic integration connection can be null while its add-in is live. Onshape and Arena use cloud account connections without a paired computer. Integration metadata and a reported connection do not establish that the intended document is ready.

Payment details, provider credentials, and private connection metadata are not
included.

## Projects

| Access | What the client can do |
| --- | --- |
| Read | Find projects and inspect their names, descriptions, and visibility. |
| Change | Create projects, rename them, and update their details. Moving a task between projects uses task write access. |
| Delete | Permanently delete a project after you confirm the action. Existing tasks and files are kept but become ungrouped. |

## Tasks and conversations

| Access | What the client can do |
| --- | --- |
| Read | Find tasks, inspect their status, review the conversation, and identify work that needs input. |
| Change | Start tasks, continue existing conversations, rename or reorganize tasks, answer questions, approve actions, and cancel work. |
| Delete | Permanently delete a task and its conversation after you confirm the action. |

Adam tasks may continue after the initial request. Compatible clients show live
progress and keep following the same task until it finishes, needs input, or is
cancelled. Other clients can check the task when you ask for an update.

When you ask a client to create a task, describe the work Adam should perform.
For example, “Create a new Adam task that says hello” should result in a task
whose instruction is “Say hello,” rather than an instruction to create another
task.

## Direct tool execution

Both endpoints advertise named native application operations. The ChatGPT/Codex endpoint also advertises named sandbox operations. With task write access and `tools:execute`, your client can queue these operations without starting an Adam agent loop. Reading a tool-call result requires both `tasks:read` and `tools:execute`.

The general `/mcp` endpoint additionally lets your client discover task tools with task read access and call the available operations through its existing generic interface. That interface is not part of `/mcp/chatgpt`. Direct execution requires a main task you own, including project edit access when applicable.

Creating an external task does not start inference or provision compute. Executing tools can use connected accounts and devices and consume usage. The full workflow, ownership requirements, statuses, and retry rules are covered in [Direct tool execution](/mcp/direct-tools).

## Files

| Access | What the client can do |
| --- | --- |
| Read | Find files attached to projects or tasks, open common formats with the client's native file experience, and inspect supported CAD models in Adam's interactive 3D viewer. |
| Change | Attach a local file to a task or add a shared file to a project. |
| Delete | Remove a shared project file after you confirm the exact file. Task results and conversation attachments are kept with their task. |

Files stay protected by your Adam connection. Compatible clients can open them
directly in the conversation without requiring a separate public download
link. Support for local uploads, downloads, and previews varies by client and
file type.

When you ask to view a STEP, STL, IGES, GLB, GLTF, or 3MF model, clients with
MCP Apps support can show Adam's orbitable 3D viewer in the conversation.
GLB and GLTF files need to contain their referenced resources.
Ordinary files such as source code, text, images, and PDFs continue to use the
client's native preview instead.

The plug-in's host-attachment viewer is a separate read-only path: STL, STEP/STP, IGES/IGS, and 3MF up to 32 MiB. It does not upload attachments into Adam. See [plug-in file previews](/mcp/plugin#preview-a-cad-attachment).

Uploading a task attachment uses `files:write`; attaching it while starting or continuing a task also requires `tasks:write`. Adding or removing a shared project file requires both `projects:write` and `files:write`. Returned API download URLs require authentication; use the client's file resources rather than treating those URLs as public links.

## Automations

| Access | What the client can do |
| --- | --- |
| Read | Find automations, inspect schedules and triggers, and review their latest status. |
| Change | Create and edit scheduled, one-time, or webhook-triggered work, and pause or resume it. |
| Delete | Permanently delete an automation after you confirm the action. |

## Safety and access

- The connection only acts within the workspace selected during authorization.
- Read and change access are approved separately for each area of Adam.
- MCP deletion tools require an explicit confirmation; deletion uses the corresponding write scope, not a separate delete scope.
- Workspace owners and admins can disable API/MCP access or block scopes under **Admin > API & MCP**. Restrictions apply to existing credentials too.
- `tools:execute` grants broad execution authority beyond individual resource scopes. Administrators can block it with **Allow full harness execution**.
- Revoking the connected app immediately ends its access.
- Removing a person from the workspace also removes access granted through
  their connection.

You can review or revoke connections in **Settings → Developer → Connected
apps**.

## Example requests

```text
Find my Adam project for the enclosure redesign, then start a task to review the
latest design for injection-molding risks. Keep me updated until it finishes or
needs my input.
```

```text
Find the completed tasks in my current Adam project, summarize the results, and
show me any output files I can open.
```

```text
Show me my Adam automations. Pause the monthly design review after I confirm
which automation you found.
```