Connect Claude Code

Add the Dalea MCP server to the Claude Code CLI over OAuth.

Connecting Claude Code (or Cursor, Windsurf, or any other MCP client you configure from a CLI or a config file) lets an external LLM work against your Dalea workspace with its full context window and tool-use loop. The setup takes about three minutes.

If you use claude.ai on the web, Claude Desktop or the Claude mobile apps, you do not configure a server by hand: those clients use the one-URL connector flow instead. See Connect the Claude connector.

The flow at a glance:

Add the server from your terminal: claude mcp add --transport http dalea https://dalea.app/mcp
OAuth challenge. Your browser opens Dalea's authorisation page.
Pick workspace. Select which workspace the client should see.
Token issued. A bearer token scoped to that workspace, plus a refresh token.
Tool calls start flowing. Every call is rate-limited and audited.

Prerequisites

A Dalea account. To link a new application to a workspace you need the ws:manage_oauth_clients permission there, which the owner role holds by default. Once an owner has linked the same client to a workspace, other members can connect to it with whatever role they hold. Until then, the workspace picker will not list it.
The organisation must have the mcp feature enabled. Workspaces in organisations without it are filtered out of the picker.
Claude Code, or any other MCP client that speaks streamable HTTP. The Dalea MCP server is HTTP-only; there is no stdio transport.
Your workspace URL. For cloud users this is https://dalea.app/mcp. Enterprise customers should use the URL provided by their administrator.

Step-by-step

Add the MCP server
Run, in a terminal:
```
claude mcp add --transport http dalea https://dalea.app/mcp
```
To replace an existing entry, remove it first with claude mcp remove dalea and run the add command again.
Trigger the OAuth flow
Start claude in the directory you want to work in and run /mcp. Pick the dalea server and choose Authenticate (or Re-authenticate). A browser window opens. The client registers itself with Dalea automatically, so there is no client ID or secret to paste.
Authorise and pick a workspace
Sign in to Dalea if you aren't already, then pick the workspace you want the client to see. On a first link you also assign the application a role in that workspace, chosen from the roles whose permissions are a subset of your own. Nothing is preselected unless exactly one role qualifies. If the application is already linked to that workspace, the existing application role is reused and no picker appears; the role belongs to the application in the workspace, not to you individually. The consent screen then lists the scopes being requested, drawn from mcp:read, mcp:write and mcp:code-exec.
The token is issued
Dalea issues an access token valid for 1 hour plus a refresh token valid for 30 days; the client stores both and refreshes silently. From here on every tool call carries the access token, and the server independently re-checks the workspace scope and the application's role on every call.
Try a real query
Back in the client, ask:
- "List my Dalea workspaces."
- "Find all animals in study DLA-7 with baseline weight under 22 g."
- "Summarise the latest result batch in the cytokines table."
- "Open the protocol for plasma collection."
Claude will invoke MCP tools (data_objects_read, document_markdown_read, etc.) and stream tool results into its response.

Tool catalogue

The server registers 42 tools, rising to 44 when workspace code execution is enabled: that adds code_execution and attach_files_to_sandbox, both gated on the mcp:code-exec scope. Reads and writes are exposed as separate, clearly-labelled tools. Read tools are annotated read-only, write tools are not, and the three that can delete or irreversibly overwrite data (document_markdown_write, data_environments_write, dalea_bash) are additionally annotated destructive.

Group	Read tools	Write tools
Search & navigation	`search_all`, `related_entities`, `workspace_info`	None
Documents & versions	`document_markdown_read`, `document_versions_read`, `entity_versions_read`	`create`, `document_markdown_write`, `document_versions_write`, `entity_versions_write`
Projects	`manage_projects_read`	`manage_projects_write`
Data (schema & rows)	`data_environments_read`, `data_tables_read`, `data_columns_read`, `data_objects_read`, `data_queries_read`	`data_environments_write` (commit), `data_tables_write`, `data_columns_write`, `data_objects_write`, `data_queries_write`
Results	`result_data_read`	`result_data_write`
Inventory	`inventory_types`, `inventory_containers_read`, `inventory_items_read`	`inventory_containers_write`, `inventory_items_write`
Files, import & export	`download_file`, `import_data_read`	`import_data_write`, `export_data`
Provenance	`provenance_read`	`record_external_run`
Marketplace & addons	`marketplace_packages`, `addons_read`	`addons_write`
Skills & examples	`list_skills`, `load_skill`, `get_tool_examples`	None
Workspace shell	None	`dalea_bash`

That is 24 read tools and 18 write tools. export_data is a write because it materialises a CSV in workspace storage. dalea_bash is a single destructive tool: some of its subcommands only read, but the tool as a whole can create, move and delete.

The tool list is the same for every role

The server advertises all 42 tools on every connection. Connecting the application as a Viewer does not hide the write tools, and granting only mcp:read does not restrict the client to reads: those calls are simply refused downstream with a permission error. mcp:code-exec is the one scope enforced per tool, on the two sandbox tools. Some irreversible actions (hard file deletes, schema-destroying edits) are not exposed to MCP at all and stay in the Dalea UI under human review.

Security model

Token lifetime: Access token 1 hour, refresh token 30 days. Signing out of Dalea does NOT revoke them.
Revoking: Settings → Developer → Connected Applications, then Revoke on the application. Dalea asks for a reason, then deletes the consent along with the access and refresh tokens.
Audience: Tokens carry an audience naming this MCP server and are rejected by any other resource. Which client may use a token is enforced separately, by the OAuth client_id and PKCE flow.
Workspace scope: Single workspace per token. Switching workspaces requires a new authorisation.
Audit: Every tool call is logged with the actor, workspace, tool name, MCP client name and version, auth method and a correlation id. No response hash is recorded.
Rate limits: Per-user request budgets, shared across all your workspaces: 120 requests per minute and 10,000 per day by default. Overage returns a rate-limit error with a retry-after.

Troubleshooting

The workspace picker is empty. Either the organisation does not have the mcp feature enabled, or you lack ws:manage_oauth_clients in every workspace and no owner has linked this client yet. Ask a workspace owner to connect it once.
"You don't have permission to grant this application access." No role in that workspace is a subset of your own permissions, so there is nothing you can assign. A workspace owner has to do the first link.
Tools not appearing. Some clients cache the tool list. Quit and reopen the client, or remove and re-add the server.
Rate-limit errors. The message carries a retry-after in seconds. Budgets are per user, not per workspace, so parallel sessions share them.

What's next

Connect the Claude connector

The one-URL flow for claude.ai on web, Desktop and mobile.

AI overview

For LLMs

The wiki itself, addressed to LLMs.

Plan mode

Connect the Claude connector