# Manage your listing after publishing Source: https://claude.com/docs/connectors/building/after-publishing Update your MCP server, plugin, and directory listing after publication ## Update your MCP server An MCP server is a live API. To add, change, or remove tools, deploy the change to your server—no resubmission to Anthropic is required, and there is no scheduled re-review. Claude picks up the new tool surface on the next connection. ## Update your plugin Plugin updates are pushed via your GitHub repo. CI mirrors changes to the public marketplace and runs automated screening on each update. ## Update your listing A self-serve dashboard for editing your logo, description, screenshots, and other listing metadata is rolling out in Claude.ai. Until it reaches you, email `mcp-review@anthropic.com` for listing edits. ## Slugs are permanent Your directory slug is fixed after publication. It determines your connector's permanent listing URL: ```text theme={null} https://claude.ai/directory/connectors/SLUG ``` Share this URL from your own documentation or a "Connect to Claude" button to send users directly to your listing. Display names can change via the dashboard; the URL slug cannot. ## Delist your connector To voluntarily remove your connector from the directory, email `mcp-review@anthropic.com`. # Authentication for connectors Source: https://claude.com/docs/connectors/building/authentication OAuth and authentication options for MCP servers in Claude Authentication is the most common source of partner questions. Claude's auth support differs in a few places from the generic MCP specification, so read this page even if you're already familiar with MCP auth. ## Supported authentication types Claude supports the following authentication types for remote MCP servers. The same infrastructure backs Claude.ai, Claude Desktop, Claude mobile, Claude Code, and Cowork. | Type | Description | Availability | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | `oauth_dcr` | OAuth 2.0 with Dynamic Client Registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591)) | Supported out of the box | | `oauth_cimd` | OAuth 2.0 with [Client ID Metadata Document](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents) | Supported out of the box | | `oauth_anthropic_creds` | OAuth 2.0 with Anthropic-held client credentials | Contact `mcp-review@anthropic.com` | | `custom_connection` | Custom URL or credentials supplied at connection time (for example, Snowflake-style) | Contact `mcp-review@anthropic.com` | | `none` | No authentication (authless server) | Supported. An optional partial-auth mode is experimental. | User-pasted bearer tokens (`static_bearer`) are **not yet supported**. Tokens or API keys passed in the connector URL (for example, `?token=`, `?apiKey=`, or `?userToken=` query parameters) are **not supported**. The MCP authorization specification explicitly [prohibits access tokens in the URI query string](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-requirements). If your server expects a credential as a query parameter, switch to OAuth or remove authentication. ## Anthropic-held client credentials A pure machine-to-machine `client_credentials` grant—where a server-to-server token is issued with no user in the loop—is **not supported**. Every connection requires user consent. `oauth_anthropic_creds` is the consent-gated alternative. The flow works like this: 1. You create an OAuth `client_id` and `client_secret` in your own authorization server and send them to Anthropic. 2. Anthropic stores those credentials securely and associates them with your directory entry. 3. When a user connects your server, they go through a standard OAuth consent screen. 4. After consent, Anthropic uses the stored client credentials to complete the token exchange on the user's behalf. This gives you a stable, registered OAuth client without requiring DCR or CIMD on your end, while keeping the user-consent step. Anthropic stores your credentials securely and uses them only for token exchange on behalf of consenting users; they are shared across the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork). Claude Code runs its own OAuth flow on the user's machine and identifies itself with its own [Client ID Metadata Document](#callback-urls), so it does not use Anthropic-held credentials. Claude Managed Agents uses a separate credential set. Anthropic-held credentials are bound to the authorization server that issued them. If you migrate to a new authorization server, email `mcp-review@anthropic.com` with the new `client_id` and `client_secret` before cutting over. CIMD-based connectors don't have this constraint — a CIMD `client_id` is a self-hosted URL, so it works against any authorization server that fetches it. To use this flow, email `mcp-review@anthropic.com` with your `client_id` and secret. ## DCR and CIMD details If your authorization server does **not** expose a `registration_endpoint` (i.e., does not support DCR), you have several options: * Expose a `registration_endpoint` * Support CIMD instead. Claude selects CIMD only when your authorization server metadata advertises **both** `"client_id_metadata_document_supported": true` **and** `"none"` in `token_endpoint_auth_methods_supported` — the second is required because Claude's CIMD client authenticates as a public client at your token endpoint. If either is missing, Claude falls back to DCR. See [lazy authentication](/docs/connectors/building/lazy-authentication#identify-the-client-with-cimd) for a worked CIMD example. * Switch to `oauth_anthropic_creds` For servers expecting high traffic from the directory, prefer **CIMD or `oauth_anthropic_creds` over DCR**. DCR causes Claude to register a new client on every fresh connection, which can result in very large numbers of registered clients on your authorization server. CIMD and Anthropic-held credentials avoid the registration call entirely. Claude includes a [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) `code_challenge` with `code_challenge_method=S256` on every authorization request, regardless of which registration mechanism it uses. Your authorization server must support S256 PKCE, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection) requires it to advertise `"code_challenge_methods_supported": ["S256"]` in its metadata so spec-compliant clients can verify support before starting the flow. To control which scopes Claude requests, include a `scope` parameter in the `WWW-Authenticate` header on your `401` response. If you don't, Claude requests the scopes your protected resource metadata advertises in `scopes_supported`. Claude also appends `offline_access` when your authorization server metadata lists it in `scopes_supported`, to obtain a refresh token. See [lazy authentication](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error) for the canonical `401` shape. ## Cross-host authorization servers A cross-host authorization server doesn't need anything special on its own. The `authorization_servers` field in your [protected resource metadata](https://www.rfc-editor.org/rfc/rfc9728) tells Claude where the authorization server is, and Claude resolves it regardless of which host it points at. The thing to get right is making sure Claude can find the protected resource metadata in the first place. **Always return a `401` with a `WWW-Authenticate` header** whose `resource_metadata` parameter points at your protected resource metadata document — the same handshake described in [Return 401, not a tool error](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error): ```http theme={null} HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource" ``` The `401` status is required — Claude does not honor a `WWW-Authenticate` header on a `200` response — and the `resource_metadata` URL doesn't have to be on the MCP server's origin; it can be any HTTPS location that serves the JSON document. That's what makes this the most reliable path for hosting platforms that can't serve `/.well-known/*` at the root, such as Supabase Edge Functions, Cloudflare Workers without a `/.well-known/*` route, and Lambda function URLs that only route a path prefix. If your `401` doesn't include a `resource_metadata` pointer, Claude can still infer the metadata location by probing your MCP server's origin: `/.well-known/oauth-protected-resource/` first, then `/.well-known/oauth-protected-resource`. Treat this as a fallback — it only works when your platform serves `/.well-known/*` paths, and it adds round-trips to every connection. Whichever way Claude finds the document: * The protected resource metadata document's `resource` field must match your MCP server URL exactly as the user enters it in Claude, including any path component. * The metadata's `authorization_servers` field must list your authorization server's issuer URL. If you list more than one, Claude uses the first entry and does not fall back to later entries — list your primary issuer first. * Your authorization server must serve its own discovery metadata — [RFC 8414](https://www.rfc-editor.org/rfc/rfc8414) authorization server metadata or [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) — at its `/.well-known/` paths, and that host must also be reachable from Anthropic's [published egress range](https://platform.claude.com/docs/en/api/ip-addresses). Discovery requests to the authorization server come from the same IP range as requests to your MCP server, so a WAF in front of your identity provider can break the flow even when your MCP server is reachable. If you control both hosts, an alternative is to serve the MCP endpoint and the authorization server behind a single custom domain that can route both `/.well-known/*` and your MCP path. A common symptom of a discovery failure is that your MCP server receives the initial request but your authorization server sees no traffic at all. That happens when neither path works: there's no `WWW-Authenticate: Bearer resource_metadata=…` header on your `401`, and the well-known paths on your MCP server's origin return `404`. With no metadata to read, Claude never learns where your authorization server is, and the connection fails with "Couldn't reach the MCP server." See [troubleshooting](/docs/connectors/building/troubleshooting) for the full diagnostic flow. ## Callback URLs For the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork), register the following redirect URI: ``` https://claude.ai/api/mcp/auth_callback ``` **Claude Code** is a native client and uses an RFC 8252 loopback redirect on an ephemeral port — for example: ``` http://localhost:3118/callback ``` The port varies per session. Claude Code declares `http://localhost/callback` and `http://127.0.0.1/callback` in its [Client ID Metadata Document](https://claude.ai/oauth/claude-code-client-metadata), so your authorization server must accept both with the port component ignored. [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) requires this for the IP-literal form (`127.0.0.1`); apply the same port-agnostic match to `localhost` so Claude Code works, even though RFC 8252 section 8.3 discourages `localhost`. See [lazy authentication](/docs/connectors/building/lazy-authentication) for implementation details. A Client ID Metadata Document can't prevent loopback impersonation on its own — any local process can bind a port and claim to be the legitimate client. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#localhost-redirect-uri-risks) requires authorization servers to display the redirect URI hostname clearly on the consent screen and recommends an extra warning when the only registered redirect URIs are loopback addresses. ## Token refresh Claude refreshes tokens **reactively on a 401 response**, with a proactive refresh up to five minutes before the stored expiry. To avoid refresh failures: * Return RFC 6749-compliant error codes (`invalid_grant`, not `invalid_request` or a custom code) when a refresh token is no longer valid * Rotate refresh tokens for public-client connections. DCR and CIMD register Claude as a public client, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-theft) adopts OAuth 2.1's requirement to rotate or sender-constrain refresh tokens for public clients. If you rotate, return the new refresh token in the same response that invalidates the old one. ## Enterprise authentication Directory connectors use a **single shared OAuth application per connector**. There is no per-org OAuth client for directory connectors — enterprise customers connect to the same OAuth app as everyone else, and access is scoped by the user's own permissions on your service. Custom connectors are different: an admin can supply their own OAuth client credentials when adding the connector, which scopes the OAuth client to that organization. See [custom connectors](#custom-connectors). ## Custom connectors When a user adds a custom connector by URL, the OAuth Client Secret field is **optional**. Supply it only if your authorization server requires confidential-client authentication. ## Network reference Anthropic's outbound traffic to your server originates from `160.79.104.0/21`. See the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses) if you need to allowlist Anthropic for conditional access or firewall rules. # Directory connectors vs custom connectors Source: https://claude.com/docs/connectors/building/directory-vs-custom Understand the difference between directory-listed and custom connectors Directory connectors and custom connectors run on the **same MCP infrastructure**. The runtime, transport, authentication, and tool-calling code paths are identical. The difference is review, discoverability, and distribution. | | Directory connector | Custom connector | | ------------------------------------- | ---------------------------------------- | ---------------------------------------------------------- | | **Runtime** | Same | Same | | **Anthropic review** | Yes | No | | **In-product discovery** | Browse, search, Suggested Connectors | None | | **Distribution** | [Directory link](#share-an-install-link) | [Install link](#share-an-install-link) or manual URL entry | | **Anthropic-held client credentials** | Available | Not available | | **Appears as** | Named card with logo | "Custom" | ## Share an install link Both directory and custom connectors have a URL you can share from your own documentation, a "Connect to Claude" button, or an onboarding email. ### Directory connectors After publication, your connector has a permanent listing URL based on its slug: ```text theme={null} https://claude.ai/directory/connectors/SLUG ``` For example, `https://claude.ai/directory/connectors/dovetail` opens the Dovetail listing with its description, screenshots, and a **Connect** button. You receive your slug when your submission is approved, and it [cannot change afterward](/docs/connectors/building/after-publishing#slugs-are-permanent). ### Custom connectors For a connector that is not in the directory, link to the **Add custom connector** dialog with the name and URL prefilled: ```text theme={null} https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL ``` | Parameter | Description | | --------------- | ----------------------------------------------------------------------------------------------------------- | | `modal` | Must be `add-custom-connector`. | | `connectorName` | Display name shown to the user. | | `connectorUrl` | Your MCP server URL, [percent-encoded](https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding). | For example, an install link for a server at `https://mcp.example.com/` looks like this: ```text theme={null} https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Example&connectorUrl=https%3A%2F%2Fmcp.example.com%2F ``` When a user follows the link, claude.ai opens the dialog with the name and URL prefilled and shows a notice that the values came from an external link. The user reviews the values and confirms before anything is added. If the user is signed out, they are prompted to sign in first and then land on the prefilled dialog. Install links only prefill the form. They do not bypass review by the user, and they do not grant your server any permissions the user has not confirmed. Organization administrators can use the same parameters on the admin path to prefill the org-wide connector dialog: ```text theme={null} https://claude.ai/admin-settings/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL ``` ## Suggested Connectors Directory connectors are eligible for **Suggested Connectors**—Claude can recommend your connector in-chat when it's relevant to the user's task. Custom connectors are never suggested. Every directory entry is automatically eligible; there is no separate opt-in. ## Use both: directory plus elevated custom A supported pattern is to list a connector in the directory with safe, broadly-applicable defaults, **and** provide enterprise customers a separate URL to add as a custom connector with elevated permissions or tenant-specific configuration. Document both paths in your own product docs. ## Per-tenant URLs If your server URL varies per tenant (for example, `{tenant}.mcp.example.com`), this is typically handled either as separate per-tenant directory entries or via the [`custom_connection`](/docs/connectors/building/authentication#supported-authentication-types) authentication type, where users supply their tenant-specific URL at connection time. `custom_connection` is enabled per partner—email `mcp-review@anthropic.com` to request it. The directory does not currently template a single entry across tenant subdomains. ## What the directory is not The Anthropic Directory is independent of the open [MCP Registry](https://registry.modelcontextprotocol.io) and the `modelcontextprotocol/servers` GitHub repository. Publishing to those does **not** surface your server in Claude. Submit through the [directory submission form](/docs/connectors/building/submission) to appear in Claude products. # Building custom connectors Source: https://claude.com/docs/connectors/building/index Build your own MCP servers to connect Claude to your tools and data ## Getting started **Authentication is the most common stumbling block.** Before you build, read the [authentication reference](/docs/connectors/building/authentication)—Claude's auth support differs from the generic MCP spec in a few important ways. Not sure whether to build an MCP server, a plugin, or both? See [what to build](/docs/connectors/building/what-to-build). **Build with Claude.** Install the official [`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev) in Claude Code—it walks you through building, testing, and packaging an MCP server interactively, using these docs as its reference. ### Key resources * **SDK Examples**: [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk) and [Python](https://github.com/modelcontextprotocol/python-sdk) SDKs contain server implementation examples * **Protocol Specification**: [modelcontextprotocol.io](https://modelcontextprotocol.io) * **Hosting Solutions**: Platforms like Cloudflare offer remote MCP server hosting with autoscaling and OAuth management * **Auth Specifications**: Review the [authorization spec](https://modelcontextprotocol.io/specification/latest/basic/authorization) with emphasis on third-party service flows ## Transport & authentication ### Supported transports Claude supports both Streamable HTTP and the legacy HTTP+SSE transport. The legacy HTTP+SSE transport is being deprecated in favor of Streamable HTTP. ### Authentication features * Supports the [2025-03-26](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization), [2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization), and [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) auth specifications * Dynamic Client Registration (DCR) enabled * OAuth callback: `https://claude.ai/api/mcp/auth_callback` (hosted surfaces); loopback redirect for Claude Code — see [callback URLs](/docs/connectors/building/authentication#callback-urls) * Token refresh and expiry support * Custom credentials for non-DCR servers ## Protocol features ### Supported * [Tools](https://modelcontextprotocol.io/specification/latest/server/tools), [prompts](https://modelcontextprotocol.io/specification/latest/server/prompts), and [resources](https://modelcontextprotocol.io/specification/latest/server/resources) * [Text](https://modelcontextprotocol.io/specification/latest/schema#textcontent) and [image-based](https://modelcontextprotocol.io/specification/latest/server/tools#image-content) tool results * [Text](https://modelcontextprotocol.io/specification/latest/schema#textresourcecontents) and [binary](https://modelcontextprotocol.io/specification/latest/schema#blobresourcecontents) resources ### Not yet supported * Resource subscriptions * Sampling * Advanced/draft capabilities ## Technical specifications | Constraint | Limit | | -------------------------------------- | -------------------------------------------------------- | | Claude.ai/Desktop max tool result size | \~150,000 characters | | Claude Code max tool result size | 25,000 tokens (configurable via `MAX_MCP_OUTPUT_TOKENS`) | | Claude Code timeout | Configurable via `MCP_TOOL_TIMEOUT` | | Claude.ai/Desktop timeout | 300 seconds (5 minutes) | | Transport protocol | Streamable HTTP (legacy HTTP+SSE being deprecated) | ## Testing your server 1. Add directly to Claude via **Settings > Connectors** 2. Use the MCP inspector tool to validate auth flows ## Related topics Understanding the Model Context Protocol. Review requirements and submit your connector. # Lazy authentication for MCP servers Source: https://claude.com/docs/connectors/building/lazy-authentication Let users call public tools immediately and defer OAuth until a protected tool is actually invoked. Not every tool on an MCP server needs the user's identity. A product catalog can be browsed anonymously; an order history cannot. **Lazy authentication** (sometimes called *mixed auth*) lets a single server expose both: unauthenticated clients can connect, list tools, and call public ones, and the server only challenges for credentials when a protected tool is invoked. The challenge follows the [MCP authorization specification](https://modelcontextprotocol.io/specification/latest/basic/authorization). In Claude, the challenge surfaces as an inline **Connect** card in the conversation. The user authenticates in a popup, Claude retries the same tool call automatically with the new token, and the turn continues — no context is lost. The examples below are drawn from a single-file Express app using `@modelcontextprotocol/sdk` over Streamable HTTP. ## Return 401, not a tool error The only detail that matters is **how** the server refuses an unauthenticated call to a protected tool. It must fail the **HTTP request** with `401 Unauthorized` and a [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc6750#section-3) header: ```http theme={null} HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="invalid_token", resource_metadata="https://example.com/.well-known/oauth-protected-resource/mcp", scope="orders:read" {"error":"invalid_token","error_description":"Authentication required for this tool"} ``` The body is advisory; the `401` status and `WWW-Authenticate` header carry the protocol signal. The optional `scope` parameter tells Claude which scopes to request during authorization — include the minimum your protected tools need. If you omit it, Claude requests the scopes your protected resource metadata advertises in `scopes_supported` (plus `offline_access` if your authorization server metadata lists it), which can produce an over-broad consent prompt. It must **not** return a successful HTTP response wrapping a tool error: ```http theme={null} HTTP/1.1 200 OK {"jsonrpc":"2.0","result":{"isError":true,"content":[{"type":"text","text":"Please sign in"}]},"id":1} ``` A `200` with `isError: true` is an application-level tool failure. Claude passes the error text to the model as the tool result and moves on — there is no auth prompt. Only a transport-level `401` causes Claude to pause the call, run the OAuth flow, and retry. A `403` triggers re-authentication only when accompanied by `WWW-Authenticate: Bearer error="insufficient_scope"` for scope step-up; any other `403` is surfaced as a terminal error. If users are seeing "please sign in" text in the chat instead of a **Connect** button, the server is returning the wrong one. The `resource_metadata` parameter in the `WWW-Authenticate` header points at the server's [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) Protected Resource Metadata (PRM), which in turn names the authorization server. That chain is how Claude discovers where to send the user without any of it being hard-coded in the client. ## Gate at the HTTP layer Because the refusal must be an HTTP status, the check has to happen **before** the JSON-RPC message reaches the MCP SDK. Once a tool handler is running, its return value is already destined to be wrapped in a `200` response. The sample inspects the parsed JSON-RPC body in the Express handler and short-circuits if the request is a `tools/call` for a protected tool and no valid bearer is present: ```ts src/index.ts theme={null} const PROTECTED_TOOLS = new Set(["get_my_orders"]); function callsProtectedTool(body: unknown): boolean { const messages = Array.isArray(body) ? body : [body]; for (const msg of messages) { if ( msg && typeof msg === "object" && (msg as { method?: unknown }).method === "tools/call" ) { const name = (msg as { params?: { name?: unknown } }).params?.name; if (typeof name === "string" && PROTECTED_TOOLS.has(name)) { return true; } } } return false; } const WWW_AUTHENTICATE = `Bearer error="invalid_token", ` + `error_description="Authentication required for this tool", ` + `resource_metadata="${BASE_URL}/.well-known/oauth-protected-resource/mcp", ` + `scope="orders:read"`; async function handleMcpPost(req: Request, res: Response): Promise { const token = extractBearer(req); const authed = isTokenValid(token); // Lazy-auth gate: fail with 401 BEFORE the MCP layer sees the request. // initialize, tools/list, and public tool calls fall through. if (!authed && callsProtectedTool(req.body)) { res .status(401) .set("WWW-Authenticate", WWW_AUTHENTICATE) .json({ error: "invalid_token", error_description: "Authentication required for this tool", }); return; } // Otherwise: stateless Streamable HTTP handling. const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined, enableJsonResponse: true, }); const mcp = buildMcpServer(authed ? "demo-user" : null); await mcp.connect(transport); await transport.handleRequest(req, res, req.body); } app.post("/mcp", (req, res) => { handleMcpPost(req, res).catch((err) => { console.error("mcp request error", err); if (!res.headersSent) { res.status(500).json({ jsonrpc: "2.0", error: { code: -32603, message: "Internal error" }, id: null, }); } }); }); ``` `initialize`, `tools/list`, and calls to `list_products` never hit the gate, so the connector is fully usable before sign-in. When the user already has a valid token, every request — public or protected — carries it and the gate is a no-op. The same pattern covers **scope upgrades**: if the bearer is valid but lacks a required scope, return `403 Forbidden` with `WWW-Authenticate: Bearer error="insufficient_scope", scope="…"` (per [RFC 6750 section 3.1](https://datatracker.ietf.org/doc/html/rfc6750#section-3.1)) and Claude will prompt the user to re-consent. ## Serve the discovery documents After a 401, Claude fetches the URL from `resource_metadata` to learn which authorization server to use: ```ts src/index.ts theme={null} function protectedResourceMetadata() { return { resource: `${BASE_URL}/mcp`, authorization_servers: [BASE_URL], bearer_methods_supported: ["header"], }; } app.get("/.well-known/oauth-protected-resource", (_req, res) => { res.json(protectedResourceMetadata()); }); // Path-suffixed variant per RFC 9728 section 3.1 — clients try this first when // the resource URL has a path component (/mcp). app.get("/.well-known/oauth-protected-resource/mcp", (_req, res) => { res.json(protectedResourceMetadata()); }); ``` Claude then fetches the authorization server's [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) metadata to find the `/authorize` and `/token` endpoints. ## Identify the client with CIMD The sample does **not** implement Dynamic Client Registration. Instead it advertises support for **Client ID Metadata Documents** ([draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)) in its authorization-server metadata: ```ts src/index.ts theme={null} function authorizationServerMetadata() { return { issuer: BASE_URL, authorization_endpoint: `${BASE_URL}/authorize`, token_endpoint: `${BASE_URL}/token`, scopes_supported: ["profile", "orders:read"], response_types_supported: ["code"], grant_types_supported: ["authorization_code", "refresh_token"], token_endpoint_auth_methods_supported: ["none"], code_challenge_methods_supported: ["S256"], client_id_metadata_document_supported: true, }; } ``` With CIMD the `client_id` is itself an HTTPS URL that dereferences to the client's OAuth registration metadata. There is no per-client database and no `POST /register` round-trip: at `/authorize`, the server fetches the `client_id` URL, verifies the document is self-referential (its `client_id` field equals the URL it was served from), and checks the requested `redirect_uri` against the document's `redirect_uris`. Because the document is self-asserted, the consent screen must display the **host of the `client_id` URL** (not the `client_name` field) as the relying party, and the listed `redirect_uris` should be required to be same-origin with the `client_id` URL. Claude selects CIMD only when the authorization-server metadata advertises **both** `client_id_metadata_document_supported: true` **and** `"none"` in `token_endpoint_auth_methods_supported`. The second is required because Claude's CIMD client authenticates as a public client (`token_endpoint_auth_method: "none"`), so the token endpoint must accept [PKCE](https://datatracker.ietf.org/doc/html/rfc7636)-only requests without a client secret. If either property is missing, Claude falls back to looking for a `registration_endpoint`. For native clients, compare loopback IP `redirect_uri` values (`http://127.0.0.1/…`, `http://[::1]/…`) with the **port ignored**, per [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) — native apps bind an ephemeral port at runtime. RFC 8252 section 8.3 discourages `http://localhost/…`, but Claude Code declares it in its CIMD and binds an ephemeral port at runtime, so apply the same port-agnostic match to `localhost` for compatibility. The sample's `redirectUriAllowed()` helper shows the comparison. ## Try it ```bash theme={null} npm install npm run build npm start ``` The server listens on `http://localhost:3000/mcp`. ```bash theme={null} curl -s http://localhost:3000/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_products","arguments":{}}}' ``` ```bash theme={null} curl -si http://localhost:3000/mcp \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_my_orders","arguments":{}}}' ``` Note the `WWW-Authenticate` header in the response. Claude reaches custom connectors from Anthropic's infrastructure, so `localhost` is not reachable directly. Expose the server over a public HTTPS tunnel (for example, `cloudflared tunnel --url http://localhost:3000` or `ngrok http 3000`), then in **Settings → Connectors → Add custom connector** enter the tunnel's `/mcp` URL. See [Testing your connector](/docs/connectors/building/testing) for details. Ask Claude to list products (no prompt), then ask for your orders — the inline **Connect** card appears, and after authenticating the same call completes. The sample's README includes a longer `curl` walkthrough that drives the stub `/authorize` and `/token` endpoints directly. ## Adapting to your server * List your protected tools in `PROTECTED_TOOLS`. * Replace `isTokenValid()` with real verification: JWT signature, `iss` matches your authorization server, `aud` equals the `resource` value you advertise in the PRM, and `exp`; or [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) token introspection against your IdP. * Point `authorization_servers` in the PRM at your real issuer and delete the stub `/authorize` and `/token` handlers. Keep `client_id_metadata_document_supported: true` in your issuer's metadata if you want registration-free onboarding for Claude clients. * If your server uses stateful Streamable HTTP sessions, the gate still belongs in the `POST /mcp` handler, before `transport.handleRequest`. # Model Context Protocol (MCP) Source: https://claude.com/docs/connectors/building/mcp Understanding the open standard powering Claude's connectors The Model Context Protocol (MCP) is an open standard created by Anthropic for AI applications to connect with tools and data sources. ## What is MCP? MCP provides a standardized way for AI assistants like Claude to: * Connect to external tools and services * Access data from various sources * Perform actions on behalf of users * Maintain security and user control ## How MCP works ### Local vs remote servers | Type | Description | Use Case | | -------------- | ---------------------- | --------------------------------- | | **Local MCP** | Runs on your device | Desktop integrations, local tools | | **Remote MCP** | Hosted on the internet | Web services, cloud applications | ### Key components * **Tools**: Actions Claude can perform (search, create, modify) * **Resources**: Data Claude can access (files, documents, records) * **Prompts**: Predefined interactions for specific tasks ## Security model ### User control * You authenticate each connector individually * Permissions mirror your access on the external service * You can disconnect at any time ### Tool hints All MCP tools must declare: * [`readOnlyHint`](https://modelcontextprotocol.io/specification/latest/schema#toolannotations-readonlyhint): Tool only reads data * [`destructiveHint`](https://modelcontextprotocol.io/specification/latest/schema#toolannotations-destructivehint): Tool can modify or delete data This helps Claude and users understand what actions are possible. ## Building with MCP The [MCP documentation](https://modelcontextprotocol.io/docs) is the source of truth for building MCP servers. ### For developers * Open specification at [modelcontextprotocol.io](https://modelcontextprotocol.io) * [TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk) and [Python SDK](https://github.com/modelcontextprotocol/python-sdk) available * Cloudflare hosting support with OAuth ### Submitting to directory Organizations can [submit MCP servers](/docs/connectors/building/submission) to the Connectors Directory for broader availability. # Building cross-platform MCP Apps Source: https://claude.com/docs/connectors/building/mcp-apps/cross-compatibility Build MCP Apps that work with both Claude and ChatGPT using a single codebase MCP Apps can run in both Claude and ChatGPT from a single codebase. The SDK auto-detects the host environment and uses the appropriate transport, though some platform-specific behaviors require attention. ## How it works ### Server side Use [`registerAppTool()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppTool.html) and [`registerAppResource()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppResource.html) to register your tools and resources. These helper functions automatically generate platform-specific metadata, so you write the registration once and it works on both platforms. ### Client side Call [`App.connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) without an explicit transport parameter. The SDK detects whether it's running in Claude or ChatGPT and uses the appropriate transport automatically. ## Platform differences While the SDK handles most cross-platform concerns automatically, some behaviors vary between hosts. ### Domain handling The [`Resource._meta.ui.domain`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#domain) field format and validation rules are determined by each host platform. For example, hosts may use hash-based subdomains, URL-derived patterns, or other formats. For Claude, compute the `Resource._meta.ui.domain` value by running this command, replacing `https://example.com/mcp` with your server URL: ```shell theme={null} node -e 'const yourServerUrl = "https://example.com/mcp"; console.log(require("crypto").createHash("sha256").update(yourServerUrl).digest("hex").slice(0,32) + ".claudemcpcontent.com")' ``` Example output for `https://example.com/mcp`: ``` c3d80a4ed901ee05b21755a88273b4a4.claudemcpcontent.com ``` # Design guidelines Source: https://claude.com/docs/connectors/building/mcp-apps/design-guidelines Visual and interaction design guidelines for MCP Apps in Claude ## Overview MCP Apps are interactive interfaces that appear within Claude's conversational flow. Think of them as natural extensions of the conversation, not separate apps that happen to appear alongside it. Your app inherits conversational context and helps users accomplish meaningful tasks without breaking flow. **Core principles:** * **Conversational.** Fit naturally into dialogue. Don't force users to learn new interaction patterns. * **Contextual.** Use conversation history to inform what you display and when. * **Integrated.** Inherit styling and conventions from the containing environment. * **Adaptive.** Handle variable sizing, mobile viewports, and diverse accessibility needs gracefully. See our [Figma UI kit](https://www.figma.com/community/file/1597641111449594397/mcp-apps-for-claude) for components and patterns to help you get started. ## What makes a good MCP App **Good candidates:** * Tasks that fit naturally into conversation like data analysis, document review, or project coordination * Communication and collaboration context like message search results, conversation threads, or team member profiles * Tasks with a clear start and end like booking, ordering or scheduling * Information users can act on immediately * Functionality that extends Claude's capabilities meaningfully **Patterns to avoid:** * Long-form or static content better suited for external viewing (max 500px height) * Complex multi-step workflows that exceed the display mode's scope * Deep navigation (no drill-ins, breadcrumbs, or multiple views) * Nested scrolling (inline cards should auto-fit content height) * Menus and popovers (dropdowns, context menus, and popover panels can get clipped by container boundaries or create z-index conflicts with the host UI — prefer visible controls like segmented buttons, toggles, or inline options) * Chat inputs or conversational UI (don't replicate Claude's features) ## Display modes ### Inline card Compact components embedded directly in conversation. Good for summaries, confirmations, and quick actions. Keep them focused. **When to use:** * Status updates and confirmations * Simple data displays or selections * Brief summaries with optional expansion * Quick actions that continue the conversation Inline card example showing a compact component Inline card example showing a data display **Constraints:** * Max height: 500px (auto-fit content height, no nested scrolling) * Max actions: 2, placed at the bottom of the card * Max data points: 4-5 * No drill-ins, breadcrumbs, or multiple views * No menus or popovers — use visible controls instead **On mobile:** Inline cards render full-width within the conversation. Ensure all tap targets are at least 44pt. Content should adapt to narrower viewports without horizontal scrolling. Inline card mobile examples ### Inline carousel Side-by-side items for browsing options. Users swipe or scroll horizontally to explore. **When to use:** * Product listings or search results * Location or venue options * Media galleries * Any set of comparable items Inline carousel example showing browsable items **Constraints:** * 3-8 items for scannability * Each card: image + title + metadata (max 3 lines) + optional CTA * 1 optional CTA per card * Maintain consistent card dimensions within a carousel * Cards should have consistent visual hierarchy **On mobile:** Carousel cards are optimized for horizontal swipe. Design for thumb reach — keep primary actions in the lower portion of cards. Peek the next card to signal scrollability. Inline carousel mobile examples ### Full screen Immersive interfaces for complex interactions. The conversation composer remains available so users can continue talking to your app through Claude. Apps provide their own fullscreen button. A close button appears in the native header bar when in fullscreen mode. In fullscreen mode, avoid the use of floating panels. Use collapsible sidebars, tabs or pagination to disclose details. **When to use:** * Data visualizations and dashboards * Detailed analysis tools * Document editing * Content that benefits from focused attention * Rich tasks requiring more space than inline allows Full screen mode example Full screen mode with data visualization **Constraints:** * Your app provides its own fullscreen button; a close button appears in the native header bar * The composer is always visible — design your UX to work with it * No floating panels — use collapsible sidebars, tabs, or pagination to disclose details * Chat sheet maintains conversational context **On mobile (coming soon):** Fullscreen is not yet available on mobile—apps render inline only. When it ships, the composer will overlay the bottom of the screen, so avoid anchoring critical UI to the bottom edge. Use the full viewport width and support both portrait and landscape where it makes sense. Full screen mobile examples ## Mobile guidelines MCP apps on mobile share the same principles as web, but the constrained viewport and touch-based interaction require specific adaptations. On mobile, Claude renders apps in a native WebView (WKWebView on iOS, WebView on Android) rather than a sandboxed iframe. Current mobile-only constraints: inline display only (no fullscreen yet), no camera/mic/location access, and connectors must be added via web or desktop before they appear on mobile. ### Host context for layout The host passes layout hints via `hostContext`: * `hostContext.safeAreaInsets` — `{top, right, bottom, left}` in pixels. Honor these to keep content clear of notches, the home indicator, and the composer overlay. Separately, set `_meta.ui.prefersBorder: false` on your `ui://` resource metadata to remove the outer card border on mobile. Apps always fill the container width—there are no fixed breakpoints. Design responsively from 320px up to fullscreen using container queries and the hostContext CSS variables. Inline apps have a maximum height of 500px. ### Display modes Declare which modes your app supports via `appCapabilities.availableDisplayModes` in `ui/initialize`. The host responds with the modes it supports, and your app can request a switch with `ui/request-display-mode`. Modes are `inline`, `fullscreen`, and `pip`. ### Content security policy Declare external origins per `ui://` resource via `_meta.ui.csp`: ```json theme={null} { "_meta": { "ui": { "csp": { "connectDomains": ["https://api.example.com"], "resourceDomains": ["https://cdn.example.com"], "baseUriDomains": [] } } } } ``` By default, all external origins are blocked. `frameDomains` (embedding third-party iframes) is currently restricted in Claude pending security review. ### Viewport and layout * Design for variable widths (320pt minimum, up to tablet) * Respect safe areas on notched devices * Full-width layouts — don't add side margins that waste mobile screen real estate * Content should reflow gracefully; avoid fixed-width layouts Viewport and layout do's and don'ts ### Touch targets * Minimum tap target: 44 x 44pt (per Apple HIG / Material guidelines) * Add sufficient spacing between interactive elements to prevent mis-taps * Prefer larger, thumb-friendly buttons over small text links * Place primary actions within natural thumb reach (lower portion of screen) Touch target do's and don'ts ### Transitions * Inline cards expand to fullscreen with a smooth transition * Provide a clear visual affordance for expansion (fullscreen button or tap-to-expand) * Fullscreen close returns to the conversation at the same scroll position Transition from inline card to full screen ### Dark mode All views must support both light and dark themes. Use the host's style tokens — they automatically adapt. Never hardcode colors. Test both modes. Dark mode examples on mobile ### Loading states Show skeleton screens while content loads. Match the layout structure of the final content so the transition feels seamless. Avoid spinners for inline content — skeletons feel more native. Loading state examples on mobile ## Visual design MCP Apps should feel native to their environment while maintaining consistent visual hierarchy and accessibility standards. You can still express your brand through accent colors, custom controls and content. **Design guidance** **Color.** Use host tokens for all structural elements: backgrounds, text, borders, icons. You can use your own brand colors for accents and identity, but the core UI should use the provided palette. Color token examples for light and dark mode **Typography.** Stick to the three-level size scale (heading, body, caption) and two weights (regular, emphasized). This creates clear hierarchy without visual noise. Typography scale examples The Figma Community File uses Anthropic Sans and Anthropic Serif. When your app runs inside Claude, the host client provides Anthropic Sans at runtime through style variables. [Download and install the fonts from here](https://brand.anthropic.com/typography) for local development. **Borders.** Using a limited set of corner radii and thickness will keep your app feeling native to the surrounding UI. Border radius examples **Icons.** Use monochromatic, outlined icons that match the host's icon color tokens. Icons should support understanding, not be essential to it. Icon style examples **Spacing.** Maintain generous padding and logical groupings. Balance information density with readability, adapting to viewport constraints. ## Interaction patterns ### App vs. chat interactions Understanding the boundary between your app's interactions and Claude's conversational interface helps you build something that feels cohesive. **Handle within your app:** * Direct manipulation like sliders, toggles, and selections * Filtering or sorting data you're already displaying * Expanding and collapsing content sections * Confirming or executing a prepared action ("Mark complete," "Send," "Save") * Interacting with visualizations like hover states or clicking data points Prefer controls with visible options (segmented buttons, toggle chips, inline tabs) over menus and dropdowns, which can conflict with the host container. **Push to chat input:** * Text entry and freeform input * Follow-up questions or requests for clarification * Requests to modify, refine, or redo something * Navigation to different contexts or topics * Anything that benefits from Claude's interpretation If the interaction requires language understanding or generates a response from Claude, it goes through chat. If it's a direct UI action on content your app already controls, handle it in the app. ### Start simple Reveal complexity only when users need it. The inline card might show a summary; fullscreen mode can offer the detailed view. ### Visible controls over hidden menus Prefer controls with visible options (segmented buttons, toggle chips, inline tabs) over menus and dropdowns. Menus conflict with the host container and are harder to use on mobile. ## Accessibility Maintain high contrast standards (WCAG AA minimum). Support keyboard navigation and provide text alternatives for visual content. Test with assistive technologies. Your app must be usable by everyone. ## Style variables MCP Apps automatically receive style variables from the host client. Reference these CSS custom properties to create interfaces that feel native to Claude. **Color tokens** cover backgrounds, text, and borders. Semantic accent colors signal status. All tokens automatically adapt to light and dark mode. | | Light mode | Dark mode | | :--------------------------- | :-------------- | :-------------- | | **Background** | | | | `color-background-primary` | `#FFFFFF` | `#30302E` | | `color-background-secondary` | `#F5F4ED` | `#262624` | | `color-background-tertiary` | `#FAF9F5` | `#141413` | | `color-background-inverse` | `#141413` | `#FAF9F5` | | `color-background-ghost` | `#FFFFFF (0%)` | `#30302E (0%)` | | `color-background-info` | `#D6E4F6` | `#253E5F` | | `color-background-danger` | `#F7ECEC` | `#602A28` | | `color-background-success` | `#E9F1DC` | `#1B4614` | | `color-background-warning` | `#F6EEDF` | `#483A0F` | | `color-background-disabled` | `#FFFFFF (50%)` | `#30302E (50%)` | | **Text** | | | | `color-text-primary` | `#141413` | `#FAF9F5` | | `color-text-secondary` | `#3D3D3A` | `#C2C0B6` | | `color-text-tertiary` | `#73726C` | `#9C9A92` | | `color-text-inverse` | `#FFFFFF` | `#141413` | | `color-text-ghost` | `#73726C (50%)` | `#9C9A92 (50%)` | | `color-text-info` | `#3266AD` | `#80AADD` | | `color-text-danger` | `#7F2C28` | `#EE8884` | | `color-text-success` | `#265B19` | `#7AB948` | | `color-text-warning` | `#5A4815` | `#D1A041` | | `color-text-disabled` | `#141413 (50%)` | `#FAF9F5 (50%)` | | **Border** | | | | `color-border-primary` | `#1F1E1D (40%)` | `#DEDCD1 (40%)` | | `color-border-secondary` | `#1F1E1D (30%)` | `#DEDCD1 (30%)` | | `color-border-tertiary` | `#1F1E1D (15%)` | `#DEDCD1 (15%)` | | `color-border-inverse` | `#FFFFFF (30%)` | `#141413 (15%)` | | `color-border-ghost` | `#1F1E1D (0%)` | `#DEDCD1 (0%)` | | `color-border-info` | `#4682D5` | `#4682D5` | | `color-border-danger` | `#A73D39` | `#CD5C58` | | `color-border-success` | `#437426` | `#599130` | | `color-border-warning` | `#805C1F` | `#A87829` | | `color-border-disabled` | `#1F1E1D (10%)` | `#DEDCD1 (10%)` | | **Ring** | | | | `color-ring-primary` | `#141413 (70%)` | `#FAF9F5 (70%)` | | `color-ring-secondary` | `#3D3D3A (70%)` | `#C2C0B6 (70%)` | | `color-ring-inverse` | `#FFFFFF (70%)` | `#141413 (70%)` | | `color-ring-info` | `#3266AD (50%)` | `#80AADD (50%)` | | `color-ring-danger` | `#A73D39 (50%)` | `#CD5C58 (50%)` | | `color-ring-success` | `#437426 (50%)` | `#599130 (50%)` | | `color-ring-warning` | `#805C1F (50%)` | `#A87829 (50%)` | **Typography tokens** include the font family, sizes, weights and line heights. | Family | | | :----------------------------- | :----------------------------- | | `font-sans` | `"Anthropic Sans, sans-serif"` | | `font-mono` | `"ui-monospace, monospace"` | | **Weight** | | | `font-weight-normal` | `400` | | `font-weight-medium` | `500` | | `font-weight-semibold` | `600` | | `font-weight-bold` | `700` | | **Size** | | | `font-text-xs-size` | `12px` | | `font-text-sm-size` | `14px` | | `font-text-md-size` | `16px` | | `font-text-lg-size` | `20px` | | `font-heading-xs-size` | `12px` | | `font-heading-sm-size` | `14px` | | `font-heading-md-size` | `16px` | | `font-heading-lg-size` | `20px` | | `font-heading-xl-size` | `24px` | | `font-heading-2xl-size` | `28px` | | `font-heading-3xl-size` | `36px` | | **Line-height** | | | `font-text-xs-line-height` | `1.4` | | `font-text-sm-line-height` | `1.4` | | `font-text-md-line-height` | `1.4` | | `font-text-lg-line-height` | `1.25` | | `font-heading-xs-line-height` | `1.4` | | `font-heading-sm-line-height` | `1.4` | | `font-heading-md-line-height` | `1.4` | | `font-heading-lg-line-height` | `1.25` | | `font-heading-xl-line-height` | `1.25` | | `font-heading-2xl-line-height` | `1.1` | | `font-heading-3xl-line-height` | `1` | **Radius tokens** provide border radius values | Radius | | | :------------------- | :------- | | `border-radius-xs` | `4px` | | `border-radius-sm` | `6px` | | `border-radius-md` | `8px` | | `border-radius-lg` | `10px` | | `border-radius-xl` | `12px` | | `border-radius-full` | `9999px` | **Border width tokens** provide width values | | | | :--------------------- | :------ | | `border-width-regular` | `0.5px` | **Shadow tokens** provide drop-shadow values | | | | :---------------- | :----------------------------------------------------------------------- | | `shadow-hairline` | `0 1px 2px 0 rgba(0, 0, 0, 0.05)` | | `shadow-sm` | `0 1px 3px 0 rgba(0, 0, 0, 0.1), 0 1px 2px -1px rgba(0, 0, 0, 0.1)` | | `shadow-md` | `0 4px 6px -1px rgba(0, 0, 0, 0.1), 0 2px 4px -2px rgba(0, 0, 0, 0.1)` | | `shadow-lg` | `0 10px 15px -3px rgba(0, 0, 0, 0.1), 0 4px 6px -4px rgba(0, 0, 0, 0.1)` | ### Example usage ```css theme={null} .my-app { background: var(--color-background-primary); color: var(--color-text-primary); font-size: var(--font-text-md-size); line-height: var(--font-text-md-line-height); } .card { background: var(--color-background-secondary); border-color: var(--color-border-primary); border-width: var(--border-width-regular); border-radius: var(--border-radius-md); } .button { background: var(--color-background-inverse); color: var(--color-text-inverse); font-weight: var(--font-weight-semibold); border-radius: var(--border-radius-md); } ``` # Opening external links from MCP Apps Source: https://claude.com/docs/connectors/building/mcp-apps/external-links How Claude handles ui/open-link requests, and how directory connectors can allowlist destinations to skip the confirmation modal When your MCP App sends a `ui/open-link` request, Claude shows an "Open external link" confirmation modal before navigating. This protects users from being silently redirected by an embedded app. Directory connectors can declare a set of trusted destinations that open immediately without the modal. Custom connectors and locally configured servers always show the modal. ## Default behavior A `ui/open-link` request displays a confirmation modal showing the destination URL. The link opens in a new tab when the user confirms; the request resolves as cancelled if they dismiss the modal. ## Allowlisting link destinations If your connector is published in the [Connectors Directory](/docs/connectors/directory), you can declare destinations that skip the modal. Provide them in the **Allowed link URIs** field when you [submit](/docs/connectors/building/submission) or update your directory listing. Each entry must be one of two shapes: | Entry shape | Example | Matches | | ----------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | HTTPS origin | `https://docs.example.com` | Any `https://` URL whose hostname is exactly `docs.example.com` (case-insensitive). Subdomains do not match implicitly; list each one you need. Port is not compared. | | Custom URI scheme | `example-app` or `example-app:` | Any URL with the scheme `example-app:`, typically a deep link into your native mobile or desktop app. | Entries that do not fit one of these shapes are ignored. This includes bare hostnames such as `example.com`, `http://` origins, and malformed values. ### Example Given the following allowlist: ```text theme={null} https://example.com https://docs.example.com example-app ``` These destinations open immediately: * `https://example.com/pricing` * `https://docs.example.com/getting-started?ref=claude` * `example-app://open/project/123` These destinations still show the confirmation modal: * `https://blog.example.com` (subdomain not listed) * `http://example.com` (not HTTPS) * `https://example.com.attacker.net` (different hostname) ### Restrictions on custom schemes A custom-scheme entry must name a scheme your application registers and owns. Entries that name a generic, browser-internal, or platform-reserved scheme are rejected. This includes `http`, `https`, `file`, `data`, `javascript`, `blob`, `mailto`, `tel`, `sms`, `intent`, `android-app`, browser-extension schemes, and Windows shell schemes such as `search-ms` and `shell`. ## User-activation requirement The modal is bypassed only when the `ui/open-link` request follows a real user gesture in your app, such as a button click. If your app sends `ui/open-link` without a preceding gesture (programmatically, on a timer, or after the browser's activation window has expired), the modal is shown so the user's confirmation click supplies the gesture the browser requires to open a new tab. A bypassed `ui/open-link` request resolves successfully once the open is attempted; it does not indicate whether the browser actually opened the tab. Do not treat the response as confirmation that the user reached the destination. ## Design for the modal Even with an allowlist configured, your app should remain usable when the modal appears: * Custom and local connectors always show the modal. Your app may run outside the directory during development or in self-hosted deployments. * Destinations not on your allowlist, or added since your last published directory update, show the modal. * Requests without user activation show the modal. Provide enough context in your UI that the destination URL shown in the modal is recognizable to the user. # Get started with MCP Apps Source: https://claude.com/docs/connectors/building/mcp-apps/getting-started Learn how to test MCP Apps in Claude ## Try an example MCP App ### Connect an example server Make sure you have installed and logged into Claude Desktop. Navigate to the [developer settings page](https://claude.ai/desktop/settings/desktop/developer) (**Settings > Developer**) and click the "Edit Config" button. Add one of the example servers to your `claude_desktop_config.json`: | Example | Description | | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | [**Customer Segmentation**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/customer-segmentation-server) | Data visualization with scatter charts and clustering analysis | | [**Map**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/map-server) | Interactive 3D globe viewer using CesiumJS | | [**QR Code**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/qr-server) | QR code generation with customizable colors and styling | | [**ShaderToy**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/shadertoy-server) | Real-time GLSL shader compilation and display | | [**Sheet Music**](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples/sheet-music-server) | ABC notation rendering with interactive audio playback | | ⋮ | Explore [more examples](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples)—each with ready-to-use config snippets! | ```json Customer Segmentation theme={null} { "mcpServers": { "customer-segmentation": { "command": "npx", "args": ["-y", "@modelcontextprotocol/customer-segmentation-server", "--stdio"] } } } ``` ```json Map theme={null} { "mcpServers": { "map": { "command": "npx", "args": ["-y", "@modelcontextprotocol/map-server", "--stdio"] } } } ``` ```json QR Code theme={null} { "mcpServers": { "qr": { "command": "npx", "args": ["-y", "@modelcontextprotocol/qr-server", "--stdio"] } } } ``` ```json ShaderToy theme={null} { "mcpServers": { "shadertoy": { "command": "npx", "args": ["-y", "@modelcontextprotocol/shadertoy-server", "--stdio"] } } } ``` ```json Sheet Music theme={null} { "mcpServers": { "sheet-music": { "command": "npx", "args": ["-y", "@modelcontextprotocol/sheet-music-server", "--stdio"] } } } ``` Save and restart the desktop app to connect. ### See it in action Once your local server is connected, prompt Claude to use it. For example, with the customer segmentation server, ask Claude to show you recent customer data. Claude will prompt you for permission to display the App. Click "Always allow", and you'll see the MCP App render inline in the conversation. ## Build your own MCP App Ready to add an MCP App to your own MCP server? Here are the key resources: * [MCP Apps Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) - Step-by-step guide to building your first MCP App * [SDK API Documentation](https://modelcontextprotocol.github.io/ext-apps/api/index.html) - Full API reference * [Example implementations](https://github.com/modelcontextprotocol/ext-apps/tree/main/examples) - Vanilla JS, React, Vue, Svelte, and more If you are using an AI coding agent, [MCP Apps skills](https://github.com/modelcontextprotocol/ext-apps/tree/main/plugins/mcp-apps) provide guided development for agents that support the [Agent Skills](https://agentskills.io) standard, including Claude Code, Cursor, Gemini CLI, and others. In Claude Code, you can install the MCP Apps skills plugin with the following commands: ``` /plugin marketplace add modelcontextprotocol/ext-apps /plugin install mcp-apps@modelcontextprotocol-ext-apps ``` Once installed, ask your agent to "Create an MCP App" or "Add a UI to my MCP tool". You can test remote MCP Apps locally via a proxy like [mcp-remote](https://www.npmjs.com/package/mcp-remote). ## Migrate from OpenAI Apps SDK If you are migrating an existing app from the OpenAI Apps SDK to the MCP Apps SDK, see the [migration reference](https://modelcontextprotocol.github.io/ext-apps/api/documents/Migrate_OpenAI_App.html). You can also use the MCP Apps skills mentioned above to help migrate your apps. Ask your agent to "Migrate from OpenAI Apps SDK" or "Convert my OpenAI App to an MCP App". *** We'd love to see what you build! Send feedback to [mcp-apps@anthropic.com](mailto:mcp-apps@anthropic.com) or open an issue on the [ext-apps repository](https://github.com/modelcontextprotocol/ext-apps/issues). # Supersede older widget instances Source: https://claude.com/docs/connectors/building/mcp-apps/instance-supersession Keep only the newest copy of a widget active when its tool is called more than once in a conversation Each time Claude calls a tool that renders an MCP App, a separate iframe is mounted in the conversation. There is no host API to unmount earlier instances when a newer one appears, so by default you end up with several live copies of the same widget, each independently pushing [model-context updates](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#updatemodelcontext) (data the widget feeds into Claude's context for the next turn) and [messages](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#sendmessage) to Claude. If your widget represents a single piece of state, such as a shopping cart or a dashboard, only the most recent instance should remain interactive. You can use [`BroadcastChannel`](https://developer.mozilla.org/docs/Web/API/BroadcastChannel) to make earlier instances disable themselves. The snippets on this page assume you have registered a UI resource and tool and created an `App` instance from `@modelcontextprotocol/ext-apps`. See the [SDK Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) if you haven't. ## How it works All widget iframes from a single connector are served from the same sandbox origin on `*.claudemcpcontent.com` (the iframe sandbox includes [`allow-same-origin`](https://developer.mozilla.org/docs/Web/HTML/Element/iframe#sandbox)). That means a `BroadcastChannel` opened in one instance reaches every other instance from the same connector in the current conversation. See [Channel scope and `ui.domain`](#channel-scope-and-ui-domain) for how a fixed domain widens this. The pattern has three parts: 1. **The server stamps each tool result with an election key.** It returns a `{createdAt, seq}` pair (server wall-clock time and a monotonic counter) in [`structuredContent`](https://modelcontextprotocol.io/specification/latest/server/tools#structured-content), the typed JSON payload slot of an MCP tool result. Tool results are stored in the conversation transcript, so every device and every remount of the widget sees the same key. 2. **Each widget announces its key on a shared channel.** Shortly after `connect()` resolves, the host delivers the tool result that mounted this widget (including its `structuredContent`) via the SDK's [`toolresult` event](https://modelcontextprotocol.github.io/ext-apps/api/types/app.AppEventMap.html). The widget reads its key from that event, opens a `BroadcastChannel`, and broadcasts the key. 3. **Any widget that sees a younger sibling marks itself superseded.** It greys out its UI, disables its buttons, and short-circuits all calls that mutate model context or inject messages. ## Mint the election key on the server Use [`registerAppTool`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppTool.html) to register the tool, and return the key in `structuredContent` alongside your normal tool output. A per-process counter works for a demo; a production server should derive the key from something durable, such as a database row ID or a version number on the underlying record. ```ts theme={null} import { registerAppTool } from "@modelcontextprotocol/ext-apps/server"; import { z } from "zod"; let callSeq = 0; registerAppTool( server, "show_cart", { title: "Show cart", description: "Render the user's shopping cart as an interactive widget.", inputSchema: { items: z.array(z.string()).optional() }, _meta: { ui: { resourceUri: "ui://cart-demo/cart.html" } }, }, async ({ items }) => { const list = items ?? []; const seq = ++callSeq; const createdAt = Date.now(); return { content: [{ type: "text", text: `Cart rendered with ${list.length} item(s).` }], // The election key travels with the tool result in the transcript, // so rehydrated widgets on any device recover the same ordering. structuredContent: { items: list, seq, createdAt }, }; }, ); ``` ### Why not use client-side `Date.now()`? Client mount time does not reflect tool-call order. When a stored conversation is reopened, Claude lazy-mounts widget cells as they scroll into view, so an older widget can mount after a newer one and would win an election based on client timestamps. The server-minted key is written into the transcript at tool-call time and is identical everywhere. ## Run the election in the widget The four snippets in this section form a single module; paste them in order into your widget entry file. ### Read the key from the `toolresult` event Connect and read the values you need from the host: your instance ID from [`hostContext.toolInfo`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html#toolinfo), and the server-minted key from the `toolresult` event. The event's `structuredContent` is typed `Record`, so cast it to the shape your server returns. ```ts theme={null} import { App } from "@modelcontextprotocol/ext-apps"; type CartResult = { items?: string[]; createdAt?: number; seq?: number }; const app = new App({ name: "cart-demo", version: "1.0.0" }); let superseded = false; let keyFinalized = false; let orderKey: number | undefined; let seq: number | undefined; let items: string[] = []; app.addEventListener("toolresult", (params) => { const sc = params.structuredContent as CartResult | undefined; if (sc?.items) items = sc.items; if (sc && Number.isFinite(sc.createdAt)) { orderKey = sc.createdAt; seq = Number.isFinite(sc.seq) ? sc.seq : undefined; keyFinalized = true; announce(); // defined in "Broadcast and compare on a shared channel" below } }); await app.connect(); const hostContext = app.getHostContext(); const instanceId = hostContext?.toolInfo?.id ?? crypto.randomUUID(); ``` ### Broadcast and compare on a shared channel Broadcast the key and compare against every sibling you hear from. The comparison is `createdAt`, tie-broken by `seq`, then by instance ID for determinism. Ignore inbound messages until your own key is finalized so you never reply with an undefined key. ```ts theme={null} const channel = new BroadcastChannel("my-app-cart-supersede"); const peers = new Map(); function isYounger(other: { orderKey: number; seq?: number; instanceId: string }) { // keyFinalized guards every call site, so orderKey is set by the time this runs. if (other.orderKey !== orderKey) return other.orderKey > orderKey!; if (other.seq != null && seq != null && other.seq !== seq) return other.seq > seq; return String(other.instanceId) > String(instanceId); } function recompute() { superseded = [...peers.values()].some(isYounger); render(); // defined in "Reflect the state in the UI" below } channel.onmessage = (ev) => { const msg = ev.data; if (!msg || msg.instanceId === instanceId) return; if (!keyFinalized) return; if (msg.type === "hello") { channel.postMessage({ type: "born", instanceId, orderKey, seq }); } peers.set(msg.instanceId, msg); recompute(); }; function announce() { channel.postMessage({ type: "hello", instanceId, orderKey, seq }); channel.postMessage({ type: "born", instanceId, orderKey, seq }); } ``` ### Gate host-mutating calls on `!superseded` The election only matters if superseded instances actually stop talking to Claude. Guard every call to [`updateModelContext`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#updatemodelcontext) or [`sendMessage`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#sendmessage): ```ts theme={null} // addButton, card, badge: elements in your widget's DOM. // pickRandomItem: your own helper that returns a string. function updateModelContext() { if (superseded) return; app.updateModelContext({ content: [{ type: "text", text: `Cart has ${items.length} item(s): ${items.join(", ")}.` }], }); } addButton.onclick = () => { if (superseded) return; items.push(pickRandomItem()); render(); updateModelContext(); }; ``` ### Reflect the state in the UI In your render function, disable buttons and show a banner that points the user to the newest instance: ```ts theme={null} function render() { card.classList.toggle("superseded", superseded); badge.textContent = superseded ? "Superseded" : "Live"; addButton.disabled = superseded; } ``` ## Special considerations The election above covers the common case. A production widget should also handle the following. ### Channel scope and `ui.domain` `BroadcastChannel` is same-origin only. How far that origin extends depends on whether you set [`_meta.ui.domain`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#domain) on your resource: * **Without `ui.domain`** (the default), Claude derives the iframe origin from the conversation and connector, so the broadcast is scoped to a single conversation. * **With a fixed `ui.domain`**, the origin is shared across every conversation and tab for your connector. A fixed channel name would let a widget in one conversation supersede a widget in another. Neither `hostContext` nor the tool-call arguments include a Claude-provided conversation ID, so if you need both a fixed domain and per-conversation elections, generate your own scope key on the server (for example, a UUID minted once per client connection) and return it in `structuredContent` for the widget to append to the channel name. ### Fall back if the server key is delayed The main snippet above waits for the `toolresult` event before announcing. If you want the widget to participate in the election even when that event is slow to arrive, replace that listener with one that resolves a promise, and race the promise against a short timeout after `connect()`: ```ts theme={null} let resolveServerKey!: (k: { orderKey: number; seq?: number }) => void; const serverKeyReady = new Promise<{ orderKey: number; seq?: number }>( (r) => (resolveServerKey = r), ); // Replaces the toolresult listener from the first widget snippet. app.addEventListener("toolresult", (params) => { const sc = params.structuredContent as CartResult | undefined; if (sc?.items) items = sc.items; if (sc && Number.isFinite(sc.createdAt)) { resolveServerKey({ orderKey: sc.createdAt!, seq: sc.seq }); } }); // Place after the announce() definition in the broadcast snippet, // so channel is initialized before announce() runs. const serverKey = await Promise.race([ serverKeyReady, new Promise((r) => setTimeout(() => r(null), 1000)), ]); orderKey = serverKey?.orderKey ?? Date.now(); seq = serverKey?.seq; keyFinalized = true; announce(); ``` If the server key arrives after the timeout, adopt it, recompute `superseded` against the peers you have already heard from, and re-announce so siblings update their view of you. The recomputed result may flip the instance back to live. ### Fallback caveat: don't compare server and client timestamps This applies only if you implemented the fallback above. If you fall back to a client-side `Date.now()` while waiting for the server key, tag the key with its source and refuse to compare a client value against a server value. A server `createdAt` from a tool call made hours ago will always be smaller than a fresh client timestamp, which would wrongly hand "live" to whichever instance happened to fall back. Include `keySource` in the broadcast payload (`announce()` and the `born` reply) and in the `peers` Map value type so siblings can read it: ```ts theme={null} type KeySource = "server" | "client"; let keySource: KeySource = "client"; function isYounger(other: { orderKey: number; seq?: number; instanceId: string; keySource: KeySource }) { if ((other.keySource === "server") !== (keySource === "server")) return false; // keyFinalized guards every call site, so orderKey is set by the time this runs. if (other.orderKey !== orderKey) return other.orderKey > orderKey!; if (other.seq != null && seq != null && other.seq !== seq) return other.seq > seq; return String(other.instanceId) > String(instanceId); } ``` ### Caching the key across remounts On Claude.ai web, [`hostContext.toolInfo.id`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html#toolinfo) is the stable tool-use ID, so you can persist the resolved server key to `localStorage` keyed by that ID and reuse it on the next mount without waiting for the `toolresult` event again. Treat this as an optimization rather than a correctness guarantee. On Claude iOS, `toolInfo.id` is `undefined` when a stored conversation is rehydrated, so there is no stable per-instance cache key. Detect that case and skip the cache; the server key from the `toolresult` event is the only ordering source that works on every platform. ### If you bypass the SDK `App` class The snippets on this page use the SDK's [`App`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html) class. If you instead hand-roll a minimal `postMessage` bridge, it will silently drop requests sent from the host to the widget, such as `ping` (a liveness check) and [`ui/resource-teardown`](https://modelcontextprotocol.github.io/ext-apps/api/types/app.McpUiResourceTeardownRequest.html) (the host asking the widget to clean up before unmount). Claude.ai web does not currently send either to widgets, and Claude iOS sends `ui/resource-teardown` only when the user navigates away from the conversation, so ignoring them is harmless today. The `App` class handles the full request surface and is recommended for production. ## Related topics * [Cross-platform compatibility](/docs/connectors/building/mcp-apps/cross-compatibility#domain-handling) for how `_meta.ui.domain` is computed on Claude. * [SDK API reference](https://modelcontextprotocol.github.io/ext-apps/api/index.html) for `registerAppTool`, `App`, and `McpUiResourceMeta`. # Blend your MCP App with Claude's theme Source: https://claude.com/docs/connectors/building/mcp-apps/transparent-theming Make your widget background transparent and style it with Claude's style variables Claude renders MCP Apps inside a sandboxed iframe, and every frame between your widget and the chat surface already has a transparent background, so the conversation can show through. When you leave your own background transparent and style text and borders with the host's [style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables), your app looks like part of the conversation rather than an embedded box, and it follows the user's light or dark mode automatically. The snippets on this page assume you have registered a UI resource and created an `App` instance from `@modelcontextprotocol/ext-apps`. See the [SDK Quickstart](https://modelcontextprotocol.github.io/ext-apps/api/documents/Quickstart.html) if you haven't. ## Let the host background show through Three settings on your side keep the transparency intact. ### Don't paint a body background Any opaque background on `` or `` hides the chat surface behind it. Explicitly set both to `transparent`: ```css theme={null} html, body { margin: 0; background: transparent; } ``` ### Declare `color-scheme` in your document head Browsers give iframe documents an opaque canvas backdrop (white in light mode, near-black in dark mode) when the iframe's [`color-scheme`](https://developer.mozilla.org/docs/Web/CSS/color-scheme) differs from the embedding page. Declaring both schemes opts your document into whichever mode the host is in, so the browser drops the backdrop and makes the CSS [`light-dark()`](https://developer.mozilla.org/docs/Web/CSS/color_value/light-dark) values in Claude's tokens resolve correctly: ```html theme={null} ``` ### Request a borderless frame Set [`prefersBorder: false`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#prefersborder) in your UI resource's [`_meta.ui`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html) object so the host doesn't wrap your widget in its own bordered card. Claude web's default is already borderless, but other hosts differ, so being explicit keeps your app portable. Register the resource with [`registerAppResource`](https://modelcontextprotocol.github.io/ext-apps/api/functions/server-helpers.registerAppResource.html): ```ts theme={null} import { registerAppResource, RESOURCE_MIME_TYPE, } from "@modelcontextprotocol/ext-apps/server"; registerAppResource(server, "My Widget", "ui://my-app/widget.html", {}, async () => ({ contents: [ { uri: "ui://my-app/widget.html", mimeType: RESOURCE_MIME_TYPE, text: widgetHtml, // the bundled HTML string of your widget; see the SDK Quickstart _meta: { ui: { prefersBorder: false, // lets applyHostFonts load Anthropic Sans; see "Allow the host font origin in your CSP" csp: { resourceDomains: ["https://assets.claude.ai"] }, }, }, }, ], })); ``` ## Apply the host's style variables Claude passes a [`hostContext`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiHostContext.html) object to your widget during the [`connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) handshake. The fields relevant to theming are: | Field | Contents | | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | | `theme` | `"light"` or `"dark"` | | `styles.variables` | CSS custom properties: `--color-background-*`, `--color-text-*`, `--color-border-*`, `--color-ring-*`, `--font-*`, `--border-radius-*`, `--border-width-*` | | `styles.css.fonts` | `@font-face` rules for Anthropic Sans, served from `https://assets.claude.ai` | The [Style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables) section of the design guidelines lists every variable and its light- and dark-mode value. ### Read `hostContext` and listen for changes The [`App`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html) class exposes the initial context via [`getHostContext()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#gethostcontext) once `connect()` resolves, and delivers subsequent updates (such as the user toggling dark mode) through the [`hostcontextchanged`](https://modelcontextprotocol.github.io/ext-apps/api/types/app.AppEventMap.html) event. Register the listener before you connect so you don't miss an early update. The SDK provides three helpers that do the DOM work for you, plus React hooks that wrap them: * [`applyDocumentTheme(theme)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyDocumentTheme.html) sets `` and the root `color-scheme`, so `[data-theme="dark"]` selectors and `light-dark()` values resolve correctly. * [`applyHostStyleVariables(variables)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyHostStyleVariables.html) writes every entry in `styles.variables` onto `:root` as a CSS custom property. * [`applyHostFonts(fontCss)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/app.applyHostFonts.html) injects the host's `@font-face` rules once. * [`useApp(options)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useApp.html) creates and connects the `App` instance for you in React. * [`useHostStyles(app, hostContext)`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useHostStyles.html) applies all of the above and re-applies on `hostcontextchanged`. Keep the `` tag from the previous section even though `applyDocumentTheme` also sets `color-scheme` at runtime. The tag covers the first paint before your script runs and prevents an opaque-backdrop flash. ```ts TypeScript theme={null} import { App, applyDocumentTheme, applyHostFonts, applyHostStyleVariables, type McpUiHostContext, } from "@modelcontextprotocol/ext-apps"; function applyHostContext(ctx: Partial) { if (ctx.theme) applyDocumentTheme(ctx.theme); if (ctx.styles?.variables) applyHostStyleVariables(ctx.styles.variables); if (ctx.styles?.css?.fonts) applyHostFonts(ctx.styles.css.fonts); } const app = new App({ name: "my-app", version: "1.0.0" }); // Updates carry only the fields that changed. app.addEventListener("hostcontextchanged", (changed) => applyHostContext(changed)); await app.connect(); const initial = app.getHostContext(); if (initial) applyHostContext(initial); ``` ```tsx React theme={null} import { useApp, useHostStyles } from "@modelcontextprotocol/ext-apps/react"; function Widget() { const { app } = useApp({ appInfo: { name: "my-app", version: "1.0.0" }, capabilities: {}, }); // Applies theme + CSS variables + fonts, and re-applies on host-context-changed. useHostStyles(app, app?.getHostContext()); return
…
; } ``` ### Reference the variables in your CSS Once the variables are on `:root`, reference them directly. Provide fallbacks so the widget is still readable when rendered outside a host: ```css theme={null} body { font-family: var(--font-sans, system-ui, sans-serif); color: var(--color-text-primary, light-dark(#141413, #faf9f5)); } .card { border: var(--border-width-regular, 0.5px) solid var(--color-border-primary); border-radius: var(--border-radius-md, 8px); } ``` Claude's token values use CSS `light-dark()`, so once `applyDocumentTheme` has set the root `color-scheme`, every `--color-*` variable resolves to the right variant without any `[data-theme]` selectors on your side. ### Allow the host font origin in your CSP For `applyHostFonts` to load the `@font-face` files, your resource's [`_meta.ui.csp`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceMeta.html#csp) allowlist must include `https://assets.claude.ai` in [`resourceDomains`](https://modelcontextprotocol.github.io/ext-apps/api/interfaces/app.McpUiResourceCsp.html#resourcedomains) (shown in the [`registerAppResource` snippet above](#request-a-borderless-frame)). `resourceDomains` also adds the listed origins to `script-src` and `style-src`, so keep it to origins you trust to serve executable code; prefer bundling third-party fonts into your widget rather than allowlisting public CDNs. ## Related topics * [Design guidelines: Style variables](/docs/connectors/building/mcp-apps/design-guidelines#style-variables) and [Visual design](/docs/connectors/building/mcp-apps/design-guidelines#visual-design) for the full variable palette and usage guidance. * [SDK API reference](https://modelcontextprotocol.github.io/ext-apps/api/index.html) for `App`, `McpUiHostContext`, and `McpUiResourceMeta`. # Troubleshooting MCP Apps Source: https://claude.com/docs/connectors/building/mcp-apps/troubleshooting Debug and resolve common issues with MCP Apps in Claude Desktop ## Using developer tools Claude Desktop's Developer Tools can help you debug MCP Apps. To use them: 1. Open **Help > Troubleshooting** and click **Enable Developer Mode**. A new **Developer** menu appears in the menu bar. 2. Open Developer Tools by pressing `Cmd+Option+I` (Mac) or `Ctrl+Shift+I` (Windows) 3. Inspect the tool call element and look for an iframe nested inside another iframe. Your app will be loaded as the content of the inner iframe. From the **Developer** menu, select **Reload MCP Configuration** after editing your `claude_desktop_config.json` to apply changes without restarting. ## Problem: Tool call appears but the app is invisible This is the most common issue when developing MCP Apps. Check these two causes: ### Missing `app.connect()` call Your app must call [`app.connect()`](https://modelcontextprotocol.github.io/ext-apps/api/classes/app.App.html#connect) (Vanilla JS) or [`useApp()`](https://modelcontextprotocol.github.io/ext-apps/api/functions/_modelcontextprotocol_ext-apps_react.useApp.html) (React) to establish communication with Claude Desktop. ```javascript Vanilla JS theme={null} import { App } from "@modelcontextprotocol/ext-apps"; const app = new App({ name: "My App", version: "1.0.0" }); // Register handlers before connecting app.ontoolresult = (result) => { // Handle tool results }; await app.connect(); ``` ```javascript React theme={null} import { useApp } from "@modelcontextprotocol/ext-apps/react"; function MyComponent() { // The useApp hook handles connection automatically const { app } = useApp({ appInfo: { name: "My App", version: "1.0.0" }, capabilities: {}, onAppCreated: (app) => { app.ontoolresult = (result) => { // Handle tool results }; } }); } ``` Event handlers like `app.ontoolinput` and `app.ontoolresult` won't be invoked until the app is connected. ### Iframe has zero height Your app needs a non-zero height to be visible. A zero height can occur if: * Your app's container has no content yet * You called `sendSizeChanged({ width, height: 0 })` Check that your root element has explicit dimensions or content that gives it height. ## Problem: App doesn't render when tool results are large When a tool result exceeds approximately 150,000 characters and Claude's code execution sandbox is active, the result is written to the sandbox filesystem instead of being passed inline to the conversation. Your app receives a pointer to the stored file rather than the structured content it needs, so it never hydrates. This \~150,000-character threshold is specific to Claude.ai and Claude Desktop. Claude Code uses a separate 25,000-token default limit configurable via `MAX_MCP_OUTPUT_TOKENS`. To avoid this, keep initial tool result payloads lean: * **Paginate large results.** Return a summary or the first page of data, and let the user request more through follow-up interactions. * **Fetch details on demand.** Use app-initiated tool calls to load additional data from within your widget as the user explores, rather than returning everything upfront. * **Defer heavy content.** If your data includes large blobs—full document text, base64-encoded images, extensive logs—return identifiers or previews in the initial result and provide a separate tool to retrieve the full content when needed. # Build a desktop extension with MCPB Source: https://claude.com/docs/connectors/building/mcpb Package a local MCP server as a single-click .mcpb install for Claude Desktop MCPB is the secondary distribution path. Remote MCP servers are recommended for directory listing—see [what to build](/docs/connectors/building/what-to-build). This guide covers building an MCP Bundle (`.mcpb`) for internal use, private distribution, or as a foundation for [submission to the Connectors Directory](/docs/connectors/building/submission). ## What is an MCPB? An `.mcpb` file is a zip archive containing a local MCP server and a `manifest.json`. It enables single-click installation in Claude Desktop, similar to a browser extension. Key characteristics: * Runs locally on the user's machine * Communicates via stdio transport * Bundles all dependencies * Works offline * No OAuth required See the [MCPB repository](https://github.com/modelcontextprotocol/mcpb) for the complete specification and the [Desktop Extensions blog post](https://www.anthropic.com/engineering/desktop-extensions) for an architecture overview. ## Local (MCPB) vs remote: which to build | Choose MCPB when you need | Choose a remote connector when you need | | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | Access to systems behind your firewall (JIRA, Confluence, internal wikis, private databases) | Cloud services and public APIs with centralized infrastructure | | Authentication via existing SSO and browser sessions, no token management | OAuth flows with server-side token management | | Zero-trust compliance inside corporate network boundaries | Distribution across Claude on web, mobile, and desktop | | Direct filesystem access for code editing and Git operations | Centralized updates pushed to all users | | Integration with locally installed tools (Docker, IDEs, databases) | Public-facing integrations used by multiple organizations | | Hardware integration and desktop application control | | | Privacy-sensitive operations that should not leave the user's machine | | | One-click install with bundled Node.js runtime, no dependencies to manage | | | No cloud infrastructure, VPN configuration, or firewall rules | | | Organization-level admin controls (custom uploads, allowlists) | | | Full control over authentication, authorization, and audit logs | | **Key difference:** MCPBs run on the user's machine via stdio with access to local and internal resources. Remote connectors run on your servers via HTTPS and are accessed through Anthropic's infrastructure. Organizations commonly build MCPBs as secure proxies to internal MCP servers, for internal documentation access, and to connect development tools while preserving their security architecture. For remote connector guidance, see [building custom connectors](/docs/connectors/building/index). ## Choose a language Node.js is strongly recommended: * Ships with Claude Desktop on macOS and Windows, so users need no separate runtime * Best compatibility and reliability with Claude Desktop * Extensive MCP SDK support ## Platform support Claude Desktop runs on macOS (`darwin`) and Windows (`win32`). Specify supported platforms in the `compatibility` section of your `manifest.json`. Test on both platforms even if you primarily develop on one. See the [manifest spec compatibility section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#compatibility) for platform and runtime requirement details. ## Quickstart ```bash theme={null} npm install -g @anthropic-ai/mcpb ``` Build a stdio MCP server using the [MCP SDK](https://www.npmjs.com/package/@modelcontextprotocol/sdk). ```bash theme={null} mcpb init ``` ```bash theme={null} mcpb pack ``` Double-click the generated `.mcpb` file. For detailed implementation guidance, see the [MCPB repository](https://github.com/modelcontextprotocol/mcpb), the [examples directory](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) including a Hello World, and the [README "For Bundle Developers" section](https://github.com/modelcontextprotocol/mcpb/blob/main/README.md). Before distributing your MCPB, review the testing and best-practices guidance in the MCPB README to ensure quality. ## manifest.json The `manifest.json` file is required metadata describing what your MCPB does, how to run it, which tools it provides, and what configuration it needs. | Reference | | | ---------------------------------------------------------------------------------------- | --------------------------- | | [MCPB Manifest Spec](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md) | Full schema with all fields | | [Example manifests](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) | Real-world implementations | | [CLI documentation](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md) | Command reference | ## Add an icon Icons are optional but recommended. Place `icon.png` in your bundle root and reference it in `manifest.json`. | Requirement | Value | | ----------- | ----------------------------------------- | | File name | `icon.png` (or a custom path) | | Size | 512×512px recommended (minimum 256×256px) | | Format | PNG with transparency | | Location | Bundle root or specified path | You can also provide multiple icon variants for different sizes and themes (light/dark mode). See the [manifest spec icons section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#icons) for variant syntax and best practices. ## User configuration Define a `user_config` section in `manifest.json` and Claude Desktop automatically generates a settings UI for your extension. The [manifest spec user configuration section](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md#user-configuration) covers the full schema, configuration types, validation constraints, sensitive-data handling, and multi-select patterns. ## How users install your MCPB Users can install three ways: 1. **Double-click** the `.mcpb` file 2. **Drag and drop** the `.mcpb` file into the Claude Desktop window 3. **Settings**: Settings → Extensions → Advanced settings → Install Extension… → select the `.mcpb` file All three open an installation UI where the user reviews extension details and permissions, configures required settings, grants permissions, and completes installation. Installation is per-user; each user installs separately on their own system. For the end-user installation experience and Team/Enterprise admin controls (organization management, allowlists, policy configuration), see [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop). ## Resources **MCPB framework** * [MCPB repository](https://github.com/modelcontextprotocol/mcpb): complete specification and tools * [MCPB Manifest Spec](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md): full manifest schema * [MCPB CLI documentation](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md): command reference * [MCPB examples](https://github.com/modelcontextprotocol/mcpb/tree/main/examples): reference implementations **MCP protocol** * [MCP specification](https://modelcontextprotocol.io/docs/getting-started/intro): protocol documentation * [MCP quickstart](https://modelcontextprotocol.io/docs/develop/build-server): getting-started guide * [TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk): Node.js implementation * [Python SDK](https://github.com/modelcontextprotocol/python-sdk): Python implementation **Claude Desktop** * [Release notes](https://support.claude.com/en/articles/12138966-release-notes): version updates * [Desktop Extensions blog](https://www.anthropic.com/engineering/desktop-extensions): architecture overview ## Get help * [MCPB GitHub issues](https://github.com/modelcontextprotocol/mcpb/issues): bug reports and feature requests * [MCP specification repo](https://github.com/modelcontextprotocol/modelcontextprotocol): protocol questions * [Claude support](https://support.claude.com/en/articles/9015913-how-to-get-support): general Claude Desktop support Check repository discussions for community Q\&A, follow release notes for updates, and review the examples for implementation patterns. ## Ready for distribution If you have a working MCPB and want broader distribution and discoverability, submit it to the Connectors Directory. See [submitting to the directory](/docs/connectors/building/submission) for requirements including: * Mandatory tool annotations for all tools * Privacy policy requirements * Working examples that exercise each tool * Test credentials where applicable * The complete submission process and review timeline # Pre-submission checklist Source: https://claude.com/docs/connectors/building/review-criteria What Anthropic reviewers test, so you can pass on the first try Anthropic reviewers run every submitted server through a functional test of each tool and a policy compliance scan. This page surfaces the most common rejection reasons so you can self-correct before submitting. For the full legal text, see the [Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy). ## Tool design ### Separate read and write tools A single tool that accepts both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe methods (POST, PUT, PATCH, DELETE) is rejected. Do not ship a catch-all `api_request` tool with a `method` parameter. Split into a read-only tool and one or more write tools. Ideally, split write operations further by action type (create, update, delete). Documenting safe versus unsafe operations within one tool's description does not satisfy this requirement—the operations must be in separate tools. ### Reference API docs in custom query tools If a tool accepts freeform endpoint paths, query strings, or request bodies that the caller constructs, its description must include a link to or explicit name of the target API. For example: "Queries the Slack Web API—see [https://api.slack.com/methods](https://api.slack.com/methods)". A description like "Makes a request to the API" with no further context fails. This applies only to custom query tools. Purpose-built tools that call a fixed endpoint internally do not need an API docs reference. ### Provide tool annotations Every tool must include a `title` and the applicable hint—`readOnlyHint: true` for read-only tools, `destructiveHint: true` for tools that modify or delete data. These determine auto-permissions in Claude: read-only tools can run without per-call confirmation; destructive tools always prompt. ### Keep tool names short Tool names must be 64 characters or fewer. ### Write narrow, accurate descriptions Each tool description should state precisely what the tool does and when to invoke it. The description must match the tool's actual behavior—reviewers call every tool and verify. ## Avoid prompt-injection patterns Tool descriptions are rejected if they: * Instruct Claude to call external software or tools the user didn't request * Interfere with Claude calling other tools * Direct Claude to pull behavioral instructions from external sources * Contain hidden, obfuscated, or encoded instructions * Tell Claude to behave in ways unrelated to the tool's function, attempt to override system instructions, or promote products and services Describe what the tool does. Do not tell Claude how to behave. ## Functional quality * Every tool must return a successful response when called with valid parameters. Generic errors ("Internal Server Error", "Bad Request" with no detail) fail review. * Validate inputs and return actionable error messages rather than silently accepting invalid data. * Keep responses reasonably sized for the task. Do not return a full database dump when a summary was requested. * Do not collect conversation data beyond what the tool needs for its function. * Do not query Claude's memory, chat history, conversation summaries, or user files. ## API ownership Your server must call your own first-party APIs, or APIs you legitimately proxy. The MCP server domain should match your service. ## Unsupported use cases Connectors that do the following are not accepted: * Transfer money, cryptocurrency, or other financial assets * Generate images, video, or audio via AI models (design tools that produce diagrams, charts, or UI mockups are allowed) ## Submission requirements * **Test credentials** are required and must be a fully populated account. * **Allowed link URIs** are recommended if your server calls `ui/open-link`. Declared HTTPS origins and custom URI schemes open without a confirmation prompt; anything else still prompts the user. See [Allowed link URIs](/docs/connectors/building/submission#allowed-link-uris). * **Public documentation** is required by your publish date—a blog post or help-center article is sufficient. You can share docs privately with Anthropic during review. * **Plugins** must link a public GitHub repo; closed-source is not accepted. * **MCPB** open-source and "spec will evolve" clauses in the [Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms) are required and not waivable. ## Before you submit Run `claude plugin validate` on plugins. For MCP servers, exercise every tool through the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) and as a [custom connector in Claude](/docs/connectors/building/testing). # Submitting to the Connectors Directory Source: https://claude.com/docs/connectors/building/submission Submit your MCP connector to the Connectors Directory The [Connectors Directory](/docs/connectors/directory) aims to be a collection of high-quality, vetted, and reviewed MCP servers that are helpful and harmless to users. Anyone is welcome to build MCP servers, but only servers meeting the review standards outlined on this page will be included in the directory. ## What you can submit Developers can submit: * **Remote MCP servers** — internet-hosted servers that provide tools and data to Claude * **Desktop extensions** — local MCP servers packaged as [MCP Bundles (MCPB)](https://github.com/modelcontextprotocol/mcpb) for Claude Desktop * **[MCP Apps](/docs/connectors/building/mcp-apps/getting-started)** — MCP servers that surface interactive UI elements. These have the additional requirement of including screenshots for submission and listing in the directory. ## Directory terms & conditions All servers in the directory must comply with: * [Anthropic Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms) * [Anthropic Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy) By submitting a connector, you also agree to: * Maintain your connector's security and functionality * Respond to security issues promptly * Provide accurate descriptions and documentation ## Submission requirements All MCP connectors submitted to the directory must meet: 1. **Security**: Meet Anthropic's security standards 2. **Tool annotations**: All tools must include a `title` and the applicable `readOnlyHint` or `destructiveHint` 3. **Authentication**: Use OAuth 2.0 for authenticated services 4. **Privacy Policy**: Local connectors must include privacy policies 5. **Documentation**: Provide clear setup and usage instructions If your connector opens external links, also provide your [allowed link URIs](#allowed-link-uris) so users aren't prompted to confirm each one. ## Privacy policy requirements Local connectors must include: 1. "Privacy Policy" section in README.md 2. `privacy_policies` array in manifest.json (manifest\_version 0.2+) 3. HTTPS URLs to privacy policies The privacy policy must cover: * Data collection practices * Usage and storage * Third-party sharing * Data retention * Contact information Missing or incomplete privacy policies result in immediate rejection. ## Allowed link URIs If your connector uses the `ui/open-link` capability to open URLs in the user's browser or native apps, provide the list of link targets your server will request. Claude uses this list to suppress the "Open external link" confirmation prompt for destinations you've declared. Links to any other destination still work—users are simply asked to confirm before the link opens. Provide each entry in one of two forms: * **HTTPS origin** — `https://example.com`. Only the scheme and hostname are matched; paths, ports, and query strings are ignored. Subdomains are not implied—list each one (`https://app.example.com`, `https://docs.example.com`). * **Custom URI scheme** — `myapp:` for deep links into a native app you own (for example, `spotify:` or `notion:`). Only the scheme is matched. Every origin and scheme you list **must be owned by you** (the submitting organization). You may not list third-party domains or URI schemes registered to apps you don't publish. Entries you don't own will be removed during review. This field is optional. If omitted, your connector functions normally, but users are shown a confirmation prompt each time it opens a link. ## Asset specifications ### Carousel screenshots (MCP Apps) * **Format:** PNG * **Width:** at least 1000px * **Count:** 3–5 images * **Crop:** to the app response only—**do not include the prompt** in the image * **Aspect ratio:** any * **Paired prompts:** provide the prompt text separately for each screenshot * **Mobile:** no separate mobile assets are required—one batch covers all surfaces * **Video/GIF:** not accepted A carousel template is available in the [Anthropic MCP Apps Figma community file](https://www.figma.com/community/file/1597641111449594397/mcp-apps-for-claude). ### Detail card description You write the detail card description in the submission form. It is not editable by Anthropic. The disclaimer text shown on connector cards is general and not customizable per partner. ## Review process Review times vary with queue volume. The submission form is always open. If you can't access the form because of a corporate firewall or tenant restriction, email `mcp-review@anthropic.com`—the form is also moving to a native Claude.ai surface. A self-serve status dashboard is rolling out in Claude.ai. Until then, you may not receive proactive notification on every status change; email `mcp-review@anthropic.com` for escalations. Run the [pre-submission checklist](/docs/connectors/building/review-criteria) and, for plugins, `claude plugin validate` before you submit. ## Submit your connector Ready to submit? Use the appropriate form based on your connector type: * Desktop extensions (MCPB): [Desktop extension submission form](https://clau.de/desktop-extention-submission) * Remote MCPs (including MCP Apps): [MCP directory submission form](https://clau.de/mcp-directory-submission) Skills are not a standalone submission type—bundle them in a [plugin](/docs/plugins/submit). ### What you'll need for submission Have the following information ready when filling out the submission form: * **Server basics** — server name, URL, tagline, description, use cases * **Connection details** — auth type, transport protocol, read/write capabilities, connection requirements * **Allowed link URIs** *(optional)* — HTTPS origins (e.g., `https://app.example.com`) and custom URI schemes (e.g., `myapp:`) your connector opens via `ui/open-link`; declaring these lets users skip the "Open external link" confirmation prompt. See [Opening external links](/docs/connectors/building/mcp-apps/external-links) for matching rules and restrictions. * **Data & compliance** — data handling practices, third-party connections, health data access, category * **Tools, resources & prompts** — list of all tools (with human-readable names), resources, and prompts in your server, plus confirmation of tool annotations * **Documentation & support** — links to docs, privacy policy, support channel * **Test account** — credentials with step-by-step setup instructions for a reviewer unfamiliar with your service * **Launch readiness** — GA date, confirmation of which surfaces you've tested in (Claude.ai, Desktop, etc.) * **Branding** — server logo (URL or SVG upload), favicon verification, promotional screenshots for MCP Apps (see [asset specifications](#asset-specifications) above) * **Documentation link** — must be public by your publish date (a blog post or help-center article is sufficient); you can share privately with Anthropic during review * **Policy & requirements checklists** — confirming compliance with directory policy, technical requirements (OAuth, HTTPS, `Origin`-header validation, annotations), documentation, and testing standards * **Optional: Skills & Plugins** — if submitting a related Agent Skill alongside the server. To submit a standalone plugin, see [Submitting your plugin](/docs/plugins/submit). # Testing your connector Source: https://claude.com/docs/connectors/building/testing Test your MCP server against Claude before submitting to the directory Test your server against the real Claude client before submitting. There is no separate staging environment—you test in production using a custom connector. ## Test as a custom connector Any Claude account (Free, Pro, Max, Team, or Enterprise) can add a custom connector. Go to **Settings > Connectors > Add custom connector** and enter your server's URL. Custom connectors use the exact same runtime as directory connectors, so what works here will work after publication. ## Test a local server To test a server running on your machine, expose it as a public URL with a tunnel such as [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) or `ngrok`, then add the tunnel URL as a custom connector. This is the recommended pattern for iterating on MCP Apps as well. A tunnel exposes your local server to the public internet. Keep authentication enabled on your server while tunneling, and shut the tunnel down when you're done testing. ## Validate with MCP Inspector Use the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) to verify protocol compliance, exercise your auth flow, and inspect tool schemas before connecting to Claude. ## Detect Claude as the client Claude identifies itself in the MCP `initialize` handshake via `clientInfo`, but the exact value depends on the surface and the request path. You may see `"name": "claude-ai"`, `"name": "Anthropic"` (sometimes with a service suffix), or `"name": "claude-code"`: ```json theme={null} { "clientInfo": { "name": "Anthropic", "version": "1.0.0" } } ``` Don't gate behavior on an exact `name` or `version` string — both vary across surfaces, request paths, and releases. Use `clientInfo` for telemetry and coarse feature detection only, and remember it's unauthenticated: any client can claim any name, so it must never feed an authorization decision. ## Prepare test credentials for review Directory submission requires test credentials. Provide a **fully populated account**—not an empty shell—so reviewers can exercise real functionality (list real records, search real data, exercise write tools on real resources). Include step-by-step setup instructions for someone unfamiliar with your service. ## Debugging Partner-visible error logs are in development. In the meantime, use server-side logging on your end and the MCP Inspector to diagnose connection failures. Common causes of `initialize` timeouts include slow OAuth metadata endpoints (keep these under five seconds), overly strict `Origin`-header validation rejecting Anthropic's requests, and firewalls dropping Anthropic's egress traffic. If your infrastructure logs show `403 Forbidden` responses your application didn't generate, your CDN or WAF is likely blocking Anthropic's traffic. See [firewall or WAF blocks Anthropic's traffic](/docs/connectors/building/troubleshooting#2-firewall-or-waf-blocks-anthropics-traffic) for the fix. For a structured walkthrough of "Couldn't reach the MCP server" and "Authorization failed" errors, including DNS resolution checks, OAuth discovery diagnostics, and how to find the `ofid_` reference ID to include in a support request, see [troubleshooting connectors](/docs/connectors/building/troubleshooting). # Troubleshooting connectors Source: https://claude.com/docs/connectors/building/troubleshooting Diagnose and resolve common connection failures for custom and directory MCP connectors This page covers the most common reasons a connector fails to connect or authenticate, and how to diagnose each one. The errors Claude shows in the UI ("Couldn't reach the MCP server" and "Authorization with the MCP server failed") cover more than one root cause, so the first step is figuring out which one you're hitting. ## Find your reference ID When a connection fails, the error toast and the page URL include a reference ID that starts with `ofid_`. For example: ```text theme={null} .../settings/connectors?step=start_error&flow_id=ofid_d32594c73257a651 ``` Copy that ID and include it in any GitHub issue or support request. It lets Anthropic trace the exact failure on the server side. Reference IDs are time-limited, so report them soon after the failure. If you're filing on the [`anthropics/claude-ai-mcp` issue tracker](https://github.com/anthropics/claude-ai-mcp/issues), include the `ofid_` value, your server URL, and what your server-side access logs show during the Connect attempt. ## "Couldn't reach the MCP server" This error appears when Claude can't complete the connection handshake. Despite the wording, it isn't always a network failure. Work through these causes in order. ### 1. Hostname resolves to a private IP claude.ai connectors run on Anthropic's infrastructure and reach your server over the public internet. Before making any request, Claude resolves your server's hostname and validates the result. If **any** resolved address is not globally routable, Claude rejects the connection before any HTTP request leaves Anthropic's network. Your server's access logs see nothing, and Claude reports "Couldn't reach." Claude rejects the connection when the hostname: * resolves to a private address (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) * resolves to a carrier-grade NAT address (`100.64.0.0/10`) * resolves to a loopback or link-local address * resolves to a mix of public and non-public addresses — every returned address must be globally routable * has no `A` record from public DNS — connectors are IPv4-only, so a hostname that only publishes `AAAA` records can't be reached **Common gotchas:** * **Works in Claude Code or `curl` but not claude.ai.** The CLI and `curl` connect from your machine, while claude.ai connects from Anthropic's servers. If your hostname resolves differently inside and outside your network (split-horizon DNS), claude.ai may be getting a private IP. * **Dynamic DNS providers.** Dynamic DNS hostnames often resolve to a home network behind NAT or carrier-grade NAT. * **Internal corporate DNS.** A hostname that resolves on your VPN won't resolve to a routable address from the public internet. **How to check:** Run `dig +short your-server.example.com` from a machine outside your network, or use a public DNS lookup service. Every returned address must be globally routable. **How to fix:** Expose your server through a publicly-routable endpoint, such as a cloud host with a public IP, a public reverse proxy, or a tunnel. See [test a local server](/docs/connectors/building/testing#test-a-local-server) for the recommended tunnel setup. ### 2. Firewall or WAF blocks Anthropic's traffic If your hostname resolves correctly but a CDN, WAF, bot-management rule, or rate limiter in front of your server blocks the request, the connection fails before your application sees it. **How to check:** Look for `403` or `429` responses in your edge or CDN logs that your application didn't generate, especially during a Connect attempt. **How to fix:** Allowlist Anthropic's published outbound IP range in your WAF or CDN configuration, or exempt your MCP and OAuth paths from the blocking rule. The current range is on the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses) page. ### 3. Your server URL redirects to a different host If your registered MCP URL returns a `301`/`302`/`307`/`308` redirect to a different host (apex to `www.`, region routing, vanity domain to CDN), the `Authorization` header is dropped on the redirect per standard HTTP client security behavior. The redirect target receives an unauthenticated request and returns `401`, and the connection fails with "Authorization with the MCP server failed." This also explains the common report "works in MCP Inspector or Claude Code CLI but not claude.ai." Local clients fail fast on a redirect, so the misconfiguration is visible immediately. claude.ai follows the redirect, drops the credential, and the failure surfaces later as an authorization error. **How to check:** Run `curl -sI https://your-server.example.com/your-mcp-path` and look at the response status and `Location` header. If you see a `3xx` status pointing at a different host, that target is the URL you should register. **How to fix:** Register the URL your server actually listens on, not a URL that redirects to it. Common culprits are apex-to-`www.` canonicalization, geographic or region routing, and vanity-domain-to-CDN redirects. ### 4. OAuth discovery fails If your server requires authentication, Claude performs OAuth discovery before it can connect. A discovery failure surfaces as "Couldn't reach" even though your MCP endpoint itself is reachable. The most common causes: * **Discovery metadata returns 404.** If your `401` response doesn't include a `WWW-Authenticate` header with a `resource_metadata` pointer, Claude looks for [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) protected resource metadata and authorization server metadata at the standard `/.well-known/` paths on your MCP server's origin. If those paths return `404` and you haven't pointed Claude elsewhere, Claude has no way to start the OAuth flow. * **No way to register a client.** Claude needs one of: [RFC 7591 dynamic client registration](https://www.rfc-editor.org/rfc/rfc7591) (a `registration_endpoint` in your authorization server metadata), [Client ID Metadata Documents](/docs/connectors/building/authentication#dcr-and-cimd-details) (`"client_id_metadata_document_supported": true`), or a pre-registered client. Without any of these, Claude can't obtain a client identity. See [supported authentication types](/docs/connectors/building/authentication#supported-authentication-types). * **Authorization server is on a different host than the MCP server.** Claude discovers protected resource metadata from your MCP server, then makes a *second* round of discovery requests against the authorization server host listed in `authorization_servers`. If that host lives behind a different CDN or WAF, it must also be reachable from Anthropic's egress range. See [cross-host authorization servers](/docs/connectors/building/authentication#cross-host-authorization-servers). **How to check:** From a public network, run: ```bash theme={null} curl -i https://your-server.example.com/.well-known/oauth-protected-resource curl -i https://your-server.example.com/.well-known/oauth-authorization-server curl -i https://your-server.example.com/.well-known/openid-configuration ``` If your MCP endpoint includes a path component (such as `https://your-server.example.com/mcp`), append it to the well-known path: `/.well-known/oauth-protected-resource/mcp`. The protected resource metadata should return `200` with valid JSON. For authorization server metadata, your server only needs to answer **one** of the two discovery endpoints — Claude tries `/.well-known/oauth-authorization-server` ([RFC 8414](https://www.rfc-editor.org/rfc/rfc8414)) first, then falls back to `/.well-known/openid-configuration` ([OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html)). A `404` on one is expected if the other returns `200`. Most hosted identity providers (Auth0, Okta, Microsoft Entra, Keycloak, Supabase Auth) only serve `/.well-known/openid-configuration`. Whichever metadata document resolves should advertise a `registration_endpoint` (DCR), `"client_id_metadata_document_supported": true` (CIMD), or you should be using pre-registered credentials. In a cross-host setup, run the protected-resource curl against your MCP server and the two authorization-server curls against your authorization server's issuer host. ## "Authorization with the MCP server failed" This error appears after the OAuth flow has started. The most common causes: * **Issuer mismatch.** The `issuer` value in your authorization server metadata must match the issuer that signs your tokens. If your tokens come from a third-party identity provider such as Supabase Auth or Auth0 but your metadata advertises a different issuer URL, validation can fail. * **Audience mismatch.** The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-handling) requires your server to verify each access token was issued for it. Claude sends the [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707) `resource` parameter on authorization and token requests, set to the canonical form of your MCP server URL — lowercase scheme and host, no trailing slash, no fragment, no default port — including any path component. Your authorization server should issue tokens with that audience, and your MCP server should accept the canonical value when checking `aud` rather than doing a strict byte-for-byte comparison against what the user typed. Or use whatever audience-binding mechanism your token format supports, as long as it confirms the token was minted for your server and not another service. * **PKCE not supported.** Claude includes a PKCE `code_challenge` with `code_challenge_method=S256` in every authorization request. If your authorization server doesn't implement S256 PKCE, the flow fails at the token endpoint. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection) also requires authorization servers to advertise `"code_challenge_methods_supported": ["S256"]` so spec-compliant clients can verify support before starting the flow. * **Refresh failures.** Use RFC 6749-compliant error codes when a refresh token expires. See [token refresh](/docs/connectors/building/authentication#token-refresh). If the OAuth flow completes successfully on your server (you see the token issued in your logs) but the connection still fails, file a [GitHub issue](https://github.com/anthropics/claude-ai-mcp/issues) with the `ofid_` reference ID and the timestamps from your server's OAuth logs. ## Diagnostic checklist Run through these in order before filing an issue: From a network outside your own, confirm `dig +short your-server.example.com` returns a globally-routable address. From a public network, confirm `curl -i https://your-server.example.com/your-mcp-path` returns a response (a `401` or `405` is fine; a timeout or connection refused is not). Run `curl -sI https://your-server.example.com/your-mcp-path` and confirm the response is not a `3xx` redirect to a different host. If it is, register the redirect target instead. Check your edge logs for `403` or `429` responses. Allowlist Anthropic's published egress range if needed. See the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses). Confirm `/.well-known/oauth-protected-resource` returns `200` with valid JSON, and that one of `/.well-known/oauth-authorization-server` or `/.well-known/openid-configuration` does the same — only one is needed. The authorization server metadata should include a `registration_endpoint` (DCR) or advertise `"client_id_metadata_document_supported": true` (CIMD), or you should be using pre-registered credentials, and it should advertise `"code_challenge_methods_supported": ["S256"]`. If your authorization server is on a different host than your MCP server, confirm your protected resource metadata's `authorization_servers` field points at it, and that the authorization server's host is reachable from Anthropic's egress range and answers `/.well-known/openid-configuration` (or `/.well-known/oauth-authorization-server`). See [cross-host authorization servers](/docs/connectors/building/authentication#cross-host-authorization-servers). Reproduce the failure and copy the `ofid_` value from the error URL. Include it, your server URL, and your server-side logs in your report. ## Related topics OAuth requirements and supported auth types. How to test your server before publishing. The 401 + WWW-Authenticate discovery handshake. Anthropic's published IP ranges for allowlisting. # What should I build: MCP, plugin, or both? Source: https://claude.com/docs/connectors/building/what-to-build Decide between an MCP server, a plugin, or both for your Claude integration Most partners ship two things: a remote MCP server and a plugin that wraps it. They serve different purposes, and together they give users the best experience. ## The recommendation Build a **remote MCP server with OAuth** first to provide connectivity and core functionality. Then create a **plugin with skills** that helps users get the most out of that MCP server. | | MCP server | Plugin | | ---------------- | ------------------------------------------------ | ------------------------------------------------ | | **What it is** | A live tool surface Claude calls over HTTP | An installable bundle of skills and connectors | | **Mental model** | "Claude can call your API" | "Claude knows how to *use* your product" | | **Contains** | Tools, prompts, resources, optionally MCP App UI | Skills, MCP connector references, slash commands | | **Works in** | Claude.ai, Desktop, mobile, Cowork, Claude Code | Claude Code, Cowork | ## When to build only one **MCP server only** is fine when your integration is simple and doesn't need skills—a few well-named tools that Claude can use without additional guidance. **Plugin only** is fine when you already have a public API or CLI that doesn't need an MCP wrapper. A plugin can ship skills that teach Claude to use that API or CLI directly. ## What a plugin can bundle A plugin can contain any combination of: * Skills only * A single MCP connector reference * Skills plus one or more MCP connectors * Multiple MCP connectors Plugins can reference both remote and local MCP servers. A remote MCP works on every Claude surface (web, mobile, Cowork, Desktop, Claude Code); a local MCP works only in Claude Desktop and Claude Code. Most MCP servers are remote. ## How they coexist A plugin references a remote MCP server by **URL**. If a user has both your directory connector and your plugin installed, Claude sees one set of tools—the plugin and the connector point at the same server. If a plugin references an MCP URL that isn't in the directory, the connector appears as **Custom** in the user's settings. Both MCP servers and plugins can update without Anthropic involvement. When you add tools to your MCP server, plugins that reference it pick them up automatically. Plugin updates are pushed via GitHub and pass through automated screening. ## Skills are not a standalone directory type Skills are user-shared micro-workflows. **Plugins are the distribution mechanism for skills**—you can't submit a skill to the directory on its own. If you have skills to ship, bundle them in a plugin. ## Build it with Claude The fastest way to scaffold an MCP server is with Claude itself. Install the official [`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev) in Claude Code and run `/mcp-server-dev:build-mcp-server`—it interviews you about your use case, picks the right deployment model, and generates a working server. ## Next steps Start with the MCP building guide. Bundle skills and connectors together. # Desktop extensions Source: https://claude.com/docs/connectors/custom/desktop-extensions Deploy enterprise-grade MCP servers with MCPB Desktop extensions allow you to deploy local MCP servers for Claude Desktop with enterprise-grade features using MCPB (MCP Bundles). Available for Team and Enterprise plans with Claude Desktop. ## What are desktop extensions? Desktop extensions are local MCP servers that run on user devices, providing: * Local tool access without internet dependency * Enhanced security for sensitive operations * Custom integrations for internal tools * Enterprise deployment capabilities ## MCPB (MCP Bundles) MCPB is Anthropic's utility for building and deploying desktop extensions: * Package MCP servers for distribution * Handle cross-platform compatibility * Manage dependencies * Support enterprise deployment ### Key features * **Bundling**: Package your MCP server with all dependencies * **Distribution**: Deploy to users via your organization's channels * **Updates**: Manage version updates centrally * **Security**: Sign and verify extensions ## When to use desktop vs remote | Use Case | Recommended | | --------------------------- | ----------------- | | Access to local files/tools | Desktop Extension | | Internet-hosted services | Remote MCP | | Sensitive enterprise data | Desktop Extension | | Public APIs | Remote MCP | | Offline capability needed | Desktop Extension | ## Enterprise deployment For Team and Enterprise plans, admins can: 1. Build custom desktop extensions 2. Package with MCPB 3. Deploy through enterprise software management 4. Control which extensions are available to users ## Security considerations Desktop extensions run locally with user permissions: * Access only what the user can access * No data transmitted unless explicitly designed * Full audit capability for enterprise * Revocable by administrators ## Getting started 1. Review the [MCPB documentation](https://github.com/modelcontextprotocol/mcpb) 2. Build your MCP server 3. Bundle with MCPB 4. Test locally 5. Deploy to your organization ## Related topics Learn to build MCP servers. Using cloud-hosted connectors. # Third party connectors with remote MCP Source: https://claude.com/docs/connectors/custom/remote-mcp Connect Claude to your tools using the Model Context Protocol Custom connectors enable you to link Claude directly to your essential tools and data sources using the Model Context Protocol (MCP). ## What are third party connectors? Custom connectors allow Claude to operate within your preferred software and leverage comprehensive context from your external tools. You can: * Connect Claude to existing remote MCP servers * Build your own remote MCP servers for any tool ### Finding connectors Browse the [Connectors Directory](/docs/connectors/directory) to discover verified and reviewed third-party MCP servers that are ready to use across all Claude products. ## Adding custom connectors You can manually add any third-party connector to Claude as long as you have the URL of that remote MCP server. **Security Notice**: Custom connectors allow connections to unverified services. Claude can access and perform actions within these services, so review security considerations carefully. ### For Team and Enterprise plans **Owners must:** 1. Navigate to **Admin settings > Connectors** 2. Click "Add custom connector" 3. Enter the remote MCP server URL 4. Optionally configure OAuth Client ID/Secret in Advanced settings 5. Click "Add" **Members then:** 1. Go to **Settings > Connectors** 2. Find the connector with "Custom" label 3. Click "Connect" to authenticate ### For Free, Pro, and Max plans 1. Navigate to **Settings > Connectors** 2. Click "Add custom connector" 3. Enter the remote MCP server URL 4. Optionally configure OAuth credentials 5. Click "Add" ### Enabling connectors in chat Use the "+" button in your chat interface to access "Connectors," where you can enable/disable connectors per conversation. ## Managing connectors To remove or edit connectors: 1. Go to **Settings > Connectors** 2. Click "Remove" or select the three-dot menu 3. Follow prompts to edit or remove ## Security and privacy ### Best practices * Only connect to servers from trusted organizations * Carefully review requested permission scopes during authentication * Be aware of prompt injection risks; Claude has built-in protections * Monitor for unexpected changes in tool behavior ### Tool actions Remote MCP servers enable Claude to invoke tools that can: * Read data from applications * Create, modify, or delete data * Take actions on your behalf **Usage guidelines:** * Monitor Claude's actions for unintended effects * Review tool approval requests carefully * Only click "Allow always" for trusted servers * Disable irrelevant tools via the "Search and tools" menu ## Reporting issues Report malicious MCP servers to [Anthropic's Bug Bounty Program](https://www.anthropic.com/responsible-disclosure-policy). ## Related topics Learn to build your own MCP servers. Browse pre-built connectors. Understand the Model Context Protocol. Deploy enterprise-grade MCP servers. # Connectors directory Source: https://claude.com/docs/connectors/directory Browse verified MCP integrations for Claude The Connectors Directory is a catalog of verified and reviewed [MCP](/docs/connectors/building/mcp) servers that work across all Claude products — Claude.ai, Claude Desktop, Claude Mobile, Claude Code, and Cowork. Every integration in the directory is vetted by Anthropic for security, reliability, and compatibility before being made available to users. All connectors in the directory are subject to the [Anthropic Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy) and the [Anthropic Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms). ## How the directory works * The same catalog serves Claude.ai, Cowork, Desktop, mobile, and Claude Code. * Directory connectors are eligible for **Suggested Connectors**—in-chat recommendations when relevant to the user's task. Every directory entry is included automatically. * Ranking is usage-based, similar to other app stores. * No domain-ownership proof (DNS or `.well-known`) is required—that requirement applies only to the open MCP Registry, not the Anthropic Directory. * The help-docs link shown in the in-product connector setup flow is not partner-customizable. Directory connectors and custom connectors run on the same infrastructure—see [directory vs custom](/docs/connectors/building/directory-vs-custom). ## Browsing the directory Access the Connectors Directory through: * **[Settings > Connectors](https://claude.ai/settings/connectors)** in Claude.ai * **[Admin Settings > Connectors](https://claude.ai/admin-settings/connectors)** for Team/Enterprise admins ## Submitting to the directory Organizations can submit their MCP servers for review and inclusion in the directory: 1. Review the [submission guidelines](/docs/connectors/building/submission) 2. Ensure your server meets security and compatibility standards 3. Submit via the [Connectors Directory review form](https://clau.de/mcp-directory-submission) ## Related topics Create your own MCP server. # Get started with connectors Source: https://claude.com/docs/connectors/getting-started Learn to connect Claude to your tools and data This tutorial walks you through setting up and using Claude's connector integrations to enhance your workflow. ## What you'll learn * Setting up your first connector * Using connectors in conversations * Best practices for each integration * Troubleshooting common issues ## Prerequisites * A Claude account (Pro, Max, Team, or Enterprise for most connectors) * Accounts on the services you want to connect ## Setting up your first connector ### Step 1: Access connector settings 1. Go to [claude.ai](https://claude.ai) 2. Click your initials in the lower left 3. Select **Settings > Connectors** ### Step 2: Choose a connector Available connectors include: * Google Drive, Gmail, Calendar * GitHub * Slack * Microsoft 365 ### Step 3: Authenticate 1. Click "Connect" next to your chosen service 2. Log in to your account on that service 3. Grant Claude the requested permissions 4. Return to Claude ## Using connectors in conversations ### In chat 1. Start a new conversation 2. Click the "+" button 3. Select "Add from \[Service]" 4. Choose the content you want to include 5. Ask your question ### In projects 1. Open your project 2. Click "Add Content" 3. Select the connector 4. Add documents to your project knowledge ## Connector-specific tips ### Google Drive * Best for: Document analysis, research * Add multiple Google Docs for comprehensive context * Documents sync automatically with updates ### Gmail & Calendar * Best for: Finding information, scheduling context * Ask questions like "What did Sarah say about the budget?" * Claude can search your emails but can't send them ### GitHub * Best for: Code understanding, documentation * Add entire repositories or specific files * Use with Projects for persistent codebase context ### Slack * Best for: Finding discussions, team context * Search channels and direct messages * Requires Claude in Slack installation first ### Microsoft 365 * Best for: Enterprise document search * Access SharePoint, OneDrive, Outlook, Teams * Team/Enterprise plans only ## Best practices 1. **Connect what you need**: Only connect services with relevant data 2. **Review permissions**: Understand what Claude can access 3. **Keep context focused**: Don't overload with too much data ## Troubleshooting * Clear browser cookies and try again * Check that you have the right account permissions * Try a different browser * Verify you have access to the data in the source service * Wait a moment for sync to complete * Try disconnecting and reconnecting * Go to Settings > Connectors * Click "Reconnect" or "Refresh" * Re-authenticate with the service ## Related topics See all available connectors. Build your own integrations with MCP. # GitHub integration Source: https://claude.com/docs/connectors/github/index Connect your code repositories to Claude Connect GitHub repositories directly to Claude to provide comprehensive context for software development tasks. Claude can understand your codebase and assist with development questions. Available on all plans including Free. All Claude integrations are currently in beta. ## Adding GitHub repositories ### In chats 1. Click the "+" button in the lower left corner of the chat interface 2. Select "Add from GitHub" from the dropdown menu 3. Use the file browser to select specific files and folders 4. When sending your message, Claude accesses and processes the selected content ### In projects 1. Click the "+" button in your project knowledge section 2. Select "GitHub" from the dropdown 3. Search accessible repositories or paste a repository URL 4. Use the file browser to select specific files and folders 5. Your selected content is added to project knowledge **Keeping content current:** * Use the "Sync" icon to ensure you're working with the latest codebase * Use the "Configure files" icon to modify which files Claude analyzes If you're not authenticated with GitHub, you'll be redirected to authenticate before using the integration. ## Connecting to private repositories If you see a warning after entering a valid URL, you're likely attempting to connect to a private repository. Follow the link to the GitHub App where you can: * **Grant access yourself**: Choose between allowing Claude access to all repos or specific ones * **Request access**: GitHub organization administrators receive an email notification. Once approved, you can sync and access the repository ## Best practices 1. **Start small**: Begin with a small codebase subset to understand how Claude interprets your code 2. **Iterate and refine**: Ask follow-up questions if initial responses need clarification 3. **Combine with human expertise**: Use Claude's insights as a starting point for team discussion 4. **Thoughtful file selection**: Include key files central to your task while staying within token limits 5. **Regular updates**: Refresh GitHub sync periodically, especially before new analysis or major repo changes ## What information is retrieved | Retrieved | Not Retrieved | | -------------- | ------------------- | | File names | Commit history | | File contents | Pull requests | | Branch content | Issues | | | Repository metadata | ## Frequently asked questions Click "Sync now" to fetch the latest changes from your repository. Yes, add multiple repositories to provide comprehensive context, provided they fit within Claude's context window. You won't be able to view its contents in projects where it was previously added. The repository preview is removed, but conversation history remains. # Google Calendar integration Source: https://claude.com/docs/connectors/google/calendar Access your calendar and meeting information with Claude The Google Calendar integration enables Claude to understand your calendar commitments, helping you manage your schedule more effectively. Available on Pro, Max, Team, and Enterprise plans. All Claude integrations are currently in beta. ## How to use Calendar integration ### 1. Ask about your schedule Simply ask Claude questions about your calendar. Claude automatically detects when calendar data is needed. **Example questions:** * "What meetings do I have tomorrow?" * "When is my next meeting with the product team?" * "Do I have any conflicts next week?" * "Who's attending the budget review meeting?" ### 2. Review Claude's response Claude provides answers that include: * Clear answers to your questions * Citations indicating which calendar events were used * Links to original events when applicable ### 3. Follow up You can ask for more details about: * Meeting attendees * Event timing and duration * Related meetings and patterns ## Privacy and data handling ### Authentication You must authenticate directly to your Google account. For Claude for Work (Team/Enterprise) plans, an Owner or Primary Owner must enable integrations at the account level. ### Data access * Claude accesses only data from your connected Google account * Access occurs only when you explicitly request it * Minimum information is retrieved to answer your question * Your existing calendar permissions are mirrored ## Limitations * Claude cannot create, modify, or delete calendar events * Claude cannot send calendar invitations * Only calendars you have access to can be searched ## Related topics Search and analyze your emails. Connect your documents. # Google Drive integration Source: https://claude.com/docs/connectors/google/drive Connect Google Docs directly to Claude The Google Drive integration lets you connect Google Docs directly to Claude on paid Claude.ai plans. You can add documents by pasting URLs or selecting recent files to provide context for your conversations. Available on Pro, Max, Team, and Enterprise plans. ## How to add Google Docs ### In chats 1. Click the plus sign (+) in the chat interface 2. Select "Add from Google Drive" 3. Authenticate with Google on first use 4. Search recent documents or paste a document URL 5. Claude accesses and processes the document when you send your message ### In projects The integration works only in private projects: 1. Click "Add Content" in project knowledge 2. Select "Google Drive" 3. Authenticate on first use 4. Search or paste a document URL 5. The document becomes available to Claude within that project ## Supported file types | Type | Supported | Notes | | -------------------- | --------- | -------------------------------- | | Google Docs | ✅ | Up to 10MB, text extraction only | | Google Sheets | ❌ | Not currently supported | | Google Slides | ❌ | Not currently supported | | Images in docs | ❌ | Not extracted | | Comments/Suggestions | ❌ | Not extracted | Convert .docx files by opening in Google Docs, clicking "File," then "Save as Google Docs." ## Key features * **Live sync**: Documents continue syncing with the latest Google Drive version * **Multiple documents**: Add multiple docs if they fit the context window * **Permission-based**: You can only sync documents you have permission to view ## Frequently asked questions Yes, documents continue syncing with the latest Google Drive version. Yes, you can add multiple docs as long as they fit within the context window. You'll lose document preview access but your conversation history remains. ## Troubleshooting For reconnection errors: 1. Navigate to **Settings > Integrations** 2. Find Google Drive 3. Click the menu button (...) 4. Select "Disconnect" 5. Authenticate again when prompted For persistent issues, disconnect from Google account connections at [myaccount.google.com](https://myaccount.google.com), search "Claude for Google Drive," and delete all connections. All Claude.ai integrations are currently in beta. ## Related topics Search and analyze your emails. Access your calendar information. # Gmail integration Source: https://claude.com/docs/connectors/google/gmail Search and analyze emails with Claude The Gmail integration enables Claude to search your emails and provide answers based on your email content, reducing time spent retrieving information. Available on Pro, Max, Team, and Enterprise plans. All Claude integrations are currently in beta. ## How to use Gmail integration ### 1. Ask a question Simply ask Claude a question that needs email information. Claude automatically detects when email data is needed. **Example questions:** * "What did Sarah say about the project deadline?" * "Find emails about the Q4 budget review" * "Summarize my conversation with the sales team last week" ### 2. Review Claude's response Claude provides answers that include: * Clear answers to your questions * Citations indicating which emails were used * Links to original sources when applicable ### 3. Follow up You can ask for more details, such as: * Requesting additional email information * Finding related threads * Summarizing longer conversations ## Understanding citations Citations show which specific emails Claude used to answer your question. You can follow links back to original sources for verification and additional context. ## Privacy and data handling ### Authentication You must authenticate directly to your Google account. For Claude for Work (Team/Enterprise) plans, an Owner or Primary Owner must enable integrations at the account level. ### Data access * Claude accesses only data from your connected Google account * Access occurs only when you explicitly request it * Minimum information is retrieved to answer your question * Your existing Gmail permissions are mirrored ## Limitations * Claude cannot create, send, or modify emails * Embedded images in emails are not visible to Claude * Only emails you have access to can be searched ## Related topics Access your calendar information. Connect your documents. # Microsoft 365 connector Source: https://claude.com/docs/connectors/microsoft/365 Connect SharePoint, OneDrive, Outlook, and Teams to Claude The Microsoft 365 connector enables Claude to search, analyze, and access information across SharePoint, OneDrive, Outlook, and Teams. Available for Team and Enterprise plan users only. ## Capabilities With this connector, Claude can: * **Search and analyze documents** across SharePoint sites and OneDrive libraries * **Access email threads** and analyze Outlook communications * **Review meeting information** from Teams Calendar * **Pull insights** from Teams Chat discussions ## Setup requirements ### Prerequisites * Claude user with Owner or Primary Owner role * Global Administrator access to Microsoft Entra tenant * Active Microsoft 365 accounts for all users ### Phase 1: Administrator setup **Automatic Setup (Recommended):** 1. Navigate to **Admin Settings > Connectors** 2. Click "Browse connectors" 3. Find Microsoft 365 and select "Add to your team" 4. Connect individually and grant organization-wide permissions 5. (Optional) Restrict user access or revoke specific permission scopes ### Phase 2: User enablement Once enabled by administrators, team members: 1. Navigate to **Settings > Connectors** 2. Find Microsoft 365 and click "Connect" 3. Authenticate with credentials ## Usage Ask Claude questions requiring Microsoft 365 data. Claude automatically detects necessary tools and retrieves information. ### Example queries * "Find the Q4 strategic planning document in SharePoint" * "Summarize email conversations about the product launch" * "What discussions happened in Teams about the marketing campaign?" * "Review meeting notes from last week's leadership sync" ## What you can access | Service | Capabilities | | ----------------------- | ---------------------------------------- | | **SharePoint/OneDrive** | Search and analyze documents | | **Outlook** | Search email threads and archived emails | | **Teams Calendar** | Review meeting summaries and attendance | | **Teams Chat** | Access channel and chat discussions | ## Permissions All permissions are delegated—Claude acts on behalf of users and can only access data you already have access to. The integration provides **read-only access**—Claude cannot modify, delete, or create content. ## Troubleshooting * Verify correct Microsoft 365 credentials * Check active license status * Review organizational third-party app policies * Try a different browser * Clear cookies and cache * Verify direct access to the document in Microsoft 365 * Ensure document is in SharePoint/OneDrive (not local) * Recently uploaded documents may need time to index * Use specific SharePoint site names * Search by exact filename * Be more specific about requirements * Specify locations and date ranges * Use exact phrases * Break complex queries into simpler questions # Connectors overview Source: https://claude.com/docs/connectors/overview Connect Claude to external tools, data, and UI through MCP Connectors extend Claude's capabilities by connecting it to external tools and data sources. They are powered by the [Model Context Protocol (MCP)](/docs/connectors/building/mcp), an open standard created by Anthropic that provides a unified way for AI applications to interact with the outside world. ## How connectors work Connectors can do two things: * **Provide tools and information** — Give Claude access to external data and the ability to take actions (search files, read emails, create issues, etc.) * **Surface UI components** — Render interactive visual elements directly in the conversation through [MCP Apps](/docs/connectors/building/mcp-apps/getting-started) **Building for Claude?** Most partners ship both a remote MCP server and a plugin that wraps it with skills. See [what to build](/docs/connectors/building/what-to-build) for the decision guide. ## Types of connectors ### Prebuilt integrations Anthropic provides first-party integrations with popular services like Google Drive, Gmail, Google Calendar, GitHub, Slack, and Microsoft 365. These are ready to use with no setup beyond authentication. See [Getting started](/docs/connectors/getting-started) for setup instructions. ### Remote MCP servers [Remote MCP servers](/docs/connectors/custom/remote-mcp) communicate with Claude over the internet, giving it access to cloud-hosted tools and data. You can connect to existing remote MCP servers or build your own for any tool or service. ### MCP Apps [MCP Apps](/docs/connectors/building/mcp-apps/getting-started) allow MCP servers to display interactive UI elements in conversational MCP clients. Rather than only returning text, an MCP App can render charts, maps, forms, and other visual components directly in the chat. See the [design guidelines](/docs/connectors/building/mcp-apps/design-guidelines) and [cross-platform compatibility](/docs/connectors/building/mcp-apps/cross-compatibility) docs for building MCP Apps. ### MCP Bundles [MCP Bundles (MCPB)](/docs/connectors/custom/desktop-extensions) package MCP servers with their dependencies for distribution as desktop extensions. MCPB handles cross-platform compatibility, dependency management, code signing, and centralized version updates — making it suitable for enterprise deployment of local MCP servers to Claude Desktop. ### Self-serve local MCP Local MCP servers distributed through third-party package registries like npm or PyPI cannot be listed directly in the Connectors Directory. To distribute a local server, package it as an [MCPB](/docs/connectors/building/mcpb) for the Desktop Extensions gallery, or bundle it in a [plugin](/docs/plugins/overview) using `.mcp.json` and submit it to the [plugin directory](/docs/plugins/submit). ## Ways to connect ### Connectors directory The [Connectors Directory](/docs/connectors/directory) is an open catalog of verified and reviewed MCP servers from third-party developers. These integrations are vetted by Anthropic and available across all Claude products. ### Third-party connectors You can build and connect your own MCP servers for proprietary tools or workflows. See [Third-party Connectors](/docs/connectors/custom/remote-mcp) for remote MCP and [Desktop Extensions](/docs/connectors/custom/desktop-extensions) for local integrations. ## Related concepts ### Plugins [Plugins](/docs/plugins/overview) combine MCP connectors, [Skills](/docs/skills/overview), slash commands, and sub-agents into shareable capability packages. They are available in Claude Code and Cowork. You can also [submit your plugin](/docs/plugins/submit) to the plugin directory. ## Platform availability Prebuilt integrations and directory connectors work across all Claude products: * **Claude.ai** — Full remote MCP support & MCP Apps * **Claude Desktop** — Full MCP support and local desktop extensions * **Claude Mobile** — Remote MCP access * **Claude Code** — Remote MCP access and plugins * **Claude Cowork** — Full MCP and plugin support ## Next steps Set up your first connector. Browse verified integrations. Create your own MCP server. Build UI components for Claude. # Slack integration Source: https://claude.com/docs/connectors/slack/index Use Claude directly in Slack and connect your workspace Integrate Claude and Slack in two ways: add Claude directly to your Slack workspace, or enable the Slack connector for your Claude apps. ## Claude in Slack Claude is available to paid Slack plan users. Slack admins must approve the app before individual users can access it. ### Ways to interact with Claude 1. **Direct messaging**: Start private conversations with @Claude 2. **AI assistant panel**: Click Claude's icon in Slack's AI assistant header 3. **Thread participation**: Mention @Claude in any thread for assistance All surfaces support the same Claude capabilities you've enabled, including web search and tool integrations. Team and Enterprise plan users with Claude Code access can route coding tasks directly to Claude Code by mentioning @Claude. ## Installation ### For Slack admins 1. Navigate to the Claude app in Slack's App Marketplace 2. Click "Add to Slack" 3. Review and approve for your organization 4. Deploy org-wide or to specific workspaces **For multi-workspace deployment:** * Access your Slack management workspace * Navigate to **Integrations → Installed apps → Add to more workspaces** * Toggle through relevant workspaces ### For individual users 1. Find Claude in your apps list or the Slack App Marketplace 2. Click "Connect Account" 3. Select your organization 4. Click "Authorize" to grant access 5. Return to Slack and click "+ New Chat" or @mention Claude **Tip**: Add Claude to your Slack header by clicking the three dots and selecting "Add this app to header." ## Slack connector Available for Team and Enterprise plans, the Slack connector allows Claude to search your workspace's channels, direct messages, and files for relevant context. You must install Claude in Slack before enabling and using the Slack connector. ### Enabling the connector **For Owners**: Navigate to **Admin settings > Connectors** and enable the Slack connector. **For Individual Users**: Go to **Settings > Connectors**, find Slack, and click "Connect." ## Managing connections ### Viewing connection status 1. Click Claude in your Slack sidebar 2. Go to the "Home" tab 3. View your connection details ### Disconnecting **Claude app**: Go to Claude's Home tab and click the red "Disconnect" button. **Slack connector**: Access [claude.ai/settings/connectors](https://claude.ai/settings/connectors), find Slack, and select "Disconnect." Disconnecting removes your account connection and deletes past conversations within 30 days. ## Privacy & data * Slack conversations remain separate from your Claude web history * Conversations initiated in Slack don't appear in your Claude chat history * Each platform maintains separate conversation histories * Conversations auto-delete within 30 days if you disconnect * Slack retention policies apply to your workspace messages ## Troubleshooting If your company Slack requires admin approval and you lack admin access, you'll see a "Request to install" prompt. Contact your Slack Admin to approve the app. # Deploy Cowork on 3P with Amazon Bedrock Source: https://claude.com/docs/cowork/3p/bedrock Set up AWS, choose an authentication path for your organization, and configure Cowork on 3P to use Claude models on Amazon Bedrock This page walks an IT administrator through a complete Amazon Bedrock deployment: enabling Claude in your AWS account, choosing the authentication path that fits your organization, preparing devices, and pushing the managed configuration. If you only need the list of configuration keys, skip to [Configure the app](#configure-the-app). ## Choose an authentication approach Bedrock supports several ways to authenticate, and the right one depends on whether your end users already work with AWS and whether you need per-user identity in CloudTrail. Use the table below to pick a path before doing any AWS or device setup. | Scenario | Use | Per-device prerequisite | Per-user CloudTrail identity | Notes | | ------------------------------------------ | ------------------------------------------------------------------ | --------------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Proof of concept, single team | [Bearer token](#bearer-token) (`inferenceBedrockBearerToken`) | None | No (shared key) | A long-lived secret distributed in the managed profile. Simplest to start; not recommended for broad rollout. | | Broad rollout to users without AWS tooling | [In-app AWS sign-in](#in-app-aws-sign-in) (`inferenceBedrockSso*`) | None | Yes | Users sign in through IAM Identity Center inside the app. No AWS CLI required. Requires app version 1.6.0 or later. | | Developers who already use the AWS CLI | [Named profile](#named-profile) (`inferenceBedrockProfile`) | AWS CLI v2 and a pushed `~/.aws/config` | Yes | IT can distribute the AWS config file directly; users run `aws sso login` to refresh. | | You already operate an LLM proxy | [Gateway provider](/docs/cowork/3p/gateway) instead of Bedrock | None | At your gateway | The proxy holds the AWS credentials; the app authenticates only to the proxy. | If a static credential in the managed profile is acceptable but a Bedrock API key is not, you can also set [`inferenceCredentialHelper`](/docs/cowork/3p/configuration#credential-helper) to an executable that prints a Bedrock bearer token to stdout at runtime. When more than one credential is configured, the app uses the first one present in this order: bearer token, named profile, in-app AWS sign-in, credential helper. ## Set up AWS These steps are performed once per AWS organization, regardless of which authentication approach you chose. You need an AWS account with permission to manage Bedrock model access and IAM Identity Center. In the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/), open **Model access** and request access to the Claude models you intend to deploy. Access is granted per region, so enable the models in the same region you will set as `inferenceBedrockRegion`. Skip this step if you chose the bearer-token approach. The named-profile and in-app AWS sign-in approaches both use IAM Identity Center to issue per-user AWS credentials. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/), create a permission set with an inline policy that allows Bedrock inference. The minimal policy is: ```json theme={null} { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*" }] } ``` Set the permission set's **Session duration** to between 8 and 12 hours. This value controls how long a user can run Cowork before needing to sign in to AWS again. If your organization uses Microsoft Entra ID, Okta, or another SAML identity provider, you can configure it as the identity source for IAM Identity Center so users sign in with their existing corporate credentials. The per-device steps on this page are unchanged. See [Connect to an external identity provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) in the AWS documentation. In IAM Identity Center, assign the permission set to the AWS account that hosts Bedrock, and add the users or groups who should have access. From the IAM Identity Center **Settings** page, note: * **AWS access portal URL**: of the form `https://d-xxxxxxxxxx.awsapps.com/start` (or your custom subdomain) * **Identity Center region**: the region where Identity Center is enabled, which may differ from your Bedrock region * **AWS account ID**: the 12-digit ID of the account where you enabled Bedrock * **Permission set name**: the name you gave the permission set above ## Prepare devices What each end-user device needs depends on the authentication approach you chose. ### In-app AWS sign-in No per-device preparation is required. Distribute the four `inferenceBedrockSso*` keys in the managed configuration; the app shows a **Sign in with AWS** page on first launch, runs the IAM Identity Center device-authorization flow in the system browser, and stores the resulting token encrypted with the operating system's secure storage. See [Sign in with AWS for Amazon Bedrock](/docs/cowork/3p/bedrock-aws-sign-in) for the full flow. ### Bearer token No per-device preparation is required. In the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/home#/api-keys), generate an API key. The key's underlying IAM principal must be allowed the `bedrock:CallWithBearerToken` action; without it, requests return an authorization error even though the key was created. You will place the key in the managed configuration in the next section. ### Named profile Each device needs AWS CLI v2 installed and an AWS config file that defines the named profile. You do not need users to run `aws configure sso` interactively. That command is a wizard that writes a profile stanza to `~/.aws/config` (macOS) or `%USERPROFILE%\.aws\config` (Windows), and you can distribute that file directly through your device-management tooling instead. A profile that uses IAM Identity Center looks like: ```ini theme={null} [profile claude-cowork] sso_session = corp sso_account_id = 123456789012 sso_role_name = ClaudeCoworkAccess region = us-west-2 [sso-session corp] sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start sso_region = us-east-1 sso_registration_scopes = sso:account:access ``` The recurring action for users is `aws sso login --profile claude-cowork`, which opens a browser for IAM Identity Center sign-in and caches a token under `~/.aws/sso/cache/`. To remove that manual step, some organizations deploy a launcher that runs `aws sts get-caller-identity` as a probe, falls back to `aws sso login` if it fails, and then opens Claude. If your AWS configuration files are not at the default location, set `inferenceBedrockAwsDir` to the directory that contains them. ## Configure the app With AWS set up and devices prepared, open the in-app configuration window (**Developer → Configure third-party inference**) on an evaluation device. In the **Connection** section, set **Inference provider** to **Bedrock** and fill in the **Bedrock credentials** card with the values for whichever authentication approach you chose: | Field | Bearer token | In-app AWS sign-in | Named profile | | -------------------- | -------------------- | ---------------------------------------- | ---------------------- | | AWS region | e.g. `us-west-2` | e.g. `us-west-2` | e.g. `us-west-2` | | AWS bearer token | your Bedrock API key | *leave empty* | *leave empty* | | Bedrock base URL | *optional* | *optional* | *optional* | | AWS profile name | *leave empty* | *leave empty* | `claude-cowork` | | AWS config directory | *leave empty* | *leave empty* | *only if not `~/.aws`* | | AWS SSO start URL | *leave empty* | `https://d-xxxxxxxxxx.awsapps.com/start` | *leave empty* | | AWS SSO region | *leave empty* | e.g. `us-east-1` | *leave empty* | | AWS SSO account ID | *leave empty* | `123456789012` | *leave empty* | | AWS SSO role name | *leave empty* | `BedrockInference` | *leave empty* | | Bedrock service tier | *optional* | *optional* | *optional* | Under **Identity & models**, add at least one **Model list** entry using the Bedrock inference-profile ID, for example `us.anthropic.claude-sonnet-4-20250514-v1:0`. Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow. ### Configuration keys The full set of Bedrock keys is below. Set `inferenceProvider` to `bedrock`, supply a region, and provide exactly one credential source. | Setting | Required | Description | | ------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AWS region
`inferenceBedrockRegion` | Yes | AWS region for the Bedrock runtime endpoint, for example `us-west-2` or `us-gov-west-1`. | | AWS bearer token
`inferenceBedrockBearerToken` | One credential source | Bedrock API key generated from the Amazon Bedrock console. | | AWS profile name
`inferenceBedrockProfile` | One credential source | AWS named profile from the device's AWS config and credentials files. | | AWS SSO start URL
`inferenceBedrockSsoStartUrl` | One credential source | AWS access portal URL. Enables in-app [AWS sign-in](/docs/cowork/3p/bedrock-aws-sign-in) (no AWS CLI needed). Set with the three SSO fields below. Ignored when a bearer token or profile is set. | | AWS SSO region
`inferenceBedrockSsoRegion` | One credential source | IAM Identity Center home region. | | AWS SSO account ID
`inferenceBedrockSsoAccountId` | One credential source | 12-digit AWS account ID assigned to users in IAM Identity Center. | | AWS SSO role name
`inferenceBedrockSsoRoleName` | One credential source | IAM Identity Center permission-set name granting `bedrock:InvokeModel*` on the account above. | | AWS config directory
`inferenceBedrockAwsDir` | No | Absolute path to the directory containing the AWS `config` and `credentials` files, if not the default `~/.aws`. | | Bedrock base URL
`inferenceBedrockBaseUrl` | No | Override the public regional endpoint, for example with a PrivateLink VPC interface endpoint. Must be `https://`. | | Bedrock service tier
`inferenceBedrockServiceTier` | No | One of `flex` or `priority`. Sent as the `X-Amzn-Bedrock-Service-Tier` header on every inference request. Leave unset for the default on-demand tier. Tier availability varies by model and region; reserved capacity uses a provisioned-throughput ARN as the model ID instead. | You must also set `inferenceModels` to a list of Bedrock inference-profile IDs, for example `us.anthropic.claude-sonnet-4-20250514-v1:0`. See the [Configuration reference](/docs/cowork/3p/configuration#models). ## What users experience The first-launch and re-authentication behavior depends on the authentication approach. | Approach | First launch | Re-authentication | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bearer token | Cowork opens directly; no user action. | Never, until you rotate the key in the managed profile. | | In-app AWS sign-in | Cowork shows a **Sign in with AWS** page; the user approves in the browser. | When the IAM Identity Center access portal session expires (defaults to 8 hours; configurable up to 90 days). The app prompts in-app; no terminal needed. | | Named profile | Cowork opens directly if the AWS SSO cache is fresh. If not, the first request fails and the user must run `aws sso login` in a terminal. | When the IAM Identity Center session expires (the permission set's session duration). | When a named-profile session has expired, requests fail with `ExpiredTokenException` from AWS, and the user runs `aws sso login` again. ## Troubleshoot To confirm which keys the app read and whether credentials validated, use **Help → Troubleshooting → Copy Managed Configuration Report**; see [Verifying the deployment](/docs/cowork/3p/installation#verifying-the-deployment) for that workflow and the common causes when the app does not enter 3P mode. Application log locations are listed in [Data storage and residency](/docs/cowork/3p/data-storage). # Sign in with AWS for Amazon Bedrock Source: https://claude.com/docs/cowork/3p/bedrock-aws-sign-in Configure per-user AWS IAM Identity Center authentication for Amazon Bedrock instead of distributing a bearer token or requiring the AWS CLI By default, Cowork on 3P authenticates to Amazon Bedrock with either a shared bearer token (`inferenceBedrockBearerToken`) or a named profile that relies on the AWS CLI being installed on every device (`inferenceBedrockProfile`). As an alternative, you can configure an interactive AWS sign-in backed by IAM Identity Center. Each user authenticates once with their corporate credentials in the browser, and the app stores an encrypted AWS SSO token on the device. No AWS CLI is required. Use AWS sign-in when you want: * Per-user identity in AWS CloudTrail instead of a single shared key * Access controlled through IAM Identity Center permission sets and group assignments * To roll out to users who do not have, and should not need, the AWS CLI installed The sign-in experience uses **your organization's AWS IAM Identity Center instance**. The app registers an OIDC client dynamically with your Identity Center at runtime, so you do not create or distribute a client ID. ## How it works When all four `inferenceBedrockSso*` keys are set and neither `inferenceBedrockBearerToken` nor `inferenceBedrockProfile` is present, the app shows a **Sign in with AWS** page the first time a user opens the Cowork tab. Clicking the button starts an OAuth device-authorization flow with your IAM Identity Center's OIDC endpoint and opens the AWS access portal in the system browser. The app displays a short verification code so the user can confirm that the browser prompt matches the app that requested it. Identity Center redirects the user to whichever identity provider you have configured (Entra ID, Okta, Google Workspace, or the Identity Center built-in directory). On success, the app stores the IAM Identity Center access token and refresh token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows) and relaunches into Cowork. At the start of each Cowork session, the app exchanges the stored token with IAM Identity Center for short-lived AWS credentials scoped to the configured account and permission set, and passes them into the session sandbox as `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN`. This is the same credential shape that `aws sso login` produces, obtained without the AWS CLI. If the stored token expires or is revoked, or if you deploy a different `inferenceBedrockSsoStartUrl`, the app clears the stored token and shows the sign-in page again. ## Prerequisites * An AWS organization with **IAM Identity Center** enabled * A permission set that grants Bedrock inference, assigned to your Cowork users on the account where Bedrock is enabled * Claude models enabled in Amazon Bedrock for the region you will set as `inferenceBedrockRegion` The IAM Identity Center setup is identical to what the named-profile approach requires. If you have already completed the [Set up AWS](/docs/cowork/3p/bedrock#set-up-aws) steps on the Bedrock deployment page, you can reuse that permission set and assignments here. ## Set up AWS sign-in In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/), create a permission set whose policy allows `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream`. The [Bedrock deployment page](/docs/cowork/3p/bedrock#set-up-aws) shows the minimal inline policy. Set the permission set's **Session duration** to between 8 and 12 hours. The app mints AWS credentials once at the start of each Cowork session, and those credentials last for this duration. A session that runs past it fails with an expired-token error until the user starts a new session. See [Notes and limitations](#notes-and-limitations). Assign the permission set to the AWS account where you enabled Bedrock, and add the Identity Center users or groups who should have access. From the IAM Identity Center **Settings** page, note the four values you will deploy via MDM: * **AWS access portal URL**, of the form `https://d-xxxxxxxxxx.awsapps.com/start` or your custom subdomain * **Identity Center region**, the home region of your Identity Center instance, which is often different from your Bedrock region * **AWS account ID**, the 12-digit ID of the account where you enabled Bedrock * **Permission set name**, the name you gave the permission set above Open the in-app configuration window (**Developer → Configure third-party inference**) on an evaluation device. In the **Connection** section, set **Inference provider** to **Bedrock**, then fill in the **Bedrock credentials** card: | Field | Value | | -------------------- | ------------------------------------------------- | | AWS region | Your Bedrock runtime region, e.g. `us-west-2` | | AWS bearer token | *leave empty* | | Bedrock base URL | *optional* | | AWS profile name | *leave empty* | | AWS config directory | *leave empty* | | AWS SSO start URL | `https://d-1234567890.awsapps.com/start` | | AWS SSO region | Your IAM Identity Center region, e.g. `us-east-1` | | AWS SSO account ID | `123456789012` | | AWS SSO role name | `BedrockInference` | | Bedrock service tier | *optional* | Leave **AWS bearer token** and **AWS profile name** empty. If either is set, it takes precedence and the sign-in page is never shown. Under **Identity & models**, add at least one **Model list** entry using the Bedrock inference-profile ID, for example `us.anthropic.claude-sonnet-4-20250514-v1:0`. Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow, or the [Configuration keys](#configuration-keys) table below if you author policy by hand. The sign-in flow and token refresh reach the IAM Identity Center endpoints for the region you set as `inferenceBedrockSsoRegion`: * `oidc..amazonaws.com` * `portal.sso..amazonaws.com` These hosts are included automatically in the **Egress Requirements** section of the in-app configuration window when the SSO keys are set, so if you built your firewall allowlist from that output, no additional changes are needed. The browser step also reaches your AWS access portal (`*.awsapps.com`) and, if federated, your external identity provider. ## User experience On first launch after the configuration is applied, the Cowork tab shows a **Sign in with AWS** page instead of the task composer. The user clicks the button, and the app opens the AWS access portal in the default browser with the authorization request prefilled. The app also displays a short verification code; the user confirms it matches the code shown on the AWS page and approves the request. The browser flow runs on the host, outside the Cowork sandbox, so it uses the user's existing identity-provider session and any security keys or passkeys configured on the device. After approval, the app relaunches into Cowork automatically. Users stay signed in across app restarts for as long as the IAM Identity Center session remains valid. This is the **AWS access portal session duration** under **Authentication** in the Identity Center settings; it defaults to 8 hours and can be extended up to 90 days. When it expires, the app shows the sign-in page again on next launch. To force a user to sign in again sooner, delete their active session from the IAM Identity Center console. ## Configuration keys | Setting | Type | Description | | ------------------------------------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------ | | AWS SSO start URL
`inferenceBedrockSsoStartUrl` | string | AWS access portal URL from IAM Identity Center **Settings**, for example `https://d-1234567890.awsapps.com/start`. | | AWS SSO region
`inferenceBedrockSsoRegion` | string | Home region of the IAM Identity Center instance. Often different from `inferenceBedrockRegion`. | | AWS SSO account ID
`inferenceBedrockSsoAccountId` | string | 12-digit AWS account ID where Bedrock is enabled and the permission set is assigned. | | AWS SSO role name
`inferenceBedrockSsoRoleName` | string | Name of the IAM Identity Center permission set that grants `bedrock:InvokeModel*`. | See [Deploy Cowork on 3P with Amazon Bedrock](/docs/cowork/3p/bedrock) for the full list of Bedrock keys, including `inferenceBedrockRegion` and `inferenceModels`. ## Notes and limitations * **Precedence.** If `inferenceBedrockBearerToken` or `inferenceBedrockProfile` is set, it is used and AWS sign-in is disabled. Remove those keys to switch an existing deployment to per-user sign-in. When AWS sign-in is configured, it takes precedence over `inferenceCredentialHelper`. * **All four keys required.** If only some of the `inferenceBedrockSso*` keys are set, the app logs a warning and ignores the partial configuration. * **One account and role per deployment.** Every user in a given managed configuration signs in to the same AWS account and assumes the same permission set. To give different groups different Bedrock permissions, deploy distinct configuration profiles with different `inferenceBedrockSsoRoleName` values. * **No mid-session credential refresh.** AWS credentials are minted once when a Cowork session starts and are valid for the permission set's session duration. A session that outlives that duration fails until restarted. Set the session duration long enough to cover a working day. * **Connection probe.** The in-app **Test connection** button reports that the connection cannot be verified in this mode, because the app cannot sign Bedrock requests outside the sandbox. This matches the behavior of named-profile mode and does not indicate a problem. * **Configuration rotation.** If you change `inferenceBedrockSsoStartUrl` in the managed profile, existing users are automatically signed out and prompted to sign in again on next launch. # Code tab Source: https://claude.com/docs/cowork/3p/code How Cowork on 3P configuration applies to the embedded Claude Code engine The Code tab in Cowork on third-party (3P) is the embedded [Claude Code](https://code.claude.com/docs/en/overview) interface. It runs the same Claude Code engine as the standalone CLI, with a graphical session manager, and it inherits your Cowork on 3P configuration automatically. ## How configuration propagates When the app starts a Code session, it translates your Cowork on 3P [configuration keys](/docs/cowork/3p/configuration) into the equivalent Claude Code settings and passes them to the session. You configure one profile, and both tabs honor it. Each key reaches Claude Code through one of two mechanisms, and the distinction matters if you also deploy Claude Code's own managed settings (see [the next section](#interaction-with-claude-codes-own-managed-settings)). ### Always applied These keys are passed directly to the Claude Code process as environment variables or launch options. They take effect on every Code session and cannot be overridden by user-level Claude Code settings or by a separately deployed `managed-settings.json`. | Cowork on 3P key | Effect in Code sessions | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `inferenceProvider` and all provider credential keys (`inferenceGateway*`, `inferenceVertex*`, `inferenceBedrock*`, `inferenceFoundry*`, `inferenceCredentialHelper*`) | Selects the inference backend and supplies credentials. Code sessions use the same provider, endpoint, and credentials as the Cowork tab. | | `inferenceModels` | Populates the model picker. The first entry is the default for new Code sessions. | | `disabledBuiltinTools` | Removes the listed tools from Code sessions. Tools your provider does not support, such as WebSearch on Amazon Bedrock, are removed automatically in addition to your list. | | `managedMcpServers` | Makes the same managed MCP servers available in Code sessions. The app handles the connection and authentication; the Code session sees only the resulting tool list. | | `otlpEndpoint`, `otlpProtocol`, `otlpHeaders`, `otlpResourceAttributes` | Routes Claude Code's OpenTelemetry metrics and logs to your collector. See [Telemetry](/docs/cowork/3p/telemetry). | | `disableEssentialTelemetry`, `disableNonessentialTelemetry` | Disables Claude Code's crash reporting and usage telemetry to Anthropic, mirroring the Cowork tab. | | `disableAutoUpdates` | The embedded Claude Code engine never self-updates regardless of this key; its version is managed by the app's own updater. | | `inferenceMaxTokensPerWindow`, `inferenceTokenWindowHours` | The token budget is shared across the Cowork and Code tabs and enforced before each turn. | ### Applied as managed policy These keys are translated into Claude Code [managed settings](https://code.claude.com/docs/en/settings#settings-files) and supplied to the session as policy. They take precedence over user and project settings, but they participate in Claude Code's managed-settings precedence if you have also deployed a separate Claude Code policy. | Cowork on 3P key | Claude Code policy it produces | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `coworkEgressAllowedHosts` | A network sandbox restricted to your hosts plus the inference and telemetry endpoints, `WebFetch` permission rules for the same hosts, and `allowManagedDomainsOnly`. | | `allowedWorkspaceFolders` | Filesystem sandbox and `Read`/`Edit` permission rules scoped to your allowed roots, plus `additionalDirectories`. The app also refuses to start a Code session outside an allowed root. | | `managedMcpServers` | An `allowedMcpServers` list containing only your managed servers, with `allowManagedMcpServersOnly` set so users cannot add their own from Claude Code's side. | ## Interaction with Claude Code's own managed settings Claude Code can also be configured directly by deploying a [`managed-settings.json` file](https://code.claude.com/docs/en/settings#settings-files), an OS configuration profile for Claude Code, or (with Anthropic authentication) server-managed settings. If a device has any of these, Claude Code treats it as the administrator policy and, by default, **ignores** the policy values Cowork supplies from the [Applied as managed policy](#applied-as-managed-policy) table. The [Always applied](#always-applied) keys are unaffected. To have Cowork's restrictions apply on top of your Claude Code policy, set `parentSettingsBehavior` to `"merge"` in the Claude Code managed settings you deploy: ```json managed-settings.json theme={null} { "parentSettingsBehavior": "merge" } ``` With `"merge"`, Cowork's policy values are layered under your Claude Code policy. Your values win any conflict, deny and allow lists are unioned, and Cowork's values are filtered so they can only tighten policy, never loosen it. See [`parentSettingsBehavior`](https://code.claude.com/docs/en/settings#available-settings) in the Claude Code settings reference. Requires Claude Code v2.1.133 or later, which ships with Cowork on 3P. In a third-party deployment there is no Anthropic authentication, so Claude Code's server-managed settings tier is never present. If you have not separately deployed a Claude Code `managed-settings.json` or OS profile, Cowork's policy applies automatically and you do not need to set `parentSettingsBehavior`. ## Further reading * [Claude Code settings reference](https://code.claude.com/docs/en/settings) * [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing) * [Settings precedence](https://code.claude.com/docs/en/settings#settings-precedence) ## Disabling the Code tab To remove the Code tab entirely, set `isClaudeCodeForDesktopEnabled` to `false` in your Cowork on 3P configuration. Users see only the Cowork tab. # Configuration reference Source: https://claude.com/docs/cowork/3p/configuration Every managed-configuration key Cowork on 3P supports, what it controls, and recommended security profiles Cowork on third-party (3P) is configured entirely through OS-native managed preferences: a `.mobileconfig` profile on macOS or registry policy on Windows. This page documents every supported key. The easiest way to author a configuration is the in-app configuration window (**Developer → Configure third-party inference**), which validates values, shows per-provider requirements, and exports directly to `.mobileconfig` or `.reg`. Use this reference when you need to author policy by hand, audit an existing profile, or understand exactly what a key does. ## How keys are read | Platform | Managed (MDM) location | Local (user) location | | -------- | --------------------------------------------------------------------------------- | -------------------------------------------------------- | | macOS | `/Library/Managed Preferences//com.anthropic.claudefordesktop.plist` | `~/Library/Application Support/Claude-3p/configLibrary/` | | Windows | `HKLM\SOFTWARE\Policies\Claude` (machine), `HKCU\SOFTWARE\Policies\Claude` (user) | `%LOCALAPPDATA%\Claude-3p\configLibrary\` | The local location is a directory: `_meta.json` records which saved configuration is applied, and each configuration is a `.json` file alongside it. The in-app configuration window writes here. When a managed source is present, it wins and locally written values are ignored. Configuration is read **once at launch**, so fully quit and reopen the app after any change. See [Installation and setup](/docs/cowork/3p/installation) for the full precedence rules. ### Value types All values are stored as **strings** in the OS preference store, even booleans and arrays. | Documented type | What to write | Example | | ---------------- | ---------------------------------------------------------------------- | --------------------------------------------- | | string | Plain string | `vertex` | | boolean | `"true"` or `"false"` (or `1` / `0`) | `"true"` | | integer | Decimal string | `"3600"` | | string\[] (JSON) | JSON array **encoded as a string** (not a native plist/registry array) | `["claude-sonnet-4","claude-opus-4"]` | | object (JSON) | JSON object mapping name to value, as a string | `{"X-Org-Id":"team1"}` | | object\[] (JSON) | JSON array of objects, as a string | see [`managedMcpServers`](#managedmcpservers) | The most common configuration mistake is writing array- or object-typed keys as native plist/registry structures. Keys like `inferenceModels`, `disabledBuiltinTools`, `coworkEgressAllowedHosts`, and `otlpHeaders` must be **JSON strings**. In a `.mobileconfig`, that means a single `` element containing `[...]` or `{...}`, not an `` or ``. The sections below match the sidebar of the in-app configuration window. ***
## Connection ### Activation | Setting | Type | Description | | ---------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Inference provider
`inferenceProvider` | string | Selects the inference backend. One of `gateway`, `vertex`, `bedrock`, `foundry`. **3P mode activates only when this key is set *and* the required credential keys for the selected provider are present and valid**; otherwise the app launches in standard mode. | | Organization UUID
`deploymentOrganizationUuid` | string | A UUID **you generate** to identify your deployment, in standard `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx` format. Used to attribute telemetry to your organization. | | Hide Anthropic sign-in
`disableDeploymentModeChooser` | boolean | When `true`, hides the **Sign in to Anthropic** option on the sign-in screen so users see only the third-party option from this configuration. The screen itself still appears. Any previously persisted sign-in choice is ignored. | Generate and set `deploymentOrganizationUuid` before rollout. Anthropic uses this value to locate crash reports and telemetry from your fleet when you open a support case. If it's unset, your telemetry is tagged with a shared placeholder UUID (`00000000-0000-4000-8000-000000000001`) that every unconfigured deployment also uses, and Anthropic cannot distinguish your organization's events from anyone else's. ### Provider credentials Each provider has its own required keys, documented on its dedicated page below. Keys for providers other than the one selected in `inferenceProvider` are ignored. `inferenceProvider: "vertex"` `inferenceProvider: "bedrock"` `inferenceProvider: "foundry"` `inferenceProvider: "gateway"` ### Credential helper For environments where static API keys aren't permitted, Cowork on 3P can invoke an executable you provide to fetch a short-lived credential at runtime. | Setting | Type | Description | | ------------------------------------------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Credential helper script
`inferenceCredentialHelper` | string | Absolute path to an executable on the host. Its **stdout** is used as the inference credential, replacing the static API-key key for the chosen provider. | | Credential helper TTL
`inferenceCredentialHelperTtlSec` | integer | Cache the helper's output for this many seconds before re-running it. Default `3600`. | The helper runs on the host (outside the sandbox) at session start and on cache expiry. Pair this with your organization's SSO, secrets manager, or PKI tooling. The helper applies to Bedrock, Foundry, and gateway providers; it is not invoked for Google Cloud's Vertex AI, which uses [file-based credentials or Google sign-in](/docs/cowork/3p/vertex#authentication). In the in-app configuration window, the **Credential helper script** field has a **Run** button that executes the script once and shows a status chip with the exit code, the run time, and whether stdout produced a non-empty credential. Use it to validate the script before exporting the configuration. ### Models | Setting | Type | Description | | --------------------------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Model list
`inferenceModels` | (string \| object)\[] (JSON) | Models to expose in the picker. Use the **provider's exact model ID**: Vertex publisher IDs (`claude-sonnet-4@20250514`), Bedrock inference-profile IDs (`us.anthropic.claude-sonnet-4-...-v1:0`), or Foundry deployment names. The first entry is the default. **Required for Vertex, Bedrock, and Foundry**; gateways auto-discover available models. Entries may be plain strings or objects of the form `{"name": "", "supports1m": true}` — see below. | #### Offering a 1M-token context variant If your provider serves a model with the extended 1M-token context window, you can expose it as a separate picker entry by setting `supports1m: true` on that model's entry: ```json theme={null} "inferenceModels": [ { "name": "claude-opus-4", "supports1m": true }, "claude-sonnet-4" ] ``` `supports1m` is a capability assertion you make about your deployment — Cowork doesn't probe the provider to verify it. Only set it for models you've confirmed support the extended window; selecting a 1M variant on a model that doesn't will fail mid-session once the conversation grows past the model's actual limit. **Gateway:** the `name` must be the exact ID your gateway's `/v1/models` endpoint returns. If you set `supports1m` on an alias (`sonnet`) but discovery returns the full ID (`claude-sonnet-4-6`), the variant won't appear. ## Sandbox & workspace | Setting | Type | Default | Description | | ---------------------------------------------------------- | ---------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Disabled built-in tools
`disabledBuiltinTools` | string\[] (JSON) | `[]` | Built-in tool names to remove from the agent entirely (e.g. `["WebSearch","Bash"]`). Valid names: `Bash`, `Read`, `Write`, `Edit`, `Glob`, `Grep`, `NotebookEdit`, `WebFetch`, `WebSearch`, `Task`, `TodoWrite`, `TaskCreate`, `TaskUpdate`, `TaskGet`, `TaskList`, `TaskStop`, `Skill`, `REPL`, `JavaScript`, `AskUserQuestion`, `ToolSearch`, `SendUserMessage`. | | Allowed workspace folders
`allowedWorkspaceFolders` | string\[] (JSON) | unrestricted | Absolute paths users may attach as workspace folders. Leading `~` expands to the user's home. When set, any path outside this list is rejected. | | Allowed egress hosts
`coworkEgressAllowedHosts` | string\[] (JSON) | inference endpoint only | Hostnames the agent's web-fetch and shell tools may reach. Supports `*.example.com` wildcards. `["*"]` disables egress filtering. The configured inference endpoint is always allowed implicitly. When unset, only the inference endpoint is reachable; the agent's package installs and web fetches will fail. | | Allow Claude Code tab
`isClaudeCodeForDesktopEnabled` | boolean | `true` | Show the Code tab. | `coworkEgressAllowedHosts` governs the **Cowork tab's** sandbox — web fetch, shell commands, and package installs run by the Cowork agent. It does **not** restrict the Code tab, which executes on the host with the user's normal network access. To remove the Code tab, set `isClaudeCodeForDesktopEnabled` to `false`. ## Connectors & extensions | Setting | Type | Default | Description | | -------------------------------------------------------------------- | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Managed MCP servers
`managedMcpServers` | object\[] (JSON) | `[]` | Remote MCP servers deployed to all users. See [schema](#managedmcpservers). | | Allow user-added MCP servers
`isLocalDevMcpEnabled` | boolean | `true` | Allow users to add their own local MCP servers from **Settings → Developer**. End users cannot add remote MCP servers regardless of this setting. | | Allow desktop extensions
`isDesktopExtensionEnabled` | boolean | `true` | Allow installing local desktop extensions (`.mcpb`). | | Show extension directory
`isDesktopExtensionDirectoryEnabled` | boolean | `true` | Show the Anthropic extension directory in the Connectors UI. | | Require signed extensions
`isDesktopExtensionSignatureRequired` | boolean | `false` | Reject unsigned desktop extensions. | See [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) for the org-plugins directory layout and the full `managedMcpServers` schema. ### `managedMcpServers` A JSON-stringified array of server objects: | Field | Required | Description | | --------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Yes | Unique display name. | | `url` | Yes | Server URL. Must be `https://`. | | `transport` | — | `"http"` (default) or `"sse"`. | | `headers` | — | Static string→string header map. Mutually exclusive with `oauth`. | | `headersHelper` | — | Absolute path to an executable that prints a JSON header object on stdout, for short-lived auth tokens. Mutually exclusive with `oauth`. | | `headersHelperTtlSec` | — | Cache helper output for this many seconds. | | `oauth` | — | Enables a browser-based OAuth flow; tokens stored in the OS keychain. Set to `true` for dynamic client registration, or to an object that supplies a pre-registered client (see below). Mutually exclusive with `headers` / `headersHelper`. | | `toolPolicy` | — | Map of tool name → `"allow"` / `"ask"` / `"blocked"`. Locks the per-tool approval state for that server. | When the MCP server's OAuth provider doesn't support dynamic client registration (for example, Slack or Microsoft Entra ID), set `oauth` to an object describing a client you've registered with that provider: | `oauth` field | Required | Description | | -------------- | -------- | ------------------------------------------------------------------------------------------------------ | | `clientId` | Yes | Client ID of the pre-registered OAuth client. | | `tenantId` | — | Tenant ID, for providers that scope clients to a tenant (e.g. Microsoft Entra ID). | | `scope` | — | Space-separated OAuth scopes to request. | | `callbackPort` | — | Loopback port the client's registered redirect URI uses (1024–65535). Defaults to `53280`. | | `callbackHost` | — | Loopback host: `127.0.0.1` (default) or `localhost`. Set to match the registered redirect URI exactly. | The app builds the redirect URI as `http://:/callback`; register that exact value with the OAuth provider. ## Telemetry & updates See [Telemetry and egress](/docs/cowork/3p/telemetry) for what each category sends and the network paths involved. ### Anthropic telemetry and updates | Setting | Type | Default | Description | | ----------------------------------------------------------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Block essential telemetry
`disableEssentialTelemetry` | boolean | `false` | Block crash reports and error telemetry to Anthropic. **Disabling this opts you into a manual support model** in which your team collects and sends logs to Anthropic directly. | | Block nonessential telemetry
`disableNonessentialTelemetry` | boolean | `false` | Block product-usage analytics to Anthropic. | | Block nonessential services
`disableNonessentialServices` | boolean | `false` | Block non-critical third-party services: connector favicons and the artifact-preview iframe. | | Block auto-updates
`disableAutoUpdates` | boolean | `false` | Block update checks and downloads from Anthropic. Your IT team must redistribute new builds. | | Auto-update enforcement window
`autoUpdaterEnforcementHours` | integer | `72` | Force a pending update to install after this many hours (1–72). Ignored when auto-updates are disabled. | ### OpenTelemetry export Export full session activity to your own collector. See [Monitoring](/docs/cowork/monitoring) for the event schema. | Setting | Type | Description | | --------------------------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | OpenTelemetry collector endpoint
`otlpEndpoint` | string | Base URL of your OTLP collector. When set, sessions export logs and metrics (prompts, tool calls, token counts). The endpoint host is automatically added to the sandbox network allowlist. | | OpenTelemetry exporter protocol
`otlpProtocol` | string | `http/protobuf` (default), `http/json`, or `grpc`. | | OpenTelemetry exporter headers
`otlpHeaders` | object (JSON) | Headers sent on every OTLP request, as a JSON object mapping header name to value (e.g. `{"Authorization":"Bearer …"}`). A comma-separated `key=value` string (the `OTEL_EXPORTER_OTLP_HEADERS` format) is also accepted for compatibility. | | OpenTelemetry resource attributes
`otlpResourceAttributes` | object (JSON) | Extra resource attributes attached to every exported span and metric, as a JSON object mapping attribute name to value (e.g. `{"enduser.id":"alice@example.com"}`). Appended to the app's built-in attributes; keys that collide with built-ins such as `service.name` are dropped. A comma-separated `key=value` string is also accepted for compatibility. | ## Usage limits | Setting | Type | Description | | -------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Max tokens per window
`inferenceMaxTokensPerWindow` | integer | Total input + output tokens permitted per device per window. When reached, the app refuses new messages until the window resets. Enforced locally; persists across restarts. | | Token cap window
`inferenceTokenWindowHours` | integer | Length of the tumbling window for the cap above, 1–720 hours. |
## Plugins & skills Plugins and skills have no configuration keys. They are distributed by placing plugin bundles in the [org-plugins directory](/docs/cowork/3p/extensions#organization-plugins-admin) on each device, which the configuration window's Plugins & skills section displays for reference. *** ## Recommended security profiles The profiles below are illustrative examples rather than built-in presets, and the labels are descriptive only. Use them as starting points and adjust for your environment. Layer the inference-provider keys for your cloud on top of whichever profile you choose. Recommended for most enterprise deployments. Telemetry and auto-updates stay on so Anthropic can diagnose issues and ship fixes; users can extend Cowork with their own connectors. | Key | Value | | ------------------------------------- | ------------------ | | `deploymentOrganizationUuid` | `` | | `autoUpdaterEnforcementHours` | `24` | | `isDesktopExtensionSignatureRequired` | `true` | | `otlpEndpoint` | `` | For regulated environments that need to control what users can connect Cowork to, while keeping Anthropic supportability. | Key | Value | | ------------------------------------ | ------------------------ | | `deploymentOrganizationUuid` | `` | | `disableNonessentialTelemetry` | `true` | | `disableNonessentialServices` | `true` | | `isLocalDevMcpEnabled` | `false` | | `isDesktopExtensionEnabled` | `false` | | `isDesktopExtensionDirectoryEnabled` | `false` | | `allowedWorkspaceFolders` | `["~/Documents/Claude"]` | | `coworkEgressAllowedHosts` | `["*.your-org.com"]` | | `otlpEndpoint` | `` | For air-gapped or maximally restricted environments. **The only traffic leaving the device goes to your inference endpoint and OTLP collector.** With this profile, Anthropic has zero remote visibility, so your team owns log collection and update distribution. | Key | Value | | ------------------------------------ | -------------------------- | | `disableEssentialTelemetry` | `true` | | `disableNonessentialTelemetry` | `true` | | `disableNonessentialServices` | `true` | | `disableAutoUpdates` | `true` | | `isLocalDevMcpEnabled` | `false` | | `isDesktopExtensionEnabled` | `false` | | `isDesktopExtensionDirectoryEnabled` | `false` | | `disabledBuiltinTools` | `["WebSearch","WebFetch"]` | | `coworkEgressAllowedHosts` | `[]` | | `allowedWorkspaceFolders` | `["~/Documents/Claude"]` | | `otlpEndpoint` | `` | # Connect to Microsoft 365 Source: https://claude.com/docs/cowork/3p/connectors-m365 Give Claude access to your organization's Outlook, OneDrive, SharePoint, and Teams data through a connector you register in your own Microsoft Entra tenant. When Cowork is deployed on third-party inference, Claude can read your organization's Microsoft 365 data—Outlook mail and calendar, OneDrive, SharePoint, and Teams—through Anthropic's Microsoft 365 connector service. The desktop app authenticates with an app registration you create in your own Microsoft Entra tenant, and the connector service performs the Microsoft Graph calls on the signed-in user's behalf. Anthropic's connector service receives the desktop's delegated access token on each request and exchanges it on-behalf-of the user for a short-lived Graph token. Neither token is persisted server-side beyond the request, and Anthropic never holds your tenant's client secrets or the user's refresh token (the refresh token stays encrypted on the user's device). Setup takes about fifteen minutes and requires a Global Administrator or Cloud Application Administrator in your Entra tenant. ## How the connection works Three applications participate in the sign-in chain. Understanding which one each ID refers to makes the setup steps below easier to follow. | Application | Owner | Purpose | | ----------------------- | ------------------------------- | ---------------------------------------------------------------------------- | | Desktop client app | You (registered in your tenant) | What Claude Desktop signs in as. Public client, PKCE, no secret. | | Anthropic connector app | Anthropic (multi-tenant) | Receives the desktop's token and calls Microsoft Graph on the user's behalf. | | Microsoft Graph | Microsoft | The Microsoft 365 data APIs. | Claude Desktop signs in through your desktop client app, receives a token scoped to the Anthropic connector app, and sends that token to Anthropic's connector service. The connector service exchanges it for a Graph token using the on-behalf-of flow and makes Graph calls as the signed-in user. ## Set up the connector The four steps below cover tenant consent, app registration, allowlisting, and desktop configuration. A tenant administrator must consent to Anthropic's multi-tenant connector app once for the organization. This creates a service principal in your tenant; no secret is exchanged. Open the following URL after replacing `YOUR_TENANT_ID` with the Directory (tenant) ID shown in **Entra admin center → Overview**. ```text theme={null} https://login.microsoftonline.com/YOUR_TENANT_ID/adminconsent?client_id=07c030f6-5743-41b7-ba00-0a6e85f37c17 ``` The consent screen lists the delegated Microsoft Graph permissions the connector requests. All are read-only: | Scope | Purpose | | ----------------------------------------- | ----------------------------------------------------------- | | `User.Read` | Read the signed-in user's profile | | `Mail.Read`, `Mail.Read.Shared` | Read mail in the user's and shared mailboxes | | `Calendars.Read`, `Calendars.Read.Shared` | Read events in the user's and shared calendars | | `Files.Read.All` | Read files the user can access in OneDrive and SharePoint | | `Sites.Read.All` | Read SharePoint site content the user can access | | `Chat.Read`, `ChatMessage.Read` | Read Teams chat messages the user can access | | `offline_access` | Allow the desktop to refresh its token without re-prompting | Review the permissions and select **Accept**. FedRAMP and GovCloud deployments use a different connector app ID and a different connector service hostname. Contact your Anthropic representative for the app ID to use in this URL and in the scope string in step 4, and for the connector URL to use in step 4. Create the public client that Claude Desktop will sign in as. 1. In **Entra admin center → App registrations → New registration**, set **Name** to `Claude Desktop` (or your preferred name), set **Supported account types** to *Accounts in this organizational directory only*, and add a **Redirect URI** of platform *Mobile and desktop applications* with the value `http://127.0.0.1/callback`. 2. Select **Register**, then note the **Application (client) ID** and **Directory (tenant) ID** shown on the overview page. 3. Under **API permissions → Add a permission → APIs my organization uses**, search for `Anthropic` (or paste the connector app ID from step 1), select **Delegated permissions → access\_as\_user**, then **Add permissions**. 4. Select **Grant admin consent for \{your organization}**. No client secret is needed; this is a public client that uses PKCE. Anthropic maintains an allowlist of tenant and client IDs that may call the connector service. Email your Anthropic representative, or open a support ticket, with your Directory (tenant) ID and the Application (client) ID from step 2. Allowlisting is typically completed within two to three business days, as it requires a connector service deployment. Until the allowlist is updated, sign-in will succeed but the connector returns *Client application is not authorized for this resource*. In the Claude Desktop setup window, open **Connectors**, select **Add → Microsoft 365**, and enter the values below. | Field | Value | | --------- | -------------------------------------------------------------------------- | | Client ID | The Application (client) ID from step 2 | | Tenant ID | Your Directory (tenant) ID | | Scope | `api://07c030f6-5743-41b7-ba00-0a6e85f37c17/access_as_user offline_access` | Select **Save**, then deploy the configuration through your device-management tool as usual. If you manage configuration through JSON or a plist directly instead of the setup window, add the following entry to [`managedMcpServers`](/docs/cowork/3p/configuration#managedmcpservers). ```json theme={null} { "name": "m365", "url": "https://microsoft365.mcp.claude.com/mcp", "transport": "http", "oauth": { "clientId": "APPLICATION_CLIENT_ID_FROM_STEP_2", "tenantId": "DIRECTORY_TENANT_ID", "scope": "api://07c030f6-5743-41b7-ba00-0a6e85f37c17/access_as_user offline_access" } } ``` ## Sign in as a user After the configuration is deployed, each user opens **Settings → Connectors** in Claude Desktop and selects **Connect** next to Microsoft 365. Their browser opens to your tenant's sign-in page; once they consent, the connector is ready to use in conversations. ## Allow the required network hosts In addition to the [base egress hosts](/docs/cowork/3p/telemetry#required-egress-paths), Claude Desktop needs outbound HTTPS access to the hosts below. The connector service itself calls `graph.microsoft.com` from Anthropic's infrastructure, so user devices do not need egress to Graph. | Host | Purpose | | ----------------------------- | ------------------------------------------------------------- | | `login.microsoftonline.com` | Microsoft Entra sign-in | | `microsoft365.mcp.claude.com` | The connector service (substitute your deployment's hostname) | ## Troubleshoot sign-in errors The errors below are the ones most commonly seen during setup. Each maps to a specific step that was missed or misconfigured. | Error | Cause | Fix | | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | `AADSTS50011` redirect mismatch | Redirect URI is not exactly `http://127.0.0.1/callback`, or was registered under *Web* instead of *Mobile and desktop applications* | Re-check step 2.1 | | `AADSTS50194` multi-tenant required | Tenant ID is missing from the configuration | Add Tenant ID in step 4 | | `AADSTS65001` admin consent required | Step 1 was not completed, or step 2.4 was skipped | Complete admin consent | | `Client application is not authorized for this resource` | Anthropic allowlist not yet updated | Wait for confirmation from step 3 | | `AADSTS9000411` duplicate prompt parameter | Older Claude Desktop build | Upgrade to the current release | # User identity and local data Source: https://claude.com/docs/cowork/3p/data-storage How Cowork on 3P identifies users and where it stores conversations, settings, and credentials on disk Cowork on third-party (3P) has no Anthropic account. There is no sign-in step, no cloud-stored conversation history, and no per-user state on Anthropic infrastructure. Identity and persistence are entirely local to the device. ## Identity When the app first launches in 3P mode, it generates a random UUID and writes it (base64-encoded) to the `ant-did` file in the application-data directory. This identifier, together with the `deploymentOrganizationUuid` from your managed configuration, is what's attached to telemetry events. It is random per device and per OS-user account, and Anthropic cannot trace it back to a real device or person. If you need to attribute Cowork activity to named users, configure [OpenTelemetry export](/docs/cowork/3p/configuration#opentelemetry-export) and join the exported events to your identity system on the collector side, or include user identity in the headers your `managedMcpServers` helpers emit. ## Where data lives Cowork on 3P stores everything under a dedicated directory, separate from standard Claude Desktop, so the two modes can coexist on one machine without interfering. | Platform | Application data | Logs | | -------- | ------------------------------------------ | -------------------------------------- | | macOS | `~/Library/Application Support/Claude-3p/` | `~/Library/Logs/Claude-3p/` | | Windows | `%LOCALAPPDATA%\Claude-3p\` | (under the application-data directory) | On Windows, earlier Claude Desktop releases stored this data under `%APPDATA%\Claude-3p\` (the Roaming profile). On first launch after upgrading, the app moves the existing directory to `%LOCALAPPDATA%` automatically; if Roaming is redirected to a network share, conversation history and configuration are copied and large regenerable caches are re-downloaded. Update any external tooling, backup jobs, or endpoint policies that reference the old path. macOS paths are unchanged. Within the application-data directory: | Path | Contents | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ant-did` | The random device identifier described above. | | `configLibrary/` | Locally authored configuration (from the in-app configuration window). `_meta.json` records which saved configuration is applied; each is a `.json` file alongside it. Ignored when a managed profile is present. | | `cowork_account_settings.json` | User-level preferences set in the app (display name, locale, memory toggle). | | `local-agent-mode-sessions/` | Cowork conversation history. One `local_.json` file plus a working directory per session, scoped by account and organization ID. | | `local-agent-mode-sessions/.../memory/` | Cowork memory: a `CLAUDE.md` instructions file plus a `memory/` subdirectory of Markdown notes Claude writes about the user's preferences, projects, and feedback. See [Memory](#memory). | | `local-agent-mode-sessions/...//audit.jsonl` | Append-only log of session events (tool invocations, permission decisions, file operations). Each entry is HMAC-chained to the previous one so edits or deletions are detectable; the companion `.audit-key` file holds the per-session signing key, encrypted via the OS keychain. | | `claude-code-sessions/` | Code tab conversation history, in the same per-session layout. | | `claude-code/`, `claude-code-vm/` | Claude Code binary and VM workspace data for the Code tab. | | `vm_bundles/` | Cached copy of the Cowork sandbox VM bundle. | | `cowork_plugins/` | User-installed and [org-provisioned](/docs/cowork/3p/extensions#organization-plugins-admin) plugins. Created on first plugin install. | | `IndexedDB/`, `Local Storage/`, `Session Storage/` | Renderer-side UI state (window layout, recent folders, preferences). | Files in this directory are written with owner-only permissions so other OS accounts on the same machine cannot read them. The logs directory contains `main.log` (application and configuration-validation events), `cowork_vm_node.log` (sandbox VM activity), and `claude.ai-web.log` (renderer events). ## Memory During Cowork sessions, Claude writes short Markdown files recording what it has learned about the user — working preferences, project context, and corrections — and reads them at the start of subsequent sessions. These files live under `local-agent-mode-sessions/.../memory/memory/` and never leave the device. Users can review and delete individual entries, or pause memory entirely (existing files are kept but not read or updated), under **Settings → Cowork → Memory**. The same page exposes a **Global instructions** editor for the `CLAUDE.md` file that is included in every session. ## Credentials Inference credentials are handled according to how they're delivered: * **Managed configuration** (e.g. `inferenceGatewayApiKey`, `inferenceBedrockBearerToken`) — read from the OS preference store / registry at launch and held in memory; never written to the application-data directory. * **OAuth tokens** (Vertex OAuth, MCP servers with `oauth: true`) — stored in the OS keychain (macOS Keychain / Windows Credential Manager), encrypted at rest by the operating system. * **Credential-helper output** — held in memory for `inferenceCredentialHelperTtlSec` seconds, then discarded and re-fetched. ## Removing data To fully reset a device's Cowork on 3P state, delete the application-data directory above. To return to standard Claude Desktop without removing data, choose the Anthropic sign-in option on the sign-in screen; to also remove the locally authored 3P configuration, delete the `configLibrary/` directory. Conversation history exists only in this directory, so deleting it is unrecoverable. # MCP, plugins, skills, and hooks Source: https://claude.com/docs/cowork/3p/extensions Extend Cowork on 3P with connectors, organization plugins, skills, and hooks for administrators and end users Cowork on third-party (3P) supports the same extensibility model as standard Cowork ([MCP connectors](/docs/connectors/overview), [skills](/docs/skills/overview), and [plugins](/docs/plugins/overview)), with the key difference that administrators provision them through the filesystem and managed configuration rather than the claude.ai admin console. There are three layers, in order of precedence: | Layer | Provisioned by | Delivered via | | -------------------- | -------------- | -------------------------------------- | | Managed MCP servers | Admin | `managedMcpServers` configuration key | | Organization plugins | Admin | A system-wide directory on each device | | User extensions | End user | In-app Connectors and Plugins UI | Admins can disable the user layer entirely; see [Controlling user extensions](#controlling-user-extensions). ## Managed MCP servers (admin) Use the `managedMcpServers` configuration key to deploy remote MCP servers to every device. These appear in the user's connector list automatically, can't be removed by the user, and support per-tool policy locks (`allow` / `ask` / `blocked`). ```json theme={null} [ { "name": "internal-search", "url": "https://mcp.example.corp", "oauth": true, "toolPolicy": { "search": "allow", "delete_document": "blocked" } }, { "name": "ticketing", "url": "https://tickets.example.corp/mcp", "headersHelper": "/usr/local/bin/corp-sso-token", "headersHelperTtlSec": 900 } ] ``` See the [`managedMcpServers` schema](/docs/cowork/3p/configuration#managedmcpservers) in the configuration reference for every field, including static headers, OAuth, and the headers-helper executable for short-lived tokens. In the in-app configuration window, each server you add under **Connectors & extensions** has a **Test this connection** button that runs a live MCP `initialize` and `tools/list` against the server using the headers or OAuth settings you've entered, then shows the round-trip latency, the discovered tool list, or the error returned. Use it to validate reachability and credentials before exporting the configuration. ### Supported MCP servers Any MCP server reachable from the user's device over HTTPS works with Cowork on 3P, including public servers from third parties and internal servers you build and host (including on internal gateways). The [Claude connector directory](https://claude.com/connectors) is the canonical catalog of vetted servers. **Every connector in the directory that is not labeled "Made by Anthropic" is accessible in Cowork on 3P** and can be deployed via `managedMcpServers` or installed by users. Connectors labeled "Made by Anthropic" are hosted on Anthropic infrastructure and are available only in standard Cowork. ### Recommended MCP servers The grids below highlight commonly used servers from the directory. Most require an account or license with the vendor; the MCP server itself accesses data through your existing entitlement. #### Productivity suites Google Workspace is not currently supported in Cowork on 3P, but will be available soon. We will update our docs when it becomes available. Outlook, OneDrive, SharePoint, and Teams. Requires registering an app in your Entra tenant and an Anthropic allowlist step — see the [setup guide](/docs/cowork/3p/connectors-m365). #### Collaboration and knowledge work Vendor-hosted remote MCP servers. Add them to `managedMcpServers` with `"oauth": true`; users authenticate with their existing vendor account. Jira, Confluence, and Compass via the Atlassian Rovo MCP Server. Pages, databases, and search. Issues, projects, and cycles. Tasks, projects, and goals. Files and document management. Repositories, issues, and pull requests. CRM records and Apex. Notebooks and analytics projects. Payments, customers, and invoices. #### Financial services Vendor-published MCP servers from the [Claude connector directory](https://claude.com/connectors). Each requires an account or data license with the respective vendor. Institutional financial data and analytics. Multi-asset-class data and analytics. Risk insights and decision intelligence. Investment and market insights. Index and ESG data. Private-market and deal data. Private-company intelligence. Fundamental data and KPIs with source links. Earnings calls, filings, and company publications. Real-time financial news. Spend management and finance automation. SEC EDGAR filings, statements, and insider trading. Open source; no license required. For licensed data sources without a public MCP server (S\&P Capital IQ, internal research databases), build an internal MCP server against your existing API entitlements and deploy it via `managedMcpServers`. For the full catalog of vetted servers across all categories, browse the [Claude connector directory](https://claude.com/connectors). ## Organization plugins (admin) [Plugins](/docs/plugins/overview) bundle MCP connectors, skills, slash commands, hooks, and sub-agents into a single directory. In Cowork on 3P, admins distribute plugins by placing them in a system-wide directory on each device, typically via the same MDM or software-distribution channel used for the app itself. ### Plugin directory location | Platform | Path | | -------- | -------------------------------------------------- | | macOS | `/Library/Application Support/Claude/org-plugins/` | | Windows | `C:\Program Files\Claude\org-plugins\` | On Windows, the directory is under `Program Files` (not `ProgramData`) so that only administrators can create or modify it. Cowork treats the presence of this directory as an admin-provisioned source. ### Plugin structure Each subdirectory of `org-plugins/` is one plugin. The directory name is the plugin's canonical name. ```text theme={null} org-plugins/ └── code-reviewer/ ├── .claude-plugin/ │ └── plugin.json ├── version.json ├── .mcp.json ├── agents/ │ └── code-reviewer.md ├── commands/ │ └── find-all-bugs.md └── skills/ └── security-review/ └── SKILL.md ``` | File | Purpose | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `.claude-plugin/plugin.json` | **Required.** Plugin manifest (name, description, version). Directories without this file are ignored. | | `version.json` | `{"version": "1.2.3"}`. When this string changes, Cowork re-syncs the plugin on next launch. Any string change triggers re-sync (there's no semver ordering, so a downgrade is just another version string). If absent, the directory's modification time is used instead. | | `.mcp.json` | MCP servers bundled with this plugin, in the same object format as [`managedMcpServers`](/docs/cowork/3p/configuration#managedmcpservers). | | `agents/` | Sub-agent definitions. | | `commands/` | Slash-command definitions. | | `skills/` | [Skill](/docs/skills/overview) directories. | | `hooks/` | Hook definitions that run on agent lifecycle events. | See the [plugins reference](https://code.claude.com/docs/en/plugins) for the full file format of each component, including the hooks schema. Symlinks inside a plugin are followed as long as the target resolves to a path inside the plugin directory. Symlinks that point outside the plugin (for example, `skills/foo/SKILL.md → /etc/hosts`) are skipped. A symlinked top-level plugin directory (for example, `org-plugins/my-plugin → /opt/shared/my-plugin`) is also followed. MCP servers declared in a plugin's `.mcp.json` do **not** inherit the per-tool policy locks (`toolPolicy`) that `managedMcpServers` supports. If you need to lock specific tools to `allow` or `blocked`, deploy that server via `managedMcpServers` instead of bundling it in a plugin. ### Auto-installing organization plugins By default, organization plugins appear in the user's plugin browser as available to install, and each user opts in. To install a plugin automatically for every user, set `installationPreference` in the plugin's `.claude-plugin/plugin.json`: ```json theme={null} { "name": "code-reviewer", "version": "1.0.0", "description": "Internal code review assistant", "installationPreference": "required" } ``` | Value | Behavior | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `"required"` | Installs automatically when the user signs in. The Uninstall action is hidden. If the plugin is removed from disk, it reinstalls on the next sign-in. | | `"auto_install"` | Installs automatically when the user signs in. Users can uninstall it, and it stays uninstalled for that user. | | `"available"` (or omitted) | Default. Users install manually from the plugin browser. | This mirrors the installation preference behavior of remote-managed plugins on Claude.ai. Changing a plugin's `installationPreference` takes effect the next time each user signs in. ### Updating organization plugins To roll out a new version of a plugin: 1. Update the plugin contents in `org-plugins//` via your software-distribution tool 2. Bump the `version` string in `version.json` 3. Users pick up the change on their next app launch ## User extensions Unless restricted by an admin, end users can add their own extensions through the in-app UI: * **Plugins** — install plugins (which can bundle skills, hooks, slash commands, and sub-agents) from the Plugins settings page * **Connectors** — install local desktop extensions (`.mcpb`) from the Connectors settings page * **Local MCP servers** — add local MCP server processes from **Settings → Developer**, when enabled by the admin End users cannot add remote MCP servers; remote servers are available only via admin-provisioned `managedMcpServers` or organization plugins. User-added extensions are stored in the user's [local data directory](/docs/cowork/3p/data-storage) and apply only to that device. ## Controlling user extensions Admins can restrict or disable each user-extension surface independently via managed configuration: | Key | Effect when `false` | | ------------------------------------- | --------------------------------------------------------------------------- | | `isLocalDevMcpEnabled` | Users cannot add their own local MCP servers from **Settings → Developer**. | | `isDesktopExtensionEnabled` | Users cannot install local `.mcpb` desktop extensions. | | `isDesktopExtensionDirectoryEnabled` | The Anthropic extension directory is hidden from the Connectors UI. | | `isDesktopExtensionSignatureRequired` | (When `true`) Unsigned `.mcpb` extensions are rejected. | Setting the first three to `false` restricts MCP servers and connectors to those delivered through `managedMcpServers` and `org-plugins/`. Users can still add their own skills and plugins regardless of these settings. See the [Locked down profile](/docs/cowork/3p/configuration#recommended-security-profiles) for a complete example. # Features on 3P Source: https://claude.com/docs/cowork/3p/feature-matrix Feature comparison between Claude Enterprise and Cowork on third-party (3P) The tables below compare the feature set of Cowork on third-party (3P) to Claude Enterprise. ## Key differences **Configuration.** Claude Enterprise uses a web-based admin console. Cowork on 3P is configured entirely via MDM (Jamf, Intune, Group Policy), with no Anthropic-hosted admin interface. **Telemetry.** Cowork on 3P sends usage and debugging metrics only, and these can be fully disabled via managed configuration. Claude Enterprise does not offer telemetry toggles. See [Telemetry and egress](/docs/cowork/3p/telemetry). **Inference.** Cowork on 3P routes all inference through the provider you configure. When using Vertex AI or Bedrock, Anthropic never sees prompts or completions; during the Microsoft Foundry preview, Claude models run on Anthropic's infrastructure — see the [Overview](/docs/cowork/3p/overview) for details. **Pricing.** Cowork on 3P is token-based consumption billed by your cloud provider, with no seat licensing. **Features not available in 3P.** Features marked with — are absent from the UI. Users see a clean interface without error states for unavailable features. ## User features | Feature | Claude Enterprise | Cowork on 3P | | ------------------------------- | :---------------: | :----------: | | Cowork tab | ✓ | ✓ | | Code tab | ✓ | ✓ | | Chat tab | ✓ | — | | Projects | ✓ | ✓ | | Code execution for analysis | ✓ | ✓ | | File access, upload, and export | ✓ | ✓ | | Local MCP | ✓ | ✓ | | Remote MCP | ✓ | ✓ | | Anthropic 1P Connectors | ✓ | — \* | | Skills, plugins, and hooks | ✓ | ✓ | | Artifacts | ✓ | ✓ | | Memory | ✓ | ✓ † | | Scheduled tasks | ✓ | ✓ | | Global languages | ✓ | ✓ | | Project and plugin sharing | ✓ | — | | Plugin Marketplaces | ✓ | ✓ \*\* | | Dispatch / mobile | ✓ | — | | Voice mode | ✓ | — | | Claude in Chrome | ✓ | — | | Computer use | — | — | \* The Anthropic Microsoft 365 connector is available in Cowork on 3P; see the [setup guide](/docs/cowork/3p/connectors-m365). Google Workspace is not currently supported but will be available soon. \*\* Plugins distributed via the [org-plugins directory](/docs/cowork/3p/extensions#organization-plugins-admin) appear to users as an organization marketplace. The public Anthropic plugin marketplace is not available. † Memory in Cowork on 3P is stored on the device, not on Anthropic infrastructure. Users can review, delete, or pause it under **Settings → Cowork → Memory**; see [Memory](/docs/cowork/3p/data-storage#memory). Chat-history search and nightly summary generation are Chat-tab features and are not applicable in 3P. ## Admin features | Feature | Claude Enterprise | Cowork on 3P | | --------------------------------------------- | :----------------: | :--------------: | | Endpoint / gateway configuration | — | ✓ | | Skills, hooks, and plugins distribution | ✓ | ✓ | | MCP server allowlist | ✓ | ✓ | | Feature toggles (web search, local MCP, etc.) | ✓ | ✓ | | Auto-updates | ✓ | ✓ (configurable) | | Per-user spend caps | ✓ (differentiated) | ✓ (blanket only) | | Compliance API | ✓ | — ‡ | | Analytics API | ✓ | — ‡ | | OpenTelemetry export | ✓ | ✓ | | User management via UI | ✓ | — | | RBAC | ✓ | via MDM | ‡ Many of these capabilities can be achieved via OpenTelemetry export to your own collector. See [Monitoring](/docs/cowork/monitoring). # Using Cowork on 3P with Microsoft Foundry Source: https://claude.com/docs/cowork/3p/foundry Configure Cowork on 3P to use Claude models on Microsoft Foundry To use Microsoft Foundry (Azure AI Foundry) as the inference provider, set `inferenceProvider` to `foundry` and supply the resource name and API key described below. In this preview platform integration, Claude models on Microsoft Foundry run on Anthropic's infrastructure. This is a commercial integration for billing and access through Azure. The data-residency and "no conversation data sent to Anthropic" statements elsewhere in these pages do not apply when using Microsoft Foundry. See the [Overview](/docs/cowork/3p/overview) for details. ## Configuration keys | Setting | Required | Description | | --------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Microsoft Foundry resource name
`inferenceFoundryResource` | Yes | Azure AI Foundry resource name used to construct the endpoint URL (`.services.ai.azure.com`). Two to sixty-four characters, lowercase alphanumeric and hyphens. | | Microsoft Foundry API key
`inferenceFoundryApiKey` | Yes | API key for the Foundry resource. May be supplied dynamically by an [`inferenceCredentialHelper`](/docs/cowork/3p/configuration#credential-helper) executable instead. | You must also set `inferenceModels` to a list of Foundry deployment names. See the [Configuration reference](/docs/cowork/3p/configuration#models). ## Configure in the app Open the in-app configuration window (**Developer → Configure third-party inference**). In the **Connection** section, set **Inference provider** to **Foundry**, then fill in the **Foundry credentials** card: | Field | Value | | ------------------------------- | ----------------------- | | Microsoft Foundry resource name | `your-foundry-resource` | | Microsoft Foundry API key | your API key | Under **Identity & models**, add at least one **Model list** entry using the Foundry deployment name. Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow. # Using Cowork on 3P with an LLM Gateway Source: https://claude.com/docs/cowork/3p/gateway Configure Cowork on 3P to use Claude models on a self-hosted gateway that implements the Anthropic Messages API To use a self-hosted LLM gateway (for example LiteLLM, Portkey, or an in-house proxy) as the inference provider, set `inferenceProvider` to `gateway` and supply the base URL and credentials described below. The gateway must implement the Anthropic [Messages API](https://docs.claude.com/en/api/messages): * `POST /v1/messages` with [streaming](https://docs.claude.com/en/api/streaming) and [tool use](https://docs.claude.com/en/docs/tool-use) is required. * `GET /v1/models` is optional. If the gateway implements it, Cowork on 3P auto-discovers available models; if not, set `inferenceModels` explicitly. The data-residency and "no conversation data sent to Anthropic" statements elsewhere in these pages apply to Vertex AI and Bedrock only. When you use a gateway, data handling is determined by the gateway you operate and the upstream provider it routes to. ## Configuration keys | Setting | Required | Description | | ----------------------------------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Gateway base URL
`inferenceGatewayBaseUrl` | Yes | Gateway base URL. Must be `https://`. | | Gateway API key
`inferenceGatewayApiKey` | Unless using `sso` or a credential helper | API key sent to the gateway. The field cannot be empty, so if your gateway authenticates by network identity and does not require a key, set a placeholder value. | | Gateway auth scheme
`inferenceGatewayAuthScheme` | No | How the credential is sent. `bearer` (default) sends `Authorization: Bearer `. `x-api-key` sends the `x-api-key` header instead. `sso` has each user sign in through your organization's identity provider and sends the resulting token as `Authorization: Bearer`; `inferenceGatewayApiKey` is not required. See [Gateway single sign-on](/docs/cowork/3p/gateway-sso). | | Gateway extra headers
`inferenceGatewayHeaders` | No | Additional HTTP headers sent on every inference request, as a JSON object mapping header name to value (e.g. `{"X-Org-Id":"team1"}`). A JSON array of `"Name: Value"` strings is also accepted for compatibility. | As an alternative to a static `inferenceGatewayApiKey`, configure an [`inferenceCredentialHelper`](/docs/cowork/3p/configuration#credential-helper) executable that prints the gateway credential to stdout, or set `inferenceGatewayAuthScheme` to `sso` for per-user [single sign-on](/docs/cowork/3p/gateway-sso) through your identity provider. ## Models When `inferenceModels` is unset, Cowork on 3P populates the model picker from your gateway's `GET /v1/models` response. Set [`inferenceModels`](/docs/cowork/3p/configuration#models) to override discovery with an explicit list — the picker will show exactly the entries you provide. Use the model IDs your gateway expects (for example `bedrock/us.anthropic.claude-opus-4-7` for a LiteLLM-style routing prefix). ## Configure in the app Open the in-app configuration window (**Developer → Configure third-party inference**). In the **Connection** section, set **Inference provider** to **Gateway**, then fill in the **Gateway credentials** card: | Field | Value | | --------------------- | ------------------------------------------------------------------------------------ | | Gateway base URL | `https://llm-gateway.example.corp` | | Gateway API key | your gateway key (or a placeholder if your gateway has none) | | Gateway auth scheme | *leave empty for the default*, or `sso` for [single sign-on](/docs/cowork/3p/gateway-sso) | | Gateway extra headers | *optional* | Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow. # Gateway single sign-on with your identity provider Source: https://claude.com/docs/cowork/3p/gateway-sso Let each user sign in to your LLM gateway with their own work account instead of a shared API key Instead of distributing a shared gateway API key, you can have each user sign in with their own work account. The first time a user opens Cowork, the app opens their browser to your organization's normal sign-in page (Microsoft Entra ID, Okta, or any OpenID Connect provider). After they sign in, the app sends a per-user token to your gateway on every request, and your gateway checks that token to confirm who the user is. This gives you per-user attribution in your gateway logs, lets your identity provider enforce MFA and conditional access, and means there is no long-lived credential to distribute or rotate. Requires Claude Desktop **1.5.0** or later. ## Before you start You need three things in place: * An LLM gateway that can validate JSON Web Tokens (LiteLLM, Kong, Envoy, and Azure API Management all support this) * Admin access to your identity provider to register a new application * A way to push managed configuration to user devices (your existing MDM) The walkthrough below uses Microsoft Entra ID. An Okta variant follows at the end. ## Set up single sign-on In the [Microsoft Entra admin center](https://entra.microsoft.com), go to **Identity → Applications → App registrations** and select **New registration**. Give it a name such as `Claude Cowork gateway`, choose **Accounts in this organizational directory only**, and select **Register**. On the overview page, copy the **Application (client) ID** and **Directory (tenant) ID**. You will use both in the next two steps. Open the **Authentication** blade, select **Add a platform**, and choose **Mobile and desktop applications**. Under **Custom redirect URIs**, add exactly: ```text theme={null} http://127.0.0.1/callback ``` A few details that matter here: use `127.0.0.1` (not `localhost`), include the `/callback` path, and add it under the **Mobile and desktop applications** platform specifically. That platform is the only one Entra allows to use any local port, which the app needs because it picks a free port at sign-in time. You do not need a client secret or any additional API permissions. Tell your gateway to accept the bearer token only if it was issued by your tenant **for this application**. In LiteLLM that looks like: ```yaml theme={null} general_settings: litellm_jwtauth: public_key_url: https://login.microsoftonline.com/YOUR_TENANT_ID/discovery/v2.0/keys audience: YOUR_CLIENT_ID user_id_jwt_field: oid ``` Replace `YOUR_TENANT_ID` and `YOUR_CLIENT_ID` with the values from step 1. The `audience` line is required. Without it, your gateway accepts tokens issued to any application in your tenant, not just this one. For Kong, Envoy, or Azure API Management, configure the equivalent JWT validation policy with the same JWKS URL and audience. Add these keys to your managed configuration profile and push it through your MDM: ```xml theme={null} inferenceProvider gateway inferenceGatewayBaseUrl https://llm-gateway.example.corp inferenceGatewayAuthScheme sso inferenceGatewayOidc issuer https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0 clientId YOUR_CLIENT_ID ``` When a user next opens Cowork, they see a **Sign in to your organization** button. Clicking it opens their browser to your Entra sign-in page; once they approve, they return to the app and can start working. The app keeps them signed in and refreshes the token in the background, so they will not see the browser again unless their session is revoked or expires under your tenant's policy. ## Using Okta instead In the Okta Admin Console, create a **Native** application with the **Authorization Code** and **Refresh Token** grant types. Okta requires the redirect URI to match exactly, including the port, so pick a fixed port (for example `53180`), register `http://127.0.0.1:53180/callback`, and add that same port to your configuration: ```xml theme={null} inferenceGatewayOidc issuer https://YOUR_ORG.okta.com clientId YOUR_CLIENT_ID redirectPort 53180 ``` Point your gateway's JWT validation at `https://YOUR_ORG.okta.com/oauth2/v1/keys` with `audience` set to the Okta client ID. Google Workspace can be used as the identity provider, but Google does not issue a fresh ID token on background refresh, so users are prompted to sign in again roughly once an hour. Entra ID and Okta are not affected. # Installation and setup Source: https://claude.com/docs/cowork/3p/installation Roll out Cowork on 3P to your organization, from a single evaluation machine to a fleet-wide MDM deployment Cowork on third-party (3P) is the standard Claude Desktop application plus a managed configuration that activates third-party inference mode. You distribute the regular Claude Desktop installer and apply the configuration through your existing device-management tooling. ## Recommended rollout For most organizations, we recommend a three-stage rollout: An admin installs Claude Desktop on their own device and uses the in-app configuration window to build and test a working configuration against your inference provider. Open the hostnames your configuration requires on your perimeter firewall. The configuration window lists them for the exact settings you've chosen. From the configuration window, export the validated configuration as a `.mobileconfig` (macOS) or `.reg` (Windows) file and distribute it through Jamf, Intune, Group Policy, or your MDM of choice. Push the Claude Desktop installer to enrolled devices. When the app launches and finds a managed configuration, it enters 3P mode automatically with no user sign-in or setup required. Deploying the configuration before the app means end users open Claude for the first time and land directly in Cowork, with no opportunity to sign in to claude.ai by mistake. ## Admin installation ### 1. Install Claude Desktop Download the installer for your platform from [claude.com/download](https://claude.com/download). | Platform | Installer | Notes | | -------- | --------- | ----------------------------------------------------------- | | macOS | `.dmg` | Drag **Claude.app** to Applications | | Windows | `.msix` | Supports per-machine provisioning for enterprise deployment | ### 2. Build a configuration in the app Launch Claude Desktop. **Do not sign in or create an Anthropic account** — stay on the login screen. From the macOS menu bar at the top of the screen: 1. Go to **Help → Troubleshooting → Enable Developer Mode** to reveal the Developer menu. 2. Then go to **Developer → Configure third-party inference** to open the configuration window. Open the application menu (☰) in the top-left of the Claude login screen: 1. Go to **Help → Troubleshooting → Enable Developer Mode** to reveal the Developer menu. 2. Then go to **Developer → Configure third-party inference** to open the configuration window. The window is organized into seven sections in the left sidebar. Work through them in order; each maps to a group of [configuration keys](/docs/cowork/3p/configuration), and the window validates values as you enter them.
SectionWhat you set
Connection
  • Inference provider (Gateway, Vertex, Bedrock, or Foundry) and its credentials
  • Model list
  • Organization UUID
  • Optional credential-helper script
Sandbox & workspace
  • Whether the Code tab is shown
  • Allowed egress hosts for the sandbox
  • Disabled built-in tools
  • Allowed workspace folders
Connectors & extensions
  • Managed MCP servers pushed to all users
  • Whether users can add their own local MCP servers
  • Whether desktop extensions (.mcpb) are allowed
  • Whether the extension directory is shown
  • Whether unsigned extensions are rejected
Telemetry & updates
  • OpenTelemetry collector endpoint
  • Whether auto-updates are blocked, and the enforcement window if not
  • The three Anthropic-bound telemetry toggles (essential, nonessential, nonessential services)
Usage limits
  • Per-device token cap and its window length
Plugins & skills
  • Shows the org-plugins folder path for your platform
  • Plugins are distributed by mounting bundles to that folder via your MDM, not through this window
Egress Requirements
  • A read-only firewall allowlist derived from everything you've entered above, grouped by feature
  • Copy hostnames, Download .txt, and Test connectivity actions
The configuration picker in the top-right shows which saved configuration you're editing and whether it's the one currently applied. On a managed device it indicates the configuration is organization-managed, and every section shows a banner directing users to their IT administrator. The configuration window is the recommended way to author configurations. It validates field formats, knows which keys each provider requires, and stays current as new keys are added. When a managed (MDM-delivered) configuration is already present on the device, the configuration window opens read-only. It shows what the admin deployed but won't let the user change or override it. To author a new configuration, use a device without a managed profile, or temporarily remove the profile. ### 3. Export for MDM Once your configuration tests successfully, click **Export** and choose a format: | Format | Platform | Deploy with | | --------------- | -------- | --------------------------------------------------------------------------------------------------------------- | | `.mobileconfig` | macOS | Jamf, Kandji, Mosyle, Workspace ONE, or any Apple MDM | | `.reg` | Windows | Group Policy (import into a GPO), Intune (via custom ADMX or script), or any MDM that can write registry policy | The two actions in the configuration window do different things: * **Apply locally** writes the selected configuration to your own machine's Claude settings and relaunches the app, so you can test it end to end before deploying it. * **Export** writes a `.mobileconfig` or `.reg` file and leaves your local settings untouched. #### Creating profiles for multiple user groups Many organizations deploy distinct configurations to different populations: for example, a permissive profile for an engineering pilot group and a restricted profile for the broader rollout, or per-region profiles that point at different inference endpoints. The configuration window can hold multiple named configurations. Use the picker in the top-right of the window: * **New configuration** creates an empty configuration. * **Duplicate** copies the current configuration as a starting point for a variant. * **Rename** and **Delete** manage the list. * **Reveal in Finder** opens the on-disk location where saved configurations are stored. Selecting a configuration in the picker loads it for editing; the **applied** badge marks the one currently active on your machine. **Apply locally** and **Export** each act on whichever configuration is selected, so you can test each one locally and export them independently. In your MDM, scope each exported profile to the corresponding device or user group. Targeting is handled by your MDM's assignment rules; the configuration name is for your authoring workflow and is not part of the deployed profile. ### 4. Allow required network egress The hosts the app needs to reach depend on the configuration you built: your inference provider's endpoint is always required, and each telemetry, update, and service setting you leave enabled adds its own hosts. The configuration window shows the exact allowlist for your settings and can export it as a text file for your network team. Open these hosts on your perimeter firewall before rolling out to devices. See [Telemetry and egress](/docs/cowork/3p/telemetry#required-egress-paths) for the full list of hosts grouped by the setting that controls each one, and for the distinction between the perimeter firewall and the in-app sandbox allowlist. ### 5. Deploy the configuration Push the exported configuration through your MDM. The app reads from these locations: | Source | Path | Precedence | | ------------------ | -------------------------------------------------------------------------- | ---------- | | Managed (per-user) | `/Library/Managed Preferences//com.anthropic.claudefordesktop.plist` | Highest | | Managed (machine) | `/Library/Managed Preferences/com.anthropic.claudefordesktop.plist` | | | Local (user) | `~/Library/Application Support/Claude-3p/configLibrary/` | Lowest | A `.mobileconfig` profile delivered by MDM lands in the Managed Preferences locations automatically. Both managed paths are read; where a key appears in both, the per-user value wins. | Source | Path | Precedence | | -------------- | ----------------------------------------- | ---------- | | Machine policy | `HKLM\SOFTWARE\Policies\Claude` | Highest | | User policy | `HKCU\SOFTWARE\Policies\Claude` | | | Local (user) | `%LOCALAPPDATA%\Claude-3p\configLibrary\` | Lowest | A Group Policy Object or Intune configuration profile writes to the registry policy paths. Both hives are read; where a key appears in both, the machine (`HKLM`) value wins. When **any** managed source is present, it takes effect and the in-app configuration window becomes read-only. Locally authored values in `configLibrary/` are ignored. ### 6. Distribute the app Deploy the Claude Desktop installer to enrolled devices using your standard software-distribution mechanism. On launch, the app reads the managed configuration, detects the configured inference provider and credentials, and the sign-in screen offers users the option to start in Cowork on 3P. ### 7. Configure the Code tab (if enabled) Anthropic is working on achieving settings parity between the Cowork and Code tabs. Today, some Cowork on 3P configuration keys do not yet propagate identically to Code-tab sessions. To configure the Code tab directly, deploy a Claude Code `managed-settings.json` alongside your profile, or disable the Code tab with `isClaudeCodeForDesktopEnabled: false`. See [Code tab](/docs/cowork/3p/code). ### 8. Deploy organization plugins (optional) If you're distributing [organization plugins](/docs/cowork/3p/extensions#organization-plugins-admin), push the plugin bundles to the org-plugins directory on each device alongside the configuration profile. Plugins are picked up at the next app launch. ## End-user installation For pilots, evaluations, or organizations that don't use MDM, individual users can configure 3P mode themselves. 1. Install Claude Desktop from [claude.com/download](https://claude.com/download). 2. Launch the app. **Do not sign in or create an Anthropic account.** From the macOS menu bar (or on Windows, the application menu ☰ in the top-left of the login screen), go to **Help → Troubleshooting → Enable Developer Mode**, then **Developer → Configure third-party inference**. 3. Enter the provider, endpoint, and credential values supplied by your administrator. 4. Click **Apply locally**. The app relaunches and the sign-in screen now offers the option to start in Cowork on 3P using the configuration you entered. The configuration is written to the application's local config file and applies only to that device and user account. It can be edited from the same window at any time. To return to standard Claude Desktop, choose the Anthropic sign-in option on the sign-in screen instead. ## Verifying the deployment On any configured device, open Claude Desktop and go to **Help → Troubleshooting → Copy Managed Configuration Report**. This copies a summary showing which keys were detected, where they were read from (managed profile vs. user store), and whether the inference credentials validated successfully. Secret values are redacted. If the app shows the standard claude.ai sign-in screen instead of Cowork, the configuration was not read. Common causes: * `inferenceProvider` is missing, misspelled, or set to an unrecognized value * The configuration was applied while the app was running (fully quit and relaunch) * The configuration was written to the local config file but you're checking the managed location (or vice versa) * A required key for the chosen provider is missing; check **Help → Troubleshooting** or the application log at `~/Library/Logs/Claude/main.log` (macOS) / `%APPDATA%\Claude\logs\main.log` (Windows) ## Troubleshooting If you're experiencing technical issues with installation or setup, generate a diagnostic report and share it with Anthropic. On the affected machine, go to **Help → Troubleshooting → Generate Diagnostic Report** in the menu bar, choose a save location, and send the resulting folder to your Anthropic representative. Please generate the diagnostic before requesting support. The report contains the configuration state, application logs, and environment details needed to investigate, and does not include any user data or conversation content. ## Endpoint security software If your organization runs binary-authorization or EDR software (such as [Santa](https://santa.dev), CrowdStrike Falcon, or Microsoft Defender ASR) with path-based deny rules, the Cowork agent helper may be blocked from launching. The symptom is that Claude Desktop opens normally and reads the managed configuration, but Cowork sessions fail to start. The agent helper is a signed binary that Claude Desktop installs under its user-data directory. **Allowlist by signing identity rather than path** so the rule survives version updates. **macOS** ``` ~/Library/Application Support/Claude-3p/claude-code//claude.app/Contents/MacOS/claude ``` The helper is Developer ID signed and notarized: * Team ID: `Q6L2SF6YDW` (Anthropic PBC) * Signing ID: `com.anthropic.claude-code` For Santa, a `TEAMID` allow rule for `Q6L2SF6YDW` covers the helper across version updates. Standard (non-3P) installs use `~/Library/Application Support/Claude/` with the same subpath. **Windows** ``` %LOCALAPPDATA%\Claude-3p\claude-code\\claude.exe ``` The helper is Authenticode-signed with publisher `Anthropic, PBC`. For Defender ASR or AppLocker, allowlist by publisher rather than path. Standard installs use `%APPDATA%\Claude\` with the same subpath. ## Updates By default, Claude Desktop checks Anthropic's update server and applies updates automatically. In 3P deployments you can: * **Leave auto-update enabled** (recommended) so fixes reach users without IT intervention. Use `autoUpdaterEnforcementHours` to bound how long users can defer a pending update. * **Disable auto-update** (`disableAutoUpdates`) and redistribute new builds through your MDM on your own cadence. This is required for air-gapped environments but means your IT team owns the update pipeline. See [Telemetry and egress](/docs/cowork/3p/telemetry) for the network paths the updater uses. # Legal and compliance Source: https://claude.com/docs/cowork/3p/legal Legal agreements, compliance, and security information for Cowork on 3P ## Legal agreements ### License Your use of the Claude Desktop application, including in Cowork on third-party (3P) mode, is subject to Anthropic's [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms). ### Commercial agreements Cowork on 3P routes model inference through the provider you configure (Google Cloud's Vertex AI, Amazon Bedrock, Microsoft Foundry, or a compatible gateway). Inference usage is billed by, and subject to your agreement with, that provider. Your existing commercial agreement with Anthropic continues to apply to your use of the Claude Desktop application, unless we've mutually agreed otherwise. ## Compliance When using Vertex AI or Bedrock, conversation content is sent only to your configured inference endpoint and stored on the local device; the compliance posture of your deployment is determined by your inference provider and the device environment you control. During the Microsoft Foundry preview, Claude models run on Anthropic's infrastructure and customers are subject to Anthropic's data use terms. See the [Overview](/docs/cowork/3p/overview) for the architecture and the provider-specific data path. For Anthropic's certifications and compliance reports, see the [Anthropic Trust Center](https://trust.anthropic.com). For HIPAA, see [HIPAA](/docs/cowork/3p/overview#hipaa) on the Overview page. When using Vertex AI or Bedrock, Anthropic does not interact with PHI; the BAA relationship is between you and your cloud service provider, and any remote MCP servers you connect should be reviewed for HIPAA compliance. ## Usage policy Use of Claude models, including via Cowork on 3P, is subject to the [Anthropic Usage Policy](https://www.anthropic.com/legal/aup). ## Privacy and telemetry The Claude Desktop application sends operational telemetry (crash reports and product analytics) to Anthropic by default. This telemetry contains no prompt or response content and can be fully disabled via managed configuration. See [Telemetry and egress](/docs/cowork/3p/telemetry) for what each category contains and how to disable it. Anthropic's [Privacy Policy](https://www.anthropic.com/legal/privacy) describes how Anthropic handles data it receives. ## Security and trust Security architecture, threat-model, and data-flow documentation for Cowork and Cowork on 3P is available on the [Anthropic Trust Center](https://trust.anthropic.com). ### Security vulnerability reporting Anthropic manages our security program through HackerOne. [Use this form to report vulnerabilities](https://hackerone.com/4f1f16ba-10d3-4d09-9ecc-c721aad90f24/embedded_submissions/new). *** © Anthropic PBC. All rights reserved. Use is subject to applicable Anthropic Terms of Service. # Desktop and filesystem access Source: https://claude.com/docs/cowork/3p/local-access How Cowork on 3P reads and writes files on the user's machine, and how to constrain it Like standard [Cowork](/docs/cowork/overview), Cowork on third-party (3P) works directly with files on the user's computer. Users attach one or more **workspace folders** to a session; the agent can then read, create, and modify files anywhere inside those folders, and run code against them inside the sandbox VM. In Cowork on 3P, administrators can constrain which folders users are allowed to attach. ## Workspace folder allowlist The `allowedWorkspaceFolders` configuration key restricts which paths users may attach as workspace folders. | Value | Behavior | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Unset | Unrestricted. Users can attach any folder they have OS-level access to, matching standard Cowork. | | `["~/Documents/Claude", "/Volumes/Shared/Projects"]` | Users may attach only folders **inside** one of the listed roots. | | `[]` | No folders may be attached. The agent can still create files in its own sandbox scratch space, but cannot read or write the user's filesystem. | A leading `~` expands to the user's home directory, so a single profile can express per-user roots like `~/Documents/Claude` across the fleet. The check is enforced against the **resolved** path, so symlinks and `..` traversal can't be used to escape an allowed root. The allowlist controls what users can **attach**. Within an attached folder, the agent has full read/write access to every file the user's OS account can reach. To isolate sensitive data, keep it outside the allowed roots. ## Network drives on Windows Users can attach a mapped network drive (for example, `Z:\`) as a workspace folder through the folder picker. Raw UNC paths (`\\server\share`) are not supported; map the share to a drive letter first. The agent can read, write, and search files on the network drive with its file tools. Shell commands, however, run in an isolated sandbox that cannot reach network shares. If a task needs to run a script or build against files on the network drive, ask the agent to copy the relevant files to a local folder first. The agent cannot attach a network-drive path on its own; only the user can, through the folder picker. This is a security boundary. On macOS, network mounts under `/Volumes/` are currently treated as local folders. # Overview Source: https://claude.com/docs/cowork/3p/overview Run Cowork against your own cloud inference provider **Research Preview.** Cowork on 3P is under active development. These docs will be updated with new product features. We will share the timeline for GA when it is available. Cowork on third-party (3P) is a deployment mode of Claude Desktop (Cowork and Code tabs) that routes all model inference through a provider you configure: Google Cloud's Vertex AI, Amazon Bedrock, Microsoft Foundry, or any compatible gateway you operate. The app runs from a bundled local web application, and conversation history is stored on the user's device. You get the same agentic Cowork experience (file creation, multi-step research, sub-agent coordination, the Code tab) with inference and billing handled by the provider you choose. The data-residency, compliance, and "no conversation data sent to Anthropic" statements throughout these pages apply when `inferenceProvider` is `vertex` or `bedrock`. They also apply when `inferenceProvider` is `gateway`, provided your gateway does not route inference to Anthropic infrastructure (directly or via Microsoft Foundry). They do not apply when using Microsoft Foundry. **Microsoft Foundry (preview):** In this preview platform integration, Claude models run on Anthropic's infrastructure. This is a commercial integration for billing and access through Azure. As an independent processor for Microsoft, customers using Claude through Microsoft Foundry are subject to Anthropic's data use terms. Anthropic continues to provide its industry-leading safety and data commitments, including zero data retention availability. ## Who it's for Cowork on 3P is designed for organizations whose security, regulatory, or contractual requirements prevent them from sending data to Anthropic's first-party infrastructure. Typical deployments include: * **Highly regulated enterprises on 3P only** — organizations that use third-party inference for regulatory or security reasons * **International enterprises with data residency requirements** — organizations that require in-region data residency and cannot send conversation data to the United States If your organization can use Anthropic's first-party products directly, standard [Cowork](/docs/cowork/overview) on a Team or Enterprise plan is simpler to deploy, offers an in-app UI for user management, analytics, and RBAC, and releases new features more quickly than Cowork on 3P. Choose Cowork on 3P when routing inference through Anthropic's API is not an option. ## Architecture Cowork on 3P keeps the standard Cowork feature set and relocates inference to the provider you configure. | Component | Standard Cowork | Cowork on 3P | | ---------------------- | -------------------------- | ----------------------------------------------------- | | Model inference | Anthropic API | Your Vertex AI / Bedrock / Foundry / gateway endpoint | | Web application | Loaded from claude.ai | Bundled inside the desktop app | | User identity | Anthropic account | Local device identity only | | Conversation storage | Anthropic backend | Local disk on the user's machine | | Code execution sandbox | Local VM | Local VM (identical) | | Configuration | Admin console at claude.ai | OS-native configuration (MDM-managed or per-user) | The desktop app detects 3P mode at launch from the configured inference provider. When a provider and its credentials are present, the sign-in screen offers the option to skip Anthropic authentication and start the app using your inference-provider configuration instead. ### Security posture * **No conversation egress to Anthropic** (Vertex AI and Bedrock only). Prompts, responses, files, and tool outputs are sent only to your configured inference endpoint and stored only on the local machine. * **Sandboxed tool execution.** Shell commands run in the hardened Cowork VM; file access is scoped to your allowed folders and web fetches to your egress allowlist. * **Auditable telemetry.** Crash reports and product analytics are scrubbed of conversation and user data before being sent to Anthropic, and can be fully disabled via configuration keys. Independently, you can export full session activity (prompts, tool calls, token counts) to your own OpenTelemetry collector. * **Centrally managed.** All configuration is delivered via your existing MDM (Jamf, Intune, Workspace ONE, Group Policy) and cannot be overridden by end users when an admin profile is present. For a detailed treatment of the threat model, sandbox boundaries, and data flows, request access to the [Claude Cowork Desktop Security Architecture Overview](https://trust.anthropic.com/resources?s=2a7bbzo1lyymvdt551q7kl\&name=claude-cowork-desktop-security-architecture-overview) on Anthropic's Trust Center. For architecture, telemetry, and controls information specific to Cowork on 3P, see the [Claude Cowork Security Overview (Third-Party Platforms)](https://trust.anthropic.com/resources?s=0c8rx4s7mm5ierz8ppetfs\&name=claude-cowork-security-overview-\(third-party-platforms\)) on the Trust Center. ## Data residency and international deployment This section applies when using Vertex AI or Bedrock. Inference requests go directly from the user's machine to the regional endpoint you configure (`inferenceVertexRegion` or `inferenceBedrockRegion`). Because conversation data goes only to that endpoint and to local disk, residency is determined entirely by: 1. The cloud region you select for inference 2. The physical location of the user's device, where conversations are persisted For multi-region organizations, deploy distinct MDM configuration profiles per geography so each user population points at an in-region endpoint. Vertex AI and Bedrock each offer Claude models in EU, UK, APJ, and other sovereign regions; consult your provider's model-availability documentation for the current list. ## Public sector and highly regulated environments This section applies when using Vertex AI or Bedrock. Because inference runs in your cloud tenant, Cowork on 3P operates inside whatever compliance boundary your provider and region give you. The desktop application itself contacts Anthropic only for crash reporting, product analytics, and auto-updates, and each of these can be disabled independently via managed configuration. With Anthropic-bound telemetry and updates disabled, the compliance posture of your deployment is determined entirely by your inference provider. See [Telemetry and egress](/docs/cowork/3p/telemetry) for the full set of network paths and how to lock them down. ## HIPAA This section applies when using Vertex AI or Bedrock. Cowork on 3P does not process user data, prompts, or completions. As such, Anthropic does not interact with PHI the user may upload to Cowork on 3P; that data is transmitted only to the customer's cloud service provider or any remote MCP servers they optionally choose to configure. For a HIPAA-compliant solution, customers should ensure they have a BAA in place with their CSP and review any MCP servers for HIPAA compliance before connecting them to Cowork on 3P. Disabling telemetry is not required to run Cowork on 3P in a HIPAA-compliant way, since Anthropic's telemetry does not collect user data, prompts, or completions, only redacted crash reporting and aggregated usage metrics that do not reveal sensitive data. ## Next steps Roll out Cowork on 3P to your organization with MDM, or configure a single machine for evaluation. Every managed-configuration key, what it does, and recommended security profiles. Deploy MCP servers, plugins, skills, and hooks across your fleet. What the app sends to Anthropic, how to turn it off, and the firewall allowlist you'll need. # Telemetry and egress Source: https://claude.com/docs/cowork/3p/telemetry What Cowork on 3P sends to Anthropic, how to disable it, and the network paths your firewall needs to allow When Cowork on third-party (3P) is configured with Vertex AI or Bedrock, conversation content never reaches Anthropic. The app does, by default, send a small amount of operational telemetry (crash reports and product analytics) that helps Anthropic diagnose issues and improve the product. Each category can be disabled independently via managed configuration. This page covers what each category contains, how to turn it off, and the complete set of outbound hostnames the app uses so you can configure your perimeter firewall. ## Telemetry categories ### Essential telemetry Crash reports, error stack traces, and performance timings. Contains diagnostic metadata (app version, OS, error type, redacted stack frames) but **never prompt or response content**. Attributed to your organization via `deploymentOrganizationUuid` so Anthropic support can find issues you report. | Setting | Default | Effect when `true` | | --------------------------- | ------- | ----------------------------------------- | | `disableEssentialTelemetry` | `false` | No crash or error data leaves the device. | Disabling essential telemetry opts you into a **manual support model**. Anthropic will have zero remote visibility into failures on your fleet, so to get help with an issue your team will need to collect application logs from affected machines and send them to Anthropic directly. We strongly recommend leaving this enabled during initial rollout. ### Non-essential telemetry Product-usage analytics: feature adoption, session counts, UI interactions. Used to understand how Cowork is used in aggregate. Contains no prompt or response content. | Setting | Default | Effect when `true` | | ------------------------------ | ------- | -------------------------------------- | | `disableNonessentialTelemetry` | `false` | No product analytics leave the device. | ### Non-essential services Cosmetic third-party fetches: favicons for connectors shown in the UI, and the sandboxed iframe that renders interactive artifact previews. Disabling these degrades the UI slightly (generic icons, static artifact previews) but doesn't affect functionality. | Setting | Default | Effect when `true` | | ----------------------------- | ------- | ------------------------------------------------- | | `disableNonessentialServices` | `false` | Favicon and artifact-preview fetches are blocked. | ### Auto-updates Checks Anthropic's update feed and downloads new builds. | Setting | Default | Effect when `true` | | -------------------- | ------- | ----------------------------------------------------------------------------------------- | | `disableAutoUpdates` | `false` | The app never checks for or downloads updates. Your IT team must redistribute new builds. | ## Sending telemetry to your own collector Independently of what's sent to Anthropic, you can export full session activity (prompts, tool calls, token counts, errors) to your own OpenTelemetry collector by setting `otlpEndpoint`. This is the recommended way to retain an audit trail in environments that disable Anthropic-bound telemetry. See [Monitoring](/docs/cowork/monitoring) for the event schema and the [`otlp*` keys](/docs/cowork/3p/configuration#opentelemetry-export) in the configuration reference. ## Required egress paths Cowork on 3P has **two** independent network boundaries: 1. **Perimeter firewall** — your corporate network controls what the device can reach. The hostnames below are what you allowlist here. 2. **Agent egress allowlist** — the [`coworkEgressAllowedHosts`](/docs/cowork/3p/configuration#sandbox-%26-workspace) key controls what the agent's web-fetch and shell tools can reach. This is independent of, and stricter than, the perimeter. The **Egress Requirements** section of the in-app configuration window is the authoritative source for your deployment. It computes the exact allowlist from your current settings, updates as you change them, and can export the list as a text file for your firewall team. Use the tables below as a static reference; defer to the configuration window for the precise set your build requires. All traffic is HTTPS on port 443. Allowlist by hostname (SNI); path-level rules aren't required. ### Always required | Host | Purpose | | --------------------- | -------------------------------------------------------------------------------------------------------------------- | | `downloads.claude.ai` | VM workspace bundle and Claude CLI binary, fetched at session start. **Without this, Cowork sessions cannot start.** | ### Inference provider The host(s) for your configured provider. These carry conversation content. | Host | Purpose | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | `-aiplatform.googleapis.com` | Model inference (or `aiplatform.googleapis.com` for the `global` region). Replaced by the host of `inferenceVertexBaseUrl` if set. | | `oauth2.googleapis.com` | Google auth token exchange | | `sts.googleapis.com` | Google auth token exchange | | `accounts.google.com` | Google auth token exchange | | `iamcredentials.googleapis.com` | Google auth token exchange | | Host | Purpose | | ------------------------------------------------------------------ | -------------------------------------------------------------------------- | | `bedrock-runtime..amazonaws.com` | Model inference. Replaced by the host of `inferenceBedrockBaseUrl` if set. | | `bedrock..amazonaws.com` | Control plane (profile auth only) | | `sts.amazonaws.com`, `sts..amazonaws.com` | STS token exchange (profile auth only) | | `portal.sso..amazonaws.com`, `oidc..amazonaws.com` | AWS SSO (profile auth only) | With `inferenceBedrockBearerToken` set, only the runtime host is required. | Host | Purpose | | ---------------------------------- | --------------- | | `.services.ai.azure.com` | Model inference | During the Foundry preview, Claude models run on Anthropic's infrastructure. The client connects only to the Azure host above, but conversation content leaves the Azure boundary — see the [Overview](/docs/cowork/3p/overview) for details. | Host | Purpose | | --------------------------------- | --------------- | | Host of `inferenceGatewayBaseUrl` | Model inference | ### Auto-updates (`disableAutoUpdates: false`) | Host | Purpose | | --------------------- | ---------------------------------------- | | `api.anthropic.com` | Update feed | | `downloads.claude.ai` | Update binaries (already required above) | ### Essential telemetry (`disableEssentialTelemetry: false`) | Host | Purpose | | ---------------------------------- | ----------------------------------------------------------------------------------------------- | | `*.sentry.io` | Crash and error reporting | | `*.ingest.us.sentry.io` | Crash and error reporting (listed separately for firewalls that match wildcards one label deep) | | `browser-intake-us5-datadoghq.com` | Performance timing | ### Non-essential telemetry (`disableNonessentialTelemetry: false`) | Host | Purpose | | --------------------- | ---------------- | | `a-cdn.anthropic.com` | Analytics SDK | | `a-api.anthropic.com` | Analytics events | | `claude.ai` | Analytics events | ### Non-essential services (`disableNonessentialServices: false`) | Host | Purpose | | ------------------------------------------------------------------ | --------------------------- | | `api.anthropic.com` | Artifact preview | | `www.claudeusercontent.com` | Artifact preview iframe | | `cdnjs.cloudflare.com`, `cdn.jsdelivr.net`, `fonts.googleapis.com` | Artifact preview asset CDNs | | `www.google.com`, `*.gstatic.com` | Connector favicons | ### Optional features | Host | Required when | | ----------------------------------------------------------------------------------- | ------------------------------------------- | | Host of `otlpEndpoint` | OpenTelemetry export is configured | | `github.com`, `objects.githubusercontent.com`, `pypi.org`, `files.pythonhosted.org` | Python-based desktop extensions are enabled | | Hosts of each entry in `managedMcpServers` | Managed MCP servers are configured | | Hosts in `coworkEgressAllowedHosts` | Sandbox web access is configured | ## Disabling all Anthropic-bound connections With `disableEssentialTelemetry`, `disableNonessentialTelemetry`, `disableNonessentialServices`, and `disableAutoUpdates` all set to `true`, the desktop application makes **no outbound connections to Anthropic-operated hosts at runtime**. The only required egress is `downloads.claude.ai` (for the VM bundle at session start) and your inference provider. This describes the application's own connections; the guarantee that conversation content does not reach Anthropic via the inference path applies only when using Vertex AI or Bedrock. See the [Locked down profile](/docs/cowork/3p/configuration#recommended-security-profiles) for a complete configuration. ## Proxy support The Cowork sandbox honors the host operating system's proxy configuration, including PAC (proxy auto-configuration) files. If the device routes HTTPS through a corporate proxy, the sandbox will too, with no additional configuration required. ### TLS-intercepting proxies on macOS If your proxy performs TLS interception, it presents its own certificate authority. Claude configures its CLI processes to trust the macOS System keychain in addition to the bundled CA roots, so a corporate CA installed there normally works without extra setup. If inference or tool requests still fail certificate verification, the CA was likely added with policy-restricted trust: certificates installed via `security add-trusted-cert -p ssl …` are trusted by Safari and Chrome but are not picked up by the CLI runtime's keychain reader. Re-add the CA with full root trust (omit `-p`): ```bash theme={null} sudo security add-trusted-cert -d -r trustRoot \ -k /Library/Keychains/System.keychain /path/to/corp-ca.pem ``` If the certificate is MDM-managed and you cannot change how it is installed, set `NODE_EXTRA_CA_CERTS` as a fallback, then quit and relaunch Claude: ```bash theme={null} security find-certificate -a -p /Library/Keychains/System.keychain > ~/corp-ca.pem launchctl setenv NODE_EXTRA_CA_CERTS "$HOME/corp-ca.pem" ``` `launchctl setenv` makes the variable visible to apps launched from Finder or the Dock (shell-profile exports only reach terminal sessions). It applies until the next reboot — to make it permanent, run the command from a LaunchAgent at login. # Deploy Cowork on 3P with Google Cloud's Vertex AI Source: https://claude.com/docs/cowork/3p/vertex Set up Google Cloud, choose an authentication path for your organization, and configure Cowork on 3P to use Claude models on Vertex AI This page walks an IT administrator through a complete Vertex AI deployment: enabling Claude in your Google Cloud project, choosing the authentication path that fits your organization, preparing devices, and pushing the managed configuration. If you only need the list of configuration keys, skip to [Configure the app](#configure-the-app). ## Choose an authentication approach Vertex AI authenticates with Google Cloud Application Default Credentials, which can be supplied several ways. The right one depends on whether your users have Google identities and whether you need per-user attribution in Cloud Audit Logs. | Scenario | Use | Per-device prerequisite | Per-user Cloud Audit Logs identity | Notes | | ------------------------------------------------------ | --------------------------------------------------------------------------- | --------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------ | | Proof of concept, single team | [Service-account key](#credentials-file) (`inferenceVertexCredentialsFile`) | The key file on each device | No (shared service account) | A long-lived secret distributed to every device. Simplest to start; not recommended for broad rollout. | | Users have Google Workspace or Cloud Identity accounts | [In-app Google sign-in](#in-app-google-sign-in) (`inferenceVertexOAuth*`) | None | Yes | Users sign in with their Google account inside the app. See the session-control warning below. | | You already operate an LLM proxy | [Gateway provider](/docs/cowork/3p/gateway) instead of Vertex | None | At your gateway | The proxy holds the Google Cloud credentials; the app authenticates only to the proxy. | If your Google Workspace or Cloud Identity organization enforces a **Google Cloud session length** of a few hours or less (Admin console → Security → Google Cloud session control), the in-app Google sign-in stores a refresh token that is subject to that policy, and users will be prompted to sign in again each time it expires. For short session policies, either mark your OAuth client as a [trusted app exempt from reauthentication](https://support.google.com/a/answer/9368756), or use a service-account key or the gateway provider instead. `inferenceCredentialHelper` is not invoked when `inferenceProvider` is `vertex`, because Vertex authentication is file-based rather than token-based. Use one of the options above. ## Set up Google Cloud These steps are performed once per Google Cloud project, regardless of which authentication approach you chose. You need a project with Owner or Editor access. In the [Google Cloud console](https://console.cloud.google.com/apis/library/aiplatform.googleapis.com), enable the **Vertex AI API** for your project. In the Vertex AI [Model Garden](https://console.cloud.google.com/vertex-ai/model-garden), locate the Claude models you intend to deploy and click **Enable** on each. Model availability varies by region; enable them in the region you will set as `inferenceVertexRegion`. Each authenticated principal needs permission to call the model. On the project's **IAM** page, grant the **Vertex AI User** role (`roles/aiplatform.user`) to: * the service account, if using a service-account key file * the Google group containing your users, if using in-app Google sign-in If your organization uses a narrower custom role, it must include at minimum `aiplatform.endpoints.predict`. If you chose in-app Google sign-in, create a Desktop-app OAuth client in your project. See [Sign in with Google for Vertex AI](/docs/cowork/3p/vertex-google-sign-in) for the full procedure, including consent-screen setup. If your users authenticate with Microsoft Entra ID, Okta, or another SAML identity provider and do not already have Google accounts, provision a free Cloud Identity tenant and configure SAML single sign-on to your IdP. Users then sign in through the in-app Google sign-in approach with a Google identity that is backed by your IdP. No Google Workspace licenses are required. See [Set up SSO with a third-party IdP](https://support.google.com/cloudidentity/answer/12032922) in the Cloud Identity documentation. ## Prepare devices What each end-user device needs depends on the authentication approach you chose. ### Credentials file Create a service account in your project, grant it the **Vertex AI User** role, and download its JSON key. Distribute the key file to a fixed path on each device through your device-management tooling and set `inferenceVertexCredentialsFile` to that path. `inferenceVertexCredentialsFile` accepts any Application Default Credentials JSON format, so if your environment already produces an `authorized_user` file (from `gcloud auth application-default login`) or an `external_account` Workforce Identity Federation configuration, you can point at that file instead. For `external_account` files, the `credential_source` must be of type `file` or `url` (`executable` sources are not supported), and separate tooling on the device must obtain the IdP token and write it to the configured location; Cowork does not perform that step. ### In-app Google sign-in No per-device preparation is required. Distribute the OAuth client ID and secret in the managed configuration; the app shows a **Sign in with Google** page on first launch and stores the user's refresh token encrypted with the operating system's secure storage. See [Sign in with Google for Vertex AI](/docs/cowork/3p/vertex-google-sign-in) for the full flow. ## Configure the app With Google Cloud set up and devices prepared, open the in-app configuration window (**Developer → Configure third-party inference**) on an evaluation device. In the **Connection** section, set **Inference provider** to **Vertex** and fill in the **Vertex credentials** card with the values for whichever authentication approach you chose: | Field | Service-account key | In-app Google sign-in | | -------------------------- | ---------------------- | ---------------------------------------------- | | GCP project ID | `your-gcp-project` | `your-gcp-project` | | GCP region | e.g. `us-east5` | e.g. `us-east5` | | GCP credentials file path | `/path/to/sa-key.json` | *leave empty* | | Vertex OAuth client ID | *leave empty* | `1234567890-abc123.apps.googleusercontent.com` | | Vertex OAuth client secret | *leave empty* | `GOCSPX-xxxxxxxxxxxxxxxxxxxx` | | Vertex OAuth scopes | *leave empty* | *leave empty for the default* | | Vertex AI base URL | *optional* | *optional* | Under **Identity & models**, add at least one **Model list** entry using the Vertex publisher model ID, for example `claude-sonnet-4@20250514`. Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow. ### Configuration keys The full set of Vertex keys is below. Set `inferenceProvider` to `vertex`, supply a project and region, and provide exactly one credential source. | Setting | Required | Description | | ------------------------------------------------------------------ | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GCP project ID
`inferenceVertexProjectId` | Yes | Google Cloud project ID. | | GCP region
`inferenceVertexRegion` | Yes | Google Cloud region for the Vertex AI endpoint, for example `us-east5` or `europe-west4`. `global` is also accepted where the model supports it. | | GCP credentials file path
`inferenceVertexCredentialsFile` | One credential source | Absolute path to a service-account key, `authorized_user`, or `external_account` (Workforce Identity Federation) JSON file. No `~` or environment-variable expansion. If set, in-app Google sign-in is disabled. | | Vertex OAuth client ID
`inferenceVertexOAuthClientId` | One credential source (with secret) | Client ID of a Desktop-app OAuth client in your Google Cloud project. Enables in-app [Google sign-in](/docs/cowork/3p/vertex-google-sign-in). | | Vertex OAuth client secret
`inferenceVertexOAuthClientSecret` | With OAuth client ID | Client secret paired with the client ID above. Not treated as confidential for installed apps. | | Vertex OAuth scopes
`inferenceVertexOAuthScopes` | No | Space-separated OAuth scopes for Google sign-in. Defaults to `openid email https://www.googleapis.com/auth/cloud-platform`. | | Vertex AI base URL
`inferenceVertexBaseUrl` | No | Override the public regional endpoint, for example with a Private Service Connect address. Must be `https://`. | If neither `inferenceVertexCredentialsFile` nor the OAuth client keys are set, the Google client library falls back to the standard Application Default Credentials search path on the device (`~/.config/gcloud/application_default_credentials.json`, then the environment's metadata server). You must also set `inferenceModels` to a list of Vertex publisher model IDs, for example `claude-sonnet-4@20250514`. See the [Configuration reference](/docs/cowork/3p/configuration#models). ## What users experience The first-launch and re-authentication behavior depends on the authentication approach. | Approach | First launch | Re-authentication | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Credentials file (service-account key) | Cowork opens directly; no user action. | Never, until you rotate the key file. | | In-app Google sign-in | The Cowork tab shows a **Sign in with Google** page. Clicking it opens Google's consent flow in the default browser. After approval, the app relaunches into Cowork. | When the refresh token is revoked, when you deploy a new OAuth client ID, or when your Google Cloud session-control policy expires it. | For in-app Google sign-in, users can sign out by revoking the app from their Google Account's [third-party connections page](https://myaccount.google.com/connections); the app detects the revoked token at the next session start and shows the sign-in page again. ## Troubleshoot To confirm which keys the app read and whether credentials validated, use **Help → Troubleshooting → Copy Managed Configuration Report**; see [Verifying the deployment](/docs/cowork/3p/installation#verifying-the-deployment) for that workflow and the common causes when the app does not enter 3P mode. Application log locations are listed in [Data storage and residency](/docs/cowork/3p/data-storage). # Sign in with Google for Google Cloud's Vertex AI Source: https://claude.com/docs/cowork/3p/vertex-google-sign-in Configure per-user Google authentication for Google Cloud's Vertex AI instead of distributing a shared service-account key By default, Cowork on 3P authenticates to Google Cloud's Vertex AI with a credentials file that you distribute to every device (`inferenceVertexCredentialsFile`). As an alternative, you can configure an interactive Google sign-in. Each user authenticates once with their own Google Workspace account, and the app stores an encrypted refresh token on the device. Use Google sign-in when you want: * Per-user attribution in Cloud Audit Logs instead of a single shared service account * IAM controlled at the user or group level rather than at the key * To avoid distributing and rotating long-lived service-account key files The sign-in experience uses a Google OAuth client that **you create in your own Google Cloud project**. Anthropic does not provide or operate an OAuth client for this flow. ## How it works When `inferenceVertexOAuthClientId` and `inferenceVertexOAuthClientSecret` are both set and `inferenceVertexCredentialsFile` is not, the app shows a **Sign in with Google** page the first time a user opens the Cowork tab. Clicking the button opens the system browser for a standard Google consent flow, and the app listens on a loopback address for the redirect. On success, the app stores the user's Google refresh token encrypted with the operating system's secure storage (Keychain on macOS, DPAPI on Windows) and relaunches into Cowork. At the start of each Cowork session, the app writes an `authorized_user` Application Default Credentials file (the same format produced by `gcloud auth application-default login`) into the session sandbox and points `GOOGLE_APPLICATION_CREDENTIALS` at it. The Google Cloud client library inside the sandbox handles access-token minting and refresh automatically. If the stored refresh token is revoked or expires, or if you deploy a new OAuth client ID, the app clears the stored token and shows the sign-in page again. ## Prerequisites * A Google Cloud project with the **Vertex AI API** enabled, containing the Claude models you intend to serve * Admin access to that project to create an OAuth client and grant IAM roles * A Google Workspace organization (recommended) so the OAuth consent screen can be set to **Internal** ## Set up Google sign-in In the Google Cloud Console for your Vertex project, open **APIs & Services → OAuth consent screen**. If your project belongs to a Google Workspace organization, select the **Internal** user type. Internal apps are limited to users in your Workspace and do not require Google verification, regardless of which scopes they request. If the project is not in a Workspace organization, you must use the **External** user type. Because this flow requests the `https://www.googleapis.com/auth/cloud-platform` scope, Google classifies the app as using a sensitive scope, and publishing it beyond test users requires Google's OAuth verification process. For that reason, Internal is strongly recommended for enterprise deployments. In **APIs & Services → Credentials**, choose **Create credentials → OAuth client ID**, and select **Desktop app** as the application type. Record the generated **Client ID** (ending in `.apps.googleusercontent.com`) and **Client secret**. For installed applications, Google does not treat the client secret as confidential; the flow is protected by PKCE and by the loopback redirect, so it is safe to distribute the secret in a managed configuration profile. You do not need to add redirect URIs. Desktop-app clients permit loopback (`http://127.0.0.1:`) redirects automatically. Each signed-in user calls Vertex AI as themselves, so each user's Google identity needs permission to invoke the model. On the Vertex project, grant the **Vertex AI User** role (`roles/aiplatform.user`) to the Google Workspace group that contains your Cowork users, or to individual users. If your organization uses a narrower custom role, it must include at minimum the `aiplatform.endpoints.predict` permission. Open the in-app configuration window (**Developer → Configure third-party inference**) on an evaluation device. In the **Connection** section, set **Inference provider** to **Vertex**, then fill in the **Vertex credentials** card: | Field | Value | | -------------------------- | ---------------------------------------------- | | GCP project ID | `your-gcp-project` | | GCP region | e.g. `us-east5` | | GCP credentials file path | *leave empty* | | Vertex OAuth client ID | `1234567890-abc123.apps.googleusercontent.com` | | Vertex OAuth client secret | `GOCSPX-xxxxxxxxxxxxxxxxxxxx` | | Vertex OAuth scopes | *leave empty for the default* | Leave **GCP credentials file path** empty — if it's set, the static credentials file takes precedence and the sign-in page is never shown. Then click **Export** to produce a `.mobileconfig` (macOS) or `.reg` (Windows) file for your MDM. See [Installation and setup](/docs/cowork/3p/installation) for the export and deployment workflow, or the [Configuration keys](#configuration-keys) table below if you author policy by hand. The sign-in flow and subsequent token refreshes reach `accounts.google.com` and `oauth2.googleapis.com` from the user's device. These hosts are already included in the standard Vertex AI egress requirements, so if you allowed egress based on the **Egress Requirements** section of the configuration window, no additional firewall changes are needed. ## User experience On first launch after the configuration is applied, the Cowork tab shows a **Sign in with Google** page instead of the task composer. The user clicks the button, approves access in their default browser, and the app relaunches into Cowork automatically. The browser flow runs on the host, outside the Cowork sandbox, so it can use the user's existing Google session and any security keys or passkeys configured on the device. Users stay signed in across app restarts. To sign out, a user can revoke access for your OAuth client from their Google Account's [third-party connections page](https://myaccount.google.com/connections); the app detects the revoked token at the next session start and shows the sign-in page again. ## Configuration keys | Setting | Type | Description | | ------------------------------------------------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Vertex OAuth client ID
`inferenceVertexOAuthClientId` | string | Client ID of the Desktop-app OAuth client in your GCP project. Must be set together with the client secret. | | Vertex OAuth client secret
`inferenceVertexOAuthClientSecret` | string | Client secret for the OAuth client above. Not treated as confidential for installed apps; PKCE protects the flow. | | Vertex OAuth scopes
`inferenceVertexOAuthScopes` | string | Space-separated OAuth scopes requested during sign-in. Defaults to `openid email https://www.googleapis.com/auth/cloud-platform`. Override only if your organization's access policies restrict the default scope. | See [Using Cowork on 3P with Google Cloud's Vertex AI](/docs/cowork/3p/vertex) for the full list of Vertex keys. ## Notes and limitations * **Precedence.** If `inferenceVertexCredentialsFile` is set, it is used and Google sign-in is disabled. Remove that key to switch an existing deployment to per-user sign-in. * **Both keys required.** If only one of `inferenceVertexOAuthClientId` or `inferenceVertexOAuthClientSecret` is set, the app logs a warning and falls back to standard Application Default Credentials discovery. * **Credential helper not applicable.** `inferenceCredentialHelper` is not invoked when `inferenceProvider` is `vertex`, because Vertex authentication is file-based rather than token-based. Use Google sign-in or a credentials file instead. * **Client rotation.** If you replace the OAuth client in Google Cloud and push the new client ID via MDM, existing users are automatically signed out and prompted to sign in again on next launch. # Web search and web fetch Source: https://claude.com/docs/cowork/3p/web-tools How Cowork on 3P reaches the internet, which providers support search, and how to control or disable web access Cowork includes two built-in tools for reaching the web: * **Web Search** runs a search-engine query and returns ranked results. * **Web Fetch** retrieves the contents of a specific URL. In Cowork on third-party (3P), both are subject to your configuration: search depends on your inference provider, and fetch is gated by the sandbox network allowlist. ## Web Search Web Search is a **server-side tool** executed by your inference provider, not by the desktop app. Availability depends on which provider you've configured: | Provider | Web Search | | ------------------------ | ------------------------------------------------------------------------- | | Google Cloud's Vertex AI | Available | | Microsoft Foundry | Available | | Amazon Bedrock | Not available | | Gateway | Available if your gateway implements Anthropic's `web_search` server tool | Because the search runs on the provider's infrastructure, queries and results travel over the same path as model inference and are subject to your provider's data-handling terms. No additional firewall rules are needed beyond the inference endpoint itself. If your provider doesn't support search, or you want to use a different search backend, deploy a search MCP server via [`managedMcpServers`](/docs/cowork/3p/configuration#managedmcpservers) and disable the built-in tool (below). ## Web Fetch Web Fetch runs in the Claude Desktop main process on the user's device. The model supplies only the target URL; it cannot set headers, a request body, or credentials. Every fetch, including redirect targets, is checked against `coworkEgressAllowedHosts` before the request is sent. By default, the sandbox can reach only your inference provider's endpoint, so Web Fetch will fail for any other host unless you've allowed it. To permit fetches: | Goal | Set `coworkEgressAllowedHosts` to | | -------------------------------------- | --------------------------------------------------- | | Allow specific domains | `["docs.example.com", "*.your-org.com"]` | | Allow all hosts (no sandbox filtering) | `["*"]` | | Block all fetches | `[]` and add `"WebFetch"` to `disabledBuiltinTools` | Wildcards match one or more leading subdomain labels (`*.example.com` matches `a.example.com` and `a.b.example.com`, but not `example.com`). `coworkEgressAllowedHosts` controls what the agent's tools can reach. Your perimeter firewall is a separate, outer layer, so a host allowed by this key still won't be reachable if your corporate network blocks it. See [Telemetry and egress](/docs/cowork/3p/telemetry#required-egress-paths) for the distinction. The same allowlist governs other in-sandbox network activity (for example, `curl` or `pip install` from the agent's shell), not just the Web Fetch tool. ## Disabling web tools To remove web tools entirely, add them to `disabledBuiltinTools`: ```json theme={null} ["WebSearch", "WebFetch"] ``` With both disabled and `coworkEgressAllowedHosts` empty, the agent has no path to the public internet from inside the sandbox. It can still read and write local files, run code against them, and call any MCP servers you've provisioned. See the [Locked down profile](/docs/cowork/3p/configuration#recommended-security-profiles). # Run tasks in the background with Dispatch Source: https://claude.com/docs/cowork/guide/dispatch Assign work to a Dispatch agent that plans, runs, and reports on tasks while you do something else, on this computer or from your phone. Dispatch is a long-running agent in Cowork that takes high-level instructions and carries them out in the background. You describe an outcome in a single conversation; the Dispatch agent breaks it into tasks, runs each one as a separate Cowork or Code session, and surfaces the results in the sidebar when they finish. Unlike a normal Cowork chat, you don't watch each step. Dispatch is for work you want to start and come back to later. ## Prerequisites Dispatch requires a Pro or Max plan and the latest Claude Desktop app on macOS or Windows. ## Start a Dispatch task The Dispatch agent appears as **Dispatch** in the left sidebar. Selecting it opens a single conversation with the agent. Select **Dispatch** in the left side panel. Tell the agent what you want done, the same way you'd brief a colleague. For example: "Summarize the open Linear issues tagged reliability and draft a status update for the team channel." The agent decides how to split the work and starts one or more child tasks. Each child task appears under the Dispatch group in the sidebar with its own status. You converse with one Dispatch agent, but it can run many child tasks beneath that conversation. Child tasks don't spawn further children of their own. ## How Dispatch routes work The Dispatch agent routes each child task to the surface that fits it. | Task type | Runs in | Examples | | -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------ | | Coding work | Code, against a workspace you've already set up | Fix a bug, open a pull request, run tests | | Knowledge work | Cowork, in the [project](/docs/cowork/guide/projects) you specify (or your default project) | Research, write a document, organize files | When starting a task, you can tell the agent which Code workspace or Cowork project to use. If you don't, it lists what's available and chooses. ## Track task status Each child task shows its current state in the sidebar. Select any task to open its full transcript, the steps Claude took, and any files it produced. | State | Meaning | | --------------- | ---------------------------------------------------------- | | Running | Claude is actively working on the task | | Awaiting input | The task needs information from you before it can continue | | Awaiting answer | The task asked you a question and is waiting for a reply | | Completed | The task finished | | Error | The task stopped because something went wrong | | Archived | You marked the task as done and set it aside | ## Approve actions Dispatch needs When a child task needs permission to take an action (such as running a command or writing a file outside its workspace), the prompt is forwarded to you. If you don't respond within ten minutes, the request is automatically denied and the task continues without that action. Permission prompts behave the same as in a normal Cowork session. ## Continue from a finished task Select any child task in the sidebar to open its session. You can read the transcript, send follow-up messages, or ask the Dispatch agent to start a new task that builds on the result. ## Assign tasks from your phone When Claude Desktop is running, your computer registers as a Dispatch host. From the Claude mobile app, you can start a Dispatch conversation that runs on your desktop, then check results from either device. Leave Claude Desktop open with your computer awake and online. In the Claude mobile app, open Dispatch and describe the task. The work runs on your desktop. Progress and results appear in the Dispatch sidebar on desktop and in the mobile app. ## Related * [Organize work with projects](/docs/cowork/guide/projects) for the project context Dispatch routes knowledge work into * [Cowork overview](/docs/cowork/overview) for how Dispatch fits alongside sessions and projects # Install plugins Source: https://claude.com/docs/cowork/guide/plugins Add packaged skills, connectors, and agents to Cowork from the plugin marketplace or a file. A plugin is a package that extends what Claude can do in Cowork. Installing one can add skills, MCP connectors, subagents, slash commands, or hooks in a single step. Plugins come from the marketplace, from your organization, or from a file you upload. Plugins are available in Cowork and Code. They aren't used in Chat. ## What a plugin can contain A plugin's manifest declares any combination of the following. | Component | What it adds | | ---------- | ---------------------------------------------------------- | | Skills | Reusable instructions that teach Claude a workflow | | Connectors | MCP servers that give Claude access to an external service | | Agents | Specialized subagents Claude can delegate to | | Hooks | Scripts that run at defined points in a session | After installing, open the plugin to see what it provides. Skills and agents appear as tabs; connectors and hooks have their own pages. ## Install a plugin Open **Customize** in the sidebar, then **Plugins**. Select **Browse plugins** to see available plugins. The default marketplace is Anthropic's official catalog; you can add other marketplaces by URL. Select a plugin and click **Install**. If the plugin includes a connector that needs authentication, you're prompted to sign in. Open the installed plugin to see its skills, connectors, agents, and hooks. Enable or disable individual components as needed. To install from a file instead, select the upload option on the Plugins page and select the plugin package. ## Use a Git repository as a marketplace A Git repository that contains plugin packages can serve as a marketplace. This is the typical way teams distribute their own plugins without publishing to the public catalog. Repositories on GitHub (including GitHub Enterprise) are supported; public repositories on GitLab and Bitbucket also work. On the Plugins page, select **Add marketplace** and enter the repository's URL. Cowork accepts the standard `https://github.com/owner/repo` form and the `owner/repo` shorthand for GitHub. Plugins defined in the repository appear alongside plugins from other marketplaces. Install them the same way. Click **Update** on a marketplace to pull the latest plugins from its repository. For administrator-managed marketplaces, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide. ## Limits The following are the default limits for plugin packages and marketplaces. | Limit | Value | | ---------------------------------- | ------ | | Plugin package size (uncompressed) | 200 MB | | Files per plugin package | 5,000 | | Marketplace repository archive | 512 MB | | Plugins per marketplace | 500 | | Marketplaces you can add | 25 | ## Plugins managed by your organization On Team and Enterprise plans, administrators can require certain plugins for everyone in the organization. Required plugins install automatically and show **This plugin is required by your organization**; you can't remove them. For how administrators provision plugins, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide. ## Update and remove plugins Cowork checks for plugin updates from the marketplace they came from. If you've edited a plugin's files locally, Cowork detects the change and warns you before an update would overwrite it. To remove a plugin you installed, open it under **Customize → Plugins** and click **Uninstall**. Organization-managed plugins can only be removed by an administrator. ## Related * [Plugins overview](/docs/plugins/overview) for how plugins work across Claude products * [Submit a plugin](/docs/plugins/submit) to publish your own to the marketplace * [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) for administrator provisioning # Organize work with projects Source: https://claude.com/docs/cowork/guide/projects Group folders, instructions, and context into a Cowork project so Claude starts each session with the right setup. A Cowork project collects everything Claude needs for a recurring area of work: the local folders to read and write, standing instructions, useful links, and a dedicated memory store. When you start a session inside a project, Claude is already set up with that context. Projects live on your computer. They aren't synced to the cloud or shared with other people. ## What a project holds Each project bundles the following, and you can change any of it after creation. | Item | Purpose | | ------------------ | ------------------------------------------------------------------------------------- | | Description | What the project is for; Dispatch reads it when choosing a project for a task | | Folders | One or more local folders Claude can read and write inside this project's sessions | | Instructions | Standing guidance applied to every session in the project | | Links | Reference URLs (documents, dashboards, repositories) Claude can consult | | Projects from Chat | Projects you made in Chat (claude.ai) whose knowledge this Cowork project can draw on | | Memory | A project-scoped memory store that persists across sessions | ## Create a project Open **Projects** in the left navigation and choose the **+** button to start. You're offered three starting points. Select **Start from scratch** to create an empty project with a new folder, **Import a project** to bring an existing claude.ai project into Cowork, or **Use an existing folder** to point at a folder you already work from. Give the project a name and a short description so you can tell it apart in the sidebar. Attach the local folders Claude should have access to, and write any standing instructions you want applied to every session. You can attach more folders, links, or projects from Chat at any time from the project's settings. ## Work inside a project Select a project in the sidebar to start a new Cowork session with that project's folders mounted and instructions applied. Files Claude creates land in the project's folders; what Claude learns during the session is saved to the project's memory for next time. [Dispatch](/docs/cowork/guide/dispatch) can also route background tasks into a project, so long-running work picks up the same folders, instructions, and memory. When you drag files or folders into a project, individual files are copied into the project's first folder and folders are mounted as additional project folders. Claude reads individual files up to 50 MB. ## Cowork projects and claude.ai projects A Cowork project is not the same thing as a project on claude.ai. They're stored separately and have different capabilities. | | Cowork project | claude.ai project | | ------------------------ | --------------------- | --------------------------- | | Lives | On your computer only | In your Claude account | | Holds local folders | Yes | No | | Shareable with teammates | No | Yes, on Team and Enterprise | You can link a claude.ai project into a Cowork project so Cowork sessions can draw on its knowledge. Linking doesn't merge them; the claude.ai project stays where it is. ## Archive a project Archiving removes the project from your list and deletes its metadata (name, instructions, links, memory). It does not touch the local folders you attached; your files stay exactly where they are on disk. To archive, open the project's menu in the sidebar and choose **Archive**. ## Related * [Run tasks in the background with Dispatch](/docs/cowork/guide/dispatch) to run work inside a project without watching each step * [Install plugins](/docs/cowork/guide/plugins) to extend what Claude can do in a project's sessions * [Cowork overview](/docs/cowork/overview) for how projects relate to sessions and Dispatch # Monitoring Source: https://claude.com/docs/cowork/monitoring Track Cowork usage and activity across your organization with OpenTelemetry Track Cowork usage and activity across your organization by exporting events through [OpenTelemetry](https://opentelemetry.io/) (OTel). Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, API requests, tool usage, and errors. Monitoring is available for Team and Enterprise plans. OTel monitoring requires Claude desktop app version 1.1.4173 or later. ## Setup Configure monitoring from the Cowork admin settings: 1. Navigate to **Admin settings > Cowork** 2. Configure the following fields: | Field | Description | Example | | ----------------- | ----------------------------------------- | ----------------------------------- | | **OTLP endpoint** | Your OpenTelemetry collector URL | `http://collector.example.com:4318` | | **OTLP protocol** | Transport protocol | `http/json` or `http/protobuf` | | **OTLP headers** | Authentication headers for your collector | `Authorization=Bearer your-token` | 3. Save your settings 4. Start a new Cowork session — settings are loaded at session start, so existing sessions won't pick up the new configuration If your organization has network egress restrictions enabled, add your collector domain to the allowlist at **Admin settings > Capabilities > Network egress**. The OTel exporter runs inside the Cowork VM, and traffic to non-allowlisted domains is silently dropped. ## Events Cowork exports the following events to your OTel collector. User prompt content and tool details are always included in events. ### Event correlation When a user submits a prompt, Cowork may make multiple API calls and run several tools. The `prompt.id` attribute links all events back to the single prompt that triggered them. | Attribute | Description | | ----------- | ------------------------------------------------------------------------------------ | | `prompt.id` | UUID v4 identifier linking all events produced while processing a single user prompt | To trace all activity triggered by a single prompt, filter your events by a specific `prompt.id` value. ### Standard attributes All events include these attributes: | Attribute | Description | | ---------------------- | -------------------------------------------------------------------------------------------- | | `session.id` | Unique session identifier | | `organization.id` | Organization UUID | | `user.account_uuid` | User's account UUID | | `user.account_id` | Account ID in tagged format matching Anthropic admin APIs (for example, `user_01BWBeN28...`) | | `user.id` | Anonymous device/installation identifier | | `user.email` | User email | | `workspace.host_paths` | Host workspace directories selected in the desktop app (string array) | | `terminal.type` | Terminal type (`non-interactive` for Cowork) | ### User prompt event Logged when a user submits a prompt. **Event name**: `user_prompt` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `prompt_length` | Length of the prompt | | `prompt` | Prompt content | ### Tool result event Logged when a tool completes execution. **Event name**: `tool_result` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `success` | `"true"` or `"false"` | | `duration_ms` | Execution time in milliseconds | | `error` | Error message (if failed) | | `decision_type` | Either `"accept"` or `"reject"` | | `decision_source` | How the decision was made — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | | `tool_result_size_bytes` | Size of the tool result in bytes | | `mcp_server_scope` | MCP server scope identifier (for MCP tools) | | `tool_parameters` | JSON string containing tool-specific parameters, including `mcp_server_name` and `mcp_tool_name` for MCP tools | | `tool_input` | JSON-serialized tool arguments. Individual strings over 512 characters are truncated; entire string limited to \~4K characters. Applies to all tools including MCP tools. | ### API request event Logged for each API request to Claude. **Event name**: `api_request` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used (e.g., `claude-sonnet-4-6`) | | `cost_usd` | Estimated cost in USD | | `duration_ms` | Request duration in milliseconds | | `input_tokens` | Number of input tokens | | `output_tokens` | Number of output tokens | | `cache_read_tokens` | Number of tokens read from cache | | `cache_creation_tokens` | Number of tokens used for cache creation | | `speed` | `"fast"` or `"normal"` | ### API error event Logged when an API request to Claude fails. **Event name**: `api_error` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used | | `error` | Error message | | `status_code` | HTTP status code as a string, or `"undefined"` for non-HTTP errors | | `duration_ms` | Request duration in milliseconds | | `attempt` | Attempt number (for retried requests) | | `speed` | `"fast"` or `"normal"` | ### Tool decision event Logged when a tool permission decision is made. **Event name**: `tool_decision` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------ | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `decision` | Either `"accept"` or `"reject"` | | `source` | Decision source — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | ## Event analysis The exported events support a range of analyses: **Tool usage patterns** — Analyze tool result events to identify most frequently used tools, success rates, average execution times, and error patterns. **Cost monitoring** — Track `cost_usd` from API request events to understand usage trends across users and teams. Group by `user.account_uuid` or `organization.id` for per-user or per-team breakdowns. **Performance monitoring** — Track API request durations and tool execution times to identify performance bottlenecks. Cost values from events are approximations. For official billing data, refer to your billing dashboard. ## Backend considerations Your choice of logs backend determines the types of analyses you can perform: * **Log aggregation systems** (e.g., Elasticsearch, Loki): Full-text search and log analysis * **Columnar stores** (e.g., ClickHouse): Structured event analysis and complex queries * **Observability platforms** (e.g., Honeycomb, Datadog): Advanced querying, visualization, and alerting ## Service information All events are exported with the following resource attributes: | Attribute | Description | | ----------------- | -------------------------------------- | | `service.name` | `cowork` | | `service.version` | Claude app version | | `host.arch` | Host architecture (e.g., `arm64`) | | `os.type` | Operating system type (e.g., `darwin`) | | `os.version` | Operating system version string | ## Security and privacy * Events are only exported when an admin configures the OTLP endpoint * User prompt content is included in events — configure your telemetry backend to filter or redact if needed * Tool execution events include the `tool_input` attribute with file paths, URLs, search patterns, and other arguments — configure your telemetry backend to filter or redact `tool_input` if these may contain sensitive values * `user.email` is included in event attributes — work with your telemetry backend to filter or redact if this is a concern # Overview Source: https://claude.com/docs/cowork/overview Learn about Cowork, Anthropic's agentic workspace Cowork uses the same agentic architecture that powers Claude Code, accessible within Claude Desktop without opening the terminal. Rather than responding to prompts sequentially, Claude tackles intricate, multi-step tasks autonomously. Describe a desired outcome, then return later to completed work — polished documents, organized files, synthesized research, and more. ## Key capabilities * **Works directly on your computer** — Claude reads and writes local files without requiring manual uploads or downloads. * **Claude in Chrome** — Pair [Claude in Chrome](https://claude.com/chrome) with Cowork to automate your tasks on any website. * **Sub-agent coordination** — Complex work gets divided into smaller tasks with parallel workstreams for faster results. * **Professional outputs** — Creates polished deliverables including Excel spreadsheets with functional formulas, PowerPoint presentations, and formatted documents. ## Extend Cowork with integrations Cowork supports the same extensibility features available across Claude products: Connect Claude to your tools and data sources using MCP. Teach Claude reusable workflows with custom instructions. Bundle skills, connectors, and more into shareable packages. Track usage and activity across your organization. # Get started building with Claude.ai Source: https://claude.com/docs/index Get started building with Connectors, Plugins, and other Claude.ai features. ## Create an account Create a Claude.ai account to start using Connectors, Plugins, and other features. 1. Go to [claude.ai](https://claude.ai) 2. Select **Continue with Google** or enter your email address 3. Follow the prompts to complete registration All plans have access to the [Connectors Directory](/docs/connectors/directory). Free plans can also add one [custom connector](/docs/connectors/custom/remote-mcp). ## Start building Connect Claude to your existing tools and data, or extend its capabilities with custom skills and plugins: Connect Claude to Google Drive, GitHub, Slack, Microsoft 365, and custom MCP servers. Extend Claude's capabilities with the Agent Skills Open Standard. Bundle skills, connectors, and more into shareable packages for Cowork and Claude Code. ## Developer access For developers integrating Claude into applications: Manage your API access, usage, and billing. Developer documentation and API reference. # Connectors and Skills Source: https://claude.com/docs/office-agents/connectors-and-skills Extend Claude for Excel, PowerPoint, Word, and Outlook with external context and reusable task recipes. Connectors and Skills work the same way across Claude for Excel, PowerPoint, Word, and Outlook. Both are enabled in your Claude settings. Connectors and Skills are available when you sign in with your Claude account directly. When connecting through a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, these capabilities may not be available. See the feature comparison in [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) for the current status by connection mode. ## Connectors Connect external tools to give Claude context beyond what's in the file or email you have open. In any Claude for M365 add-in, click the **+** button below the chat input and select **Connectors** to see available options. Common connectors used with Claude for M365 include S\&P Global, LSEG, and Daloopa for financial data, plus any custom connectors your organization has enabled. Custom connectors can introduce security risks. Before enabling one, review [Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) for guidance on what to consider. ## Skills Skills you've enabled in your Claude settings are available in all Claude for M365 add-ins. Claude applies relevant Skills automatically based on what you're doing. You can also invoke a Skill directly: type `/` in the sidebar to see Skills available for the app you're in, then select one, such as `/deck-check` in PowerPoint. Skills that aren't relevant to the current app are excluded from this list. See [Use Skills in Claude](https://support.claude.com/en/articles/12512180-use-skills-in-claude) for details on enabling and managing Skills. ## Related See the per-app guides for setup and feature details. * [Use Claude for Excel](/docs/office-agents/excel) * [Use Claude for PowerPoint](/docs/office-agents/powerpoint) * [Use Claude for Word](/docs/office-agents/word) * [Use Claude for Outlook](/docs/office-agents/outlook) # Use dictation in Claude for M365 Source: https://claude.com/docs/office-agents/dictation Speak your prompts instead of typing them in Claude for Excel, PowerPoint, Word, and Outlook. Dictation lets you speak prompts instead of typing them. Click the microphone icon in the chat input, speak, and see your words appear in the composer in real time. Dictation requires the desktop version of Excel, PowerPoint, Word, or Outlook. It is not available in Office on the web because browser-hosted add-ins cannot access the microphone. On the web, use your operating system's built-in dictation or your Office application's dictation feature instead. Dictation is also available only for organizations using direct Claude authentication. It is not supported when Claude for M365 connects through a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) for platform support details. ## Use dictation Click the microphone icon on the right side of the chat input. The placeholder changes to "Listening..." and the button highlights. Words appear in the composer as you talk. Click the microphone again to stop, or press Enter to stop and send in one step. To select a different microphone, hover over the microphone icon and click the arrow that appears. ## How it works When you start dictating, the add-in streams your audio to Anthropic's transcription service, the same infrastructure that powers dictation in the Claude apps. The transcribed text displays in real time in the composer. Nothing is transcribed on your device. Audio is streamed to Anthropic, which uses a contracted speech-to-text subprocessor to generate the transcript. Audio is not retained after transcription; only the resulting text remains in your composer. ## Why dictation is not available with third-party authentication In third-party environments, Claude for M365 does not send prompts to Anthropic directly. Spoken audio is effectively a prompt, so dictation is not offered there. Use your operating system's built-in dictation or your Office application's dictation feature instead. # Security, admin auditability, and analytics Source: https://claude.com/docs/office-agents/enterprise-readiness Security architecture diagrams, OpenTelemetry audit, usage analytics, and spend tracking for enterprise admins deploying Claude for M365. Enterprise administrators deploying Claude for Excel, PowerPoint, Word, and Outlook can review the security architecture for their chosen deployment mode and connect audit logs, usage analytics, and spend tracking to existing enterprise tooling. ## Security architecture The Trust Center publishes architecture diagrams that show how user prompts, document content, and responses flow between the Office add-ins, Claude, and your infrastructure. Review the diagram that matches your deployment mode before rollout. * **Anthropic first-party**: users sign in with their Claude accounts and requests go directly to Claude. See the [first-party architecture overview](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx\&name=claude-for-excel,-powerpoint,-word:-architecture-overview-%28anthropic-first-party%29). * **Third-party platforms**: requests route through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. The companion third-party architecture diagram is listed alongside the first-party one in the [Trust Center resources](https://trust.anthropic.com/resources?s=e3n7pvyjnxjyahmdmqujcx); filter for "Claude for Excel, PowerPoint, Word". See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) for deployment guidance. ## Audit and observability Forward Claude for M365 activity to your existing observability stack with a custom OpenTelemetry collector endpoint. When a custom collector is configured, spans are exported unfiltered to that endpoint and include the full audit trail: session identifiers, surface, tool inputs and outputs, and prompt and response content. Treat the endpoint as containing prompt and document content when scoping access controls and retention. Only spans sent to Anthropic's own collector are allowlist-filtered to strip sensitive attributes; that path is bypassed entirely when a custom endpoint is set. See [Configure a custom OpenTelemetry collector for Claude for M365](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) for the manifest parameters and endpoint requirements. The usage analytics and spend tracking sections below apply when users sign in with their Claude accounts directly. When connecting through a third-party platform such as Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, usage and spend are tracked through your cloud provider's billing console and your gateway's logging instead. ## Usage analytics Pull Claude for M365 usage into your own BI or reporting pipeline through the Claude Enterprise Analytics API. The API exposes per-user, per-surface, and per-organization aggregates. See [Claude Enterprise Analytics API reference guide](https://support.claude.com/en/articles/13703965-claude-enterprise-analytics-api-reference-guide) for endpoints, request shapes, and aggregation windows. ## Spend tracking Download CSV exports of Team and Enterprise plan usage from the usage analytics dashboard in your admin console. Exports include per-seat and per-surface spend, making them suitable for chargeback and financial reconciliation. See [View usage analytics for Team and Enterprise plans](https://support.claude.com/en/articles/12883420-view-usage-analytics-for-team-and-enterprise-plans) for the steps to generate and download a report. ## Related The pages below cover deployment paths and plugins relevant to enterprise admins. * [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms) * [Install financial services plugins for Cowork](/docs/office-agents/fsi-plugins) # Use Claude for Excel Source: https://claude.com/docs/office-agents/excel An Excel add-in that integrates Claude into your spreadsheet workflow, for Pro, Max, Team, and Enterprise plans. Claude for Excel is an add-in that brings Claude into Excel. Ask questions about open workbooks, adjust assumptions while preserving formula relationships, debug errors, and build or populate models, all without leaving Excel. Claude for Excel is currently in beta and available to Pro, Max, Team, and Enterprise plans. ## What you can do With Claude for Excel, you can: * Ask questions about your workbook and get answers with cell-level citations. * Adjust assumptions while keeping formula relationships intact. * Identify and resolve errors and their root causes. * Generate new spreadsheet models or populate existing templates. * Work across multi-tab workbooks. * Pull external context through connectors such as S\&P Global, LSEG, and Daloopa. * Apply enabled Skills automatically while you work. ## Get started with Claude for Excel ### Supported versions Claude for Excel runs on the following Excel builds. * Excel on the web * Excel on Windows with a Microsoft 365 subscription, build 16.0.13127.20296 or later * Excel on Mac, version 16.46 or later, build 21011600 or later ### Install for yourself Go to the [Claude for Excel listing on Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/office/WA200009404). Select "Get it now" to install. Open Excel, activate the add-in, and sign in with your Claude account. ### Deploy to your organization Organization admins can deploy Claude for Excel through the Microsoft 365 Admin Center. In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go to Settings, Org Settings, User owned apps and services, and turn on ["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center). Go to Settings, Integrated apps, Add-ins. Search for "Claude by Anthropic for Excel" in Microsoft AppSource. Assign the add-in to your organization or to specific users or groups. Share [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins) with your team for activation steps. After deployment, users can activate the Claude add-in from Tools, Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working. For environments where "Let users access the Office Store" is disabled, deploy using the custom manifest XML file instead. Download the [Excel manifest XML file](https://pivot.claude.ai/manifest-excel.xml), then follow [Deploy with a custom manifest](/docs/office-agents/word#deploy-with-a-custom-manifest) for the upload steps. The flow is identical apart from which manifest file you upload in Step 1. ### Connect through a third-party platform If your organization routes AI traffic through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, your admin can deploy the add-in without individual Claude accounts. See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms). ## Key features ### Understand complex models Ask Claude to trace assumptions, explain formulas, or walk through how a number was derived. Answers include cell-level citations you can click to navigate to the referenced cell. Example prompts: * "Walk me through how the revenue number in cell C42 is calculated." * "What assumptions drive the gross margin forecast?" ### Update values safely Claude updates cell values while keeping formula relationships intact, so downstream cells recompute correctly. Example prompts: * "Change the discount rate to 8% and update dependent calculations." * "Flex the growth rate from 5% to 10% and show me the impact on terminal value." ### Build templates and models Populate an existing template or generate a new model from a natural language description. Example prompts: * "Populate this LBO template with a \$500M purchase price and 6x leverage." * "Build a three-statement model from this trial balance." ### Debug errors Locate the root cause of calculation errors and suggest fixes. Example prompts: * "Find the source of the #REF! error in the summary tab." * "Trace why cell H15 is returning #DIV/0." ### Native Excel operations Claude can sort, filter, edit pivot tables, apply conditional formatting, and create data validation dropdowns. Ask for these directly. ## Connectors and Skills Claude for Excel supports connectors for pulling external context into your workbook, and Skills for applying reusable task recipes. See [Connectors and Skills](/docs/office-agents/connectors-and-skills) for details. ## Set persistent instructions Open Settings in the add-in sidebar and use the Instructions field to set preferences that apply to every conversation in Excel. Instructions are useful for formatting conventions such as "format numbers with thousand separators" or "always bold column headers", currency or locale preferences, or recurring context about your workflow. Instructions you set in Excel only apply to Excel. They are separate from Instructions you set in PowerPoint or Word. ## Work across M365 apps Claude for Excel shares context with Claude for PowerPoint, Word, and Outlook, so a single conversation can span your open workbook, presentation, document, and inbox. See [Work across M365 apps](/docs/office-agents/work-across-apps). ## Context and session management The add-in handles long sessions and protects against accidental overwrites for you. * **Auto-compaction**: longer conversations are automatically compacted into new conversations to avoid running out of context. See [Understanding usage and length limits](https://support.claude.com/en/articles/11647753-understanding-usage-and-length-limits). * **Overwrite protection**: Claude warns you before overwriting existing data to avoid accidental data loss. Your use of Claude for Excel is associated with your existing Claude account and is subject to the same usage limits. ## Models available You can switch between Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6 when using the add-in. ## Data handling Inputs and outputs are deleted on the backend within 30 days of receipt or generation, except in cases outlined in [How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data). Data is cached for a number of hours after deletion so users can access context in recently closed workbooks. Chat history is stored locally in your browser using IndexedDB. Conversations are not stored on Anthropic's servers, are not synced across devices, and can be cleared from Settings at any time. Claude for Excel does not inherit custom data retention settings your organization might have set. Activity is not included in Enterprise audit logs or the Compliance API. ## Current limitations As a beta feature, Claude for Excel is not recommended for: * Final client deliverables without human review. * Audit-critical calculations without verification. * Models containing highly sensitive or regulated data without proper controls. Unsupported capabilities: * Data tables. * Macros and VBA operations. ### Unsupported versions The add-in does not run on these Excel versions. * Excel 2016 and 2019 perpetual or volume license. * Excel on iPad. The add-in requires SharedRuntime support, which iPad does not provide. * Excel on Android. * Older builds of Microsoft 365 Excel below the SharedRuntime threshold. ## Prompt injection risk Only use Claude for Excel with trusted spreadsheets. Files from external sources can contain hidden instructions that manipulate the add-in into extracting data, modifying records, or performing destructive actions. External files such as downloaded templates, vendor files, and data imports can contain prompt injections that try to trick Claude into taking unintended actions. Testing has identified scenarios where Claude for Excel can be manipulated to extract sensitive information, modify critical data, or perform destructive actions if allowed to act without verification. When Claude proposes a risky operation, you are asked to confirm before it runs. Review confirmations carefully, especially for files from external sources. ## Best practices Follow these guidelines to use Claude for Excel safely and effectively. * Always review changes before finalizing your work. * Start with a trusted copy of the workbook before asking Claude to edit widely. * Be specific about what you want changed. * Verify that outputs match your organization's standards and your own judgment. # Install financial services plugins for Cowork Source: https://claude.com/docs/office-agents/fsi-plugins Add the open-source financial services plugin set to Cowork for financial modeling, equity research, investment banking, private equity, and wealth management workflows. A set of open-source plugins extends Cowork with specialized capabilities for financial services workflows: financial modeling, equity research, investment banking, private equity, and wealth management. The plugins also work in Claude Code. The plugins live in a [public GitHub repository](https://github.com/anthropics/financial-services-plugins) that you can add as a marketplace in Cowork. ## What's included The repository contains a core plugin and several add-on plugins that build on it. | Plugin | What it does | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Financial analysis (core) | Build comparable company analyses, DCF models, LBO models, and 3-statement financials. Includes all shared MCP connectors for financial data providers. Install this first. | | Investment banking | Draft CIMs, teasers, and process letters. Build buyer lists, run merger models, and create strip profiles. | | Equity research | Write earnings updates and initiating coverage reports. Track catalysts and screen for new ideas. | | Private equity | Source and screen deals, run due diligence checklists, draft IC memos, and monitor portfolio company KPIs. | | Wealth management | Prep for client meetings, build financial plans, rebalance portfolios, and identify tax-loss harvesting opportunities. | The repository also includes partner-built plugins from LSEG and S\&P Global, which bring their financial data and analytics directly into Cowork. ## Add the marketplace Open the Claude Desktop app and select the Cowork tab in the mode selector. Select "Customize" on the left sidebar, then "Browse plugins". Select "Personal", click the "+" button, then select "Add marketplace from GitHub". Enter the repository URL: `https://github.com/anthropics/financial-services-plugins` Once added, you'll see the available financial services plugins in your marketplace. ## Install plugins From your plugin marketplace, browse the available financial services plugins. Install the financial analysis plugin first. It provides shared tools and data connectors that the other plugins use. Install any additional plugins that match your workflow needs. Once installed, plugins activate automatically. Skills are applied when relevant, or you can invoke them manually during your Cowork session by typing `/` or clicking the "+" button. ## Available Skills After installation, you can invoke Skills like the following. AI-generated financial analysis should always be reviewed by a qualified professional before being used in decision-making. | Skill | What it does | | ------------------------------- | --------------------------------------- | | `/comps [company]` | Run a comparable company analysis. | | `/dcf [company]` | Build a DCF valuation model. | | `/earnings [company] [quarter]` | Generate a post-earnings update report. | | `/one-pager [company]` | Create a one-page company profile. | | `/ic-memo [project name]` | Draft an investment committee memo. | | `/source [criteria]` | Source deals based on criteria. | | `/client-review [client]` | Prep for a client meeting. | ## MCP connectors The financial analysis core plugin includes connectors for third-party financial data providers including Daloopa, Morningstar, S\&P Global, FactSet, Moody's, MT Newswires, Aiera, LSEG, PitchBook, Chronograph, and Egnyte. Access to these connectors may require a separate subscription or API key from the respective provider. Contact your data provider for details. ## Customize plugins for your firm These plugins are starting points. Plugins are file-based Markdown and JSON, so no code or infrastructure is required to customize them. Edit the plugin files directly to match your firm's workflows. * Add your firm's terminology, processes, and formatting standards to skill files. * Swap or add MCP connectors to point at your specific data providers. * Adjust workflow instructions to reflect how your team does analysis. * Use `/ppt-template` to teach Claude your firm's branded PowerPoint layouts. ## Learn more See the [Cowork and plugins for finance](https://claude.com/blog/cowork-plugins-finance) blog post for background on how the plugins were designed. # Use Claude for Outlook Source: https://claude.com/docs/office-agents/outlook An Outlook add-in that integrates Claude into your inbox and calendar, for Pro, Max, Team, and Enterprise plans. Claude for Outlook is an add-in that brings Claude into your Outlook inbox and calendar. It is built for professionals whose work runs through email, including private equity and investment banking associates managing deal flow, in-house legal teams running counterparty negotiations, and consultants tracking multiple client threads. Claude for Outlook is currently in beta and available to Pro, Max, Team, and Enterprise plans. ## What you can do With Claude for Outlook, you can: * Triage your unread inbox into what needs you, what Claude can handle, and what is noise. * Draft replies, reply-alls, and forwards in your voice, landed unsent in Outlook's compose pane. * Summarize long threads into decisions made, open items, and who owes what, with per-email citations. * Read `.docx` and `.xlsx` attachments inline without opening them. * Find meeting times across attendees and draft invites into Outlook's native appointment form. * Prep for your next meeting with a one-page brief of recent threads and attached documents. ## Get started with Claude for Outlook ### Supported versions Claude for Outlook runs on the following Outlook clients. * Outlook on the web * Outlook on Windows, both new Outlook and classic Outlook, with a Microsoft 365 subscription * Outlook on Mac with a Microsoft 365 subscription The following are not supported: Outlook 2016 and 2019 perpetual or volume-licensed editions, Outlook on iOS, Outlook on Android, and mailboxes hosted on Exchange on-premises. Exchange Online through Microsoft 365 is required. ### Install for yourself Go to the [Claude for Outlook listing on Microsoft AppSource](https://appsource.microsoft.com/). Select "Get it now" to install. Open Outlook, open any email, select the Claude button in the message ribbon, and sign in with your Claude account. If you do not see the Claude button on the message, open the overflow menu on the reading pane, choose Customize actions, and check Claude under Apps. It then appears on every message and in the Home ribbon. ### Deploy to your organization Organization admins can deploy Claude for Outlook through the Microsoft 365 Admin Center. In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go to Settings, then Integrated apps. Search for "Claude by Anthropic for Outlook" in Microsoft AppSource. Deploy the add-in to your organization or to specific people. See [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins) for assignment options. Complete the [Microsoft Graph admin consent](#grant-microsoft-graph-consent) step below so users are not prompted individually. After installation, team members open Outlook, open any email, select the Claude button in the message ribbon, and sign in with their Claude credentials. Pinning the task pane keeps it open as you move between messages. ### Install from a manifest file If your organization blocks the Microsoft Store, an IT administrator can deploy the add-in by uploading its manifest file directly. Download the [Claude for Outlook manifest](https://pivot.claude.ai/manifest-outlook.xml) and save it to a secure location. In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go to Settings, then Integrated apps. Select Upload custom apps, then Office Add-in. Choose "I have a manifest file on this device", select the file you downloaded, and upload it. Choose your deployment scope: the entire organization, specific people, specific groups, or just yourself for testing. Review the settings and select Deploy. The add-in appears within minutes for most people. Full organization rollout can take up to 24 hours on the Microsoft 365 side. Complete the consent step in the next section. ### Grant Microsoft Graph consent Claude for Outlook reads mail and calendar data through Microsoft Graph. This requires a one-time tenant-wide grant from a Global Administrator and is separate from the Integrated apps deployment. Have a Global Administrator open the following admin consent link in a browser where they are signed in to your Microsoft 365 tenant. ``` https://login.microsoftonline.com/organizations/v2.0/adminconsent?client_id=c2995f31-11e7-4882-b7a7-ef9def0a0266&scope=https://graph.microsoft.com/Mail.ReadWrite%20https://graph.microsoft.com/Calendars.Read%20https://graph.microsoft.com/User.Read%20offline_access&redirect_uri=https://pivot.claude.ai/auth/callback ``` The administrator sees a Microsoft permissions screen listing `Mail.ReadWrite`, `Calendars.Read`, `User.Read`, and `offline_access`. After they select Accept, all users in the organization can use Claude for Outlook without additional Microsoft prompts. The grant takes effect immediately. Only the add-in rollout in the previous step can take up to 24 hours. If this step is skipped, every user sees a "Need admin approval" message when Claude first tries to read mail or calendar data. #### Use your own Entra app instead If your organization's policy does not permit consenting to a third-party multi-tenant application, register a single-tenant application in the Microsoft Entra admin center and have the add-in use it instead. The data flow is identical; the Graph token stays in the user's Outlook client either way. The difference is that approval and Conditional Access policy live entirely under an application your organization owns. In the Entra admin center, go to App registrations and create a new registration. Choose "Accounts in this organizational directory only". Under Authentication, add a Single-page application platform with redirect URI `brk-multihub://pivot.claude.ai`. In Advanced settings, set "Allow public client flows" to Yes. Under API permissions, add the Microsoft Graph delegated permissions `Mail.ReadWrite`, `Calendars.Read`, `User.Read`, and `offline_access`. Select "Grant admin consent" for your tenant. Copy the application's client ID from the Overview page. Append `?graph_client_id=YOUR_CLIENT_ID` to the manifest URL from the [Install from a manifest file](#install-from-a-manifest-file) section and use that URL when downloading the manifest. With this option, skip the admin consent link entirely. Users do not see a Microsoft permissions prompt because your tenant has already consented to your own application. ### Connect through a third-party platform If your organization routes API traffic through an internal LLM gateway, Google Cloud Vertex AI, or Azure AI Foundry, you can use the add-in without Claude accounts. This is the same gateway pattern used by Claude Code. Amazon Bedrock is not currently supported for Claude for Outlook. For setup instructions and gateway requirements, see [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms). ## Triage your inbox Ask Claude what needs your attention. Claude reads your unread mail and attachments and sorts them into three groups: action items for you, items Claude can handle for your review, and noise you can archive in one selection. Each action item carries a one-line reason. Items Claude can handle, such as scheduling asks, acknowledgments, and standard-form documents, arrive pre-drafted. Prompts to try: * "What needs me?" * "Draft replies for everything you can handle" * "Archive all the calendar responses and newsletters" ## Draft replies in your voice Tell Claude what you want to say. It drafts the reply into Outlook's native compose pane, unsent. Tone is learned from your sent folder, so the draft matches your sentence length and formality register. Claude leaves the closing off so Outlook can append your configured signature without duplication. Claude chooses reply versus reply-all deliberately and warns before adding anyone who was not on the thread. Prompts to try: * "Reply to this and agree to the extension, push back on the fee" * "Reply-all thanking everyone and confirming Thursday works" * "Forward this to Dana with a two-line summary" ## Summarize long threads Claude reads the entire conversation, including every reply and forward, and tells you what has been decided, what is still open, and who owes what. Every claim cites the specific email it came from. Selecting a citation opens that message in Outlook. Prompts to try: * "What's been decided and what's still open?" * "Who owes what on this thread?" ## Read attachments inline Claude reads `.docx` and `.xlsx` attachments on the open email without you opening them. For `.pptx` attachments, open the deck in PowerPoint with the thread loaded as context using [Work across M365 apps](/docs/office-agents/work-across-apps). PDF attachments are not currently read inline; save the file and upload it through the sidebar instead. Prompts to try: * "Summarize the attached memo" * "What's in the spreadsheet on this email?" ## Search your mailbox Ask Claude to find a past conversation by topic, not only by keywords. Results return as citations that open the source message in Outlook so you can verify every answer against the original email. Prompts to try: * "When did we last discuss the cap with Fernwood?" * "Find the email where Dana sent the revised term sheet" ## Find time and create events Claude checks free/busy for everyone whose calendar you can see and proposes slots that respect working hours and existing holds. The invite is drafted into Outlook's native appointment form with attendees, subject, and agenda for you to review and send. Prompts to try: * "Find 30 minutes with Dana and the Fernwood team next week" * "Block Thursday afternoon for deep work" ## Prep for meetings For your next event, Claude pulls the last thread with each attendee and any attached documents into a one-page brief, so you walk in knowing the open items and what each person last said. Prompts to try: * "Prep me for my 2pm" * "What's open with Dana before our call?" ## Work across M365 apps Claude for Outlook shares context with Claude for Excel, PowerPoint, and Word, so Claude can work across your open Office apps in a single conversation. For example, you can open an attached letter of intent in Word with the email thread already loaded as context, or pull numbers from an email into an open Excel model, without copying between apps. For setup instructions, see [Work across M365 apps](/docs/office-agents/work-across-apps). ## Model availability When you sign in with a Claude account, you can choose between Claude Opus 4.7, Opus 4.6, and Sonnet 4.6. When you connect through a third-party platform such as Vertex AI, Azure AI Foundry, or an LLM gateway, Opus 4.7 is the only officially supported model. ## How Claude accesses your mailbox Claude reads the email or event you have open via Office.js. For anything that spans your mailbox or calendar, including thread retrieval, search, free/busy lookups, and move or flag operations, Claude uses Microsoft Graph. Mailbox content is fetched on demand and not persisted on Anthropic's servers. The Graph access token stays in the browser's MSAL cache and is never sent to Anthropic. Claude never sends mail or invites on its own. The add-in does not request the `Mail.Send` permission. Every draft lands unsent in Outlook's compose or appointment form, and you click Send. ## Chat history Chat history is stored locally in your browser using IndexedDB. Conversations are not stored on Anthropic's servers and are not synced across devices or browsers. You can clear all chat history from Settings at any time. The local store is also cleared when you clear your browser data. Chat history is specific to the combination of the add-in surface, your user ID, and your organization ID, so your Excel and Outlook histories are separate. ## Data retention and audit For Claude for Outlook use, inputs and outputs are deleted on Anthropic's backend within 30 days of receipt or generation, except as described in [How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data) Enterprise organizations can route full audit telemetry from Claude for Outlook to their own OpenTelemetry collector for integration with a SIEM or observability platform. See [Configure a custom OpenTelemetry collector](/docs/office-agents/enterprise-readiness) for setup. On Pro, Max, and Team plans, observability and audit export are not available. Claude for Outlook does not inherit custom data retention settings your organization may have configured and is not included in Enterprise audit logs or the Compliance API at this time. ## Prompt injection risks Be cautious with email from external or untrusted senders. Email bodies and attachments are untrusted input and may contain instructions intended to manipulate Claude rather than you. Prompt injection refers to malicious instructions hidden in an email body, signature, or attachment that try to trick the AI into taking unintended actions. For example, a routine inbound email might contain hidden text instructing Claude to forward a thread or draft a reply you did not ask for. Claude may interpret these instructions as legitimate requests. Review every draft and inbox action before accepting it, especially when working with email from external or untrusted senders. ## Recommended use during beta As a beta feature, Claude for Outlook is not recommended for: * Unattended sending. Claude never sends mail or invites on its own; every draft lands unsent for your review. * Client-facing or counterparty correspondence without reading the draft first. * Replacing your judgment on which emails matter or how to handle a relationship. * Mailboxes containing privileged or regulated data without appropriate organizational controls. To use Claude for Outlook safely and effectively: * Review drafted replies and invites before sending, especially recipient lists. * Verify thread summaries against the cited source emails for high-stakes conversations. * Apply appropriate Microsoft 365 permissions and Conditional Access policies for the add-in. * Maintain human oversight for anything leaving your organization. # Claude for M365 overview Source: https://claude.com/docs/office-agents/overview Claude for Excel, PowerPoint, Word, and Outlook. Claude for M365 is a set of Claude-powered add-ins that work inside your Microsoft 365 apps. Chat with Claude about the file or email you have open, ask it to read or edit content, and move work between Excel, PowerPoint, Word, and Outlook without leaving the app. ## What's available today The pages below cover each surface and the features that span them. * [Claude for Excel](/docs/office-agents/excel): read and write cells, formulas, formatting, pivot tables, and charts. * [Claude for PowerPoint](/docs/office-agents/powerpoint): read, edit, and generate slides using your existing templates. * [Claude for Word](/docs/office-agents/word): draft, redline, and review documents with tracked changes and comment-driven editing. * [Claude for Outlook](/docs/office-agents/outlook): triage your inbox, draft replies in your voice, summarize threads, and find meeting times. Admins must complete a one-time [Microsoft Graph consent](/docs/office-agents/outlook#grant-microsoft-graph-consent) before deployment. * [Work across M365 apps](/docs/office-agents/work-across-apps): Claude for Excel, PowerPoint, Word, and Outlook share conversation state, so actions in one app are informed by what happened in the others. * [Connectors and Skills](/docs/office-agents/connectors-and-skills): extend Claude with external context and reusable task recipes. * [Dictation](/docs/office-agents/dictation): speak prompts instead of typing them. ## Deployment These pages cover enterprise admin setup and observability. * [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms): connect through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. * [Security, admin auditability, and analytics](/docs/office-agents/enterprise-readiness): security architecture diagrams, OpenTelemetry audit, usage analytics, and spend tracking. # Use Claude for PowerPoint Source: https://claude.com/docs/office-agents/powerpoint A PowerPoint add-in that integrates Claude into your presentation workflow, for Pro, Max, Team, and Enterprise plans. Claude for PowerPoint is an add-in that brings Claude into PowerPoint. Build decks from scratch, edit specific slides without regenerating everything, convert bullets into diagrams and native charts, and iterate on feedback while preserving template compliance. Claude for PowerPoint is currently in beta and available to Pro, Max, Team, and Enterprise plans. ## What you can do With Claude for PowerPoint, you can: * Build new slides using your existing client or corporate templates. * Make pinpoint edits to specific slides without regenerating entire decks. * Generate full deck structures from natural language descriptions. * Convert bullets into diagrams and native PowerPoint charts. * Pull external context through connectors. * Iterate on feedback while preserving formatting and template compliance. ## Get started with Claude for PowerPoint ### Supported versions Claude for PowerPoint runs on the following PowerPoint builds. * PowerPoint on the web * PowerPoint on Windows with a Microsoft 365 subscription, build 16.0.13127.20296 or later * PowerPoint on Mac, version 16.46 or later ### Install for yourself Go to the [Claude for PowerPoint listing on Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/office/WA200010001?tab=Overview). Select "Get it now" to install. Open PowerPoint, activate the add-in, and sign in with your Claude account. ### Deploy to your organization Organization admins can deploy Claude for PowerPoint through the Microsoft 365 Admin Center. In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go to Settings, Org Settings, User owned apps and services, and turn on ["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center). Go to Settings, Integrated apps, Add-ins. Search for "Claude by Anthropic for PowerPoint" in Microsoft AppSource. Assign the add-in to your organization or to specific users or groups. Share [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins) with your team for activation steps. After deployment, users can activate the Claude add-in from Tools, Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working. Organizations that have disabled "Let users access the Office Store" may find that admin-deployed add-ins don't appear for users. To work around this, deploy using the manifest XML file described below. ### Deploy with a custom manifest For IT administrators deploying to multiple users when the Office Store is disabled: Download the [custom manifest XML file](https://pivot.claude.ai/manifest-powerpoint.xml) and save it to a secure location. Go to [https://admin.microsoft.com](https://admin.microsoft.com), sign in, and open Settings, Integrated apps. Select "Upload custom apps", choose "Office Add-in", then "I have a manifest file on this device". Upload the manifest. Choose entire organization, specific users, specific groups, or just yourself for admin testing. Review settings and select "Deploy". The add-in is available within minutes. Full organization rollout can take up to 24 hours. After deployment, users see Claude in PowerPoint's Home ribbon and sign in with their Claude credentials on first use. ### Connect through a third-party platform If your organization routes AI traffic through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, your admin can deploy the add-in without individual Claude accounts. See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms). ## Key features ### Build from templates Start with a client or corporate template already loaded. Describe what you need, and Claude generates slides using the correct layouts, fonts, and colors from the slide master. Claude reads your deck's template and respects its formatting rules. Example prompts: * "Create a market sizing section, 3 slides covering TAM, SAM, SOM with supporting visuals." * "Add an executive summary slide using the one-column content layout." ### Edit existing slides Select a slide and tell Claude what to change. Claude makes edits while preserving formatting and surrounding context. Example prompts: * "Simplify the text on this slide." * "Add a chart showing the quarterly trend." * "Restructure the storyline across slides 4 to 7." ### Generate full decks Open a blank deck and describe your goal. Claude builds a draft with logical structure and professional defaults, which you can refine. Example prompts: * "Create a 10-slide deck walking through our market entry hypotheses." * "Build an internal project update presentation with timeline and next steps." ### Create native charts and diagrams Convert bullet points into professional visuals such as diagrams, process flows, or editable native PowerPoint charts. Claude produces visuals you can edit directly, not static images. Example prompts: * "Turn these bullets into a process flow diagram." * "Create a bar chart comparing Q1 to Q4 performance." ### Template awareness Claude reads the slide master, layouts, fonts, and color scheme in your deck and uses them when generating or editing slides. It aims to maintain template compliance without introducing off-brand elements. ## Connectors and Skills Claude for PowerPoint supports connectors for pulling external context into your deck, and Skills for applying reusable task recipes. See [Connectors and Skills](/docs/office-agents/connectors-and-skills) for details. ## Set persistent instructions Open Settings in the add-in sidebar and use the Instructions field to set preferences that apply to every conversation in PowerPoint. Instructions are useful for brand guidelines such as "always use one-line bullets" or "use the blue accent color for highlights", preferred slide structure, or recurring context about your workflow. Instructions you set in PowerPoint only apply to PowerPoint. They are separate from Instructions you set in Excel or Word. ## Work across M365 apps Claude for PowerPoint shares context with Claude for Excel, Word, and Outlook, so a single conversation can span your open deck, workbook, document, and inbox. See [Work across M365 apps](/docs/office-agents/work-across-apps). ## Context and session management The add-in handles long sessions for you so a single conversation can span an entire workflow. * **Auto-compaction**: longer conversations are automatically compacted into new conversations to avoid running out of context. See [Understanding usage and length limits](https://support.claude.com/en/articles/11647753-understanding-usage-and-length-limits). Your use of Claude for PowerPoint is associated with your existing Claude account and is subject to the same usage limits. ## Models available You can switch between Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6 when using the add-in. ## Data handling Inputs and outputs are deleted on the backend within 30 days of receipt or generation, except in cases outlined in [How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data). Data is cached for a number of hours after deletion so users can access context in recently closed presentations. Chat history is stored locally in your browser using IndexedDB. Conversations are not stored on Anthropic's servers, are not synced across devices, and can be cleared from Settings at any time. Claude for PowerPoint does not inherit custom data retention settings your organization might have set. Activity is not included in Enterprise audit logs or the Compliance API. ## Current limitations As a beta feature, Claude for PowerPoint is not recommended for: * Final client deliverables without human review. * Presentations containing highly sensitive or regulated data without proper controls. * Replacing your judgment on design and narrative flow. ### Unsupported versions The add-in does not run on these PowerPoint versions. * PowerPoint 2016 and 2019 perpetual or volume license. * PowerPoint on iPad. * PowerPoint on Android. * Older builds of Microsoft 365 PowerPoint below the SharedRuntime threshold. ## Prompt injection risk Only use Claude for PowerPoint with trusted files. Files from external sources can contain hidden instructions that manipulate the add-in into extracting data, modifying records, or performing destructive actions. External files such as downloaded templates, vendor files, collaborative documents, and data imports can contain prompt injections that try to trick Claude into taking unintended actions. Testing has identified scenarios where Claude for PowerPoint can be manipulated to extract sensitive information, modify critical data, or perform destructive actions if allowed to act without verification. When Claude proposes a risky operation, you are asked to confirm before it runs. Review confirmations carefully, especially for files from external sources. ## Best practices Follow these guidelines to use Claude for PowerPoint safely and effectively. * Always review changes before finalizing your work. * Start with your template already applied before asking Claude to generate content. * Be specific about what you want changed. Claude can target individual slides or elements. * Verify that outputs match your organization's brand guidelines. ## Example use cases ### Consulting deliverables Prompts that produce client-ready sections and summaries. * "Build a market sizing section with TAM, SAM, SOM slides." * "Create a competitive landscape slide comparing 4 players." * "Summarize these survey results." ### Iterative refinement Prompts that tighten or restructure an existing deck. * "Simplify the text on slide 3, it's too dense." * "Combine slides 5 and 6 into a single summary." * "Make the recommendations section more visual." ### Data visualization Prompts that turn raw data into native charts and diagrams. * "Convert these bullet points into a process flow." * "Create a bar chart from this data table." * "Add a pie chart showing market share breakdown." ### Deck restructuring Prompts that reorder or re-sequence slides. * "Reorder slides to lead with recommendations first." * "Add transition slides between each major section." * "Create an agenda slide that reflects the current structure." # Use Claude for M365 with third-party platforms Source: https://claude.com/docs/office-agents/third-party-platforms Deploy the Office add-ins through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, without individual Claude accounts. Organizations using Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway can deploy Claude's Office add-ins without requiring individual Claude accounts. The add-in connects through your organization's infrastructure, keeping prompts and responses within your trust boundary. ## Connection paths Four connection paths are available. Your IT admin selects one during deployment. End users see the same interface regardless. | Path | How it works | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | LLM gateway | Requests route through your gateway (LiteLLM, Portkey, Kong, and others) to your chosen provider. Matches the pattern used by Claude Code. | | Bedrock direct | The add-in authenticates via Microsoft Entra ID and calls Amazon Bedrock directly without intermediaries. | | Vertex AI direct | The add-in authenticates through Google OAuth and calls Vertex AI directly. | | Foundry direct | The add-in authenticates directly to your Azure AI Foundry resource using its API key. | ## Requirements by connection path All paths need: * Claude for Excel, PowerPoint, Word, or Outlook installed from Microsoft AppSource or via admin deployment. * Microsoft 365 with Entra ID for admin consent and token issuance. * For Outlook: Microsoft Graph admin consent for `Mail.ReadWrite`, `Calendars.Read`, `User.Read`, and `offline_access`, granted via Anthropic's app or your own Entra app registration. | Path | Additional requirements | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | LLM gateway | Gateway URL and API token from your IT team. | | Bedrock direct | AWS account with Claude model access enabled in target region. IAM OIDC identity provider and role configured to trust Microsoft Entra ID tokens. | | Vertex AI direct | Google Cloud project with Vertex AI API enabled and Claude model access. Google OAuth client configured with the add-in's redirect URI. | | Foundry direct | Azure AI Foundry resource with at least one Claude model deployed. Deployment names must use default model IDs (for example, `claude-opus-4-6`), not custom names. Resource API key from Azure Portal, your Foundry resource, Keys and Endpoint, KEY 1. | Your organization's IT team manages these resources. Anthropic cannot provide or reset credentials. ## Network allowlist The add-in requires access to specific domains. The required domains differ depending on whether your organization uses the Anthropic API directly (1P) or a third-party platform (3P). In all configurations, prompts and responses travel only to your chosen inference provider. Domains pointing to Anthropic (such as `pivot.claude.ai`) serve the add-in's interface, feature configuration, and operational telemetry, not prompt or response content. ### Anthropic API (1P) Use this table if your organization signs in with Claude accounts and inference goes to `api.anthropic.com`. | Domain | Required when | Purpose | | ------------------------------ | ------------------------- | ------------------------------------------------------------------------------------------ | | `pivot.claude.ai` | Always | Add-in host serving task pane UI, analytics, icon search, skill downloads, and telemetry. | | `claude.ai` | Always | Anthropic OAuth sign-in and feature-flag evaluation. | | `api.anthropic.com` | Always | Claude inference API, file uploads, code-execution containers, and MCP connector registry. | | `appsforoffice.microsoft.com` | Always | Microsoft Office.js runtime script (required by all Office add-ins). | | `login.microsoftonline.com` | If using Outlook | Microsoft Entra ID sign-in via Nested App Auth for the Graph token. | | `o1158394.ingest.us.sentry.io` | Optional | Crash and error reporting; blocking degrades diagnostics only. | | `mcp-proxy.anthropic.com` | If using MCP connectors | Proxy for MCP connector tool calls. | | `bridge.claudeusercontent.com` | If using work across apps | WebSocket bridge for the work-across-apps feature. | | `graph.microsoft.com` | If using Outlook | Microsoft Graph mailbox and calendar API. | ### Third-party platforms (3P) Use this table if your organization signs in with Microsoft Entra ID and inference goes to your LLM gateway, Bedrock, Vertex AI, or Azure AI Foundry. | Domain | Required when | Purpose | | ---------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------- | | `pivot.claude.ai` | Always | Add-in host serving task pane UI, analytics, and telemetry. | | `claude.ai/api/` | Always | Feature-flag evaluation without sign-in. | | `appsforoffice.microsoft.com` | Always | Microsoft Office.js runtime script. | | `login.microsoftonline.com` | Always | Microsoft Entra ID sign-in via Nested App Auth; reads admin config and issues tokens. | | `o1158394.ingest.us.sentry.io` | Optional | Crash and error reporting; blocking degrades diagnostics only. | | Your LLM gateway URL | If using LLM gateway | Organization's LLM gateway for inference. | | `sts.amazonaws.com` | If using Bedrock direct | AWS STS for exchanging Entra ID token for temporary Bedrock credentials. | | `bedrock-runtime..amazonaws.com` | If using Bedrock direct | Bedrock inference endpoint; replace `` with your configured AWS region. | | `accounts.google.com` | If using Vertex AI direct | Google OAuth consent screen. | | `oauth2.googleapis.com` | If using Vertex AI direct | Google OAuth token exchange and refresh. | | `aiplatform.googleapis.com` | If using Vertex AI direct | Vertex AI global inference endpoint. | | `-aiplatform.googleapis.com` | If using Vertex AI direct | Vertex AI regional inference endpoint; replace `` with your GCP region. | | `.services.ai.azure.com` | If using Foundry direct | Azure AI Foundry inference endpoint; replace `` with your resource name. | | `graph.microsoft.com` | If using Outlook | Microsoft Graph mailbox and calendar API. | ## Deploy the add-in for your organization Use the `claude-in-office` plugin to configure and deploy the add-in across your organization. The plugin provisions cloud resources (for Bedrock or Vertex AI direct), generates the add-in manifest, and obtains admin consent in a single guided flow. ### Run the setup wizard [Install the plugin](https://github.com/anthropics/financial-services-plugins/tree/main/claude-in-office) from the financial services marketplace, then run the setup wizard from inside Claude. Add the marketplace in your shell: ```bash theme={null} claude plugin marketplace add anthropics/financial-services-plugins ``` Install the plugin: ```bash theme={null} claude plugin install claude-in-office@financial-services-plugins ``` Then, from inside Claude, run the setup wizard: ``` /claude-in-office:setup ``` The wizard walks you through the path you chose: * **LLM gateway**: collects the gateway URL and token, determines the API format, generates the manifest, handles Azure admin consent. * **Bedrock direct**: creates the IAM OIDC identity provider and role, generates the manifest, handles Azure admin consent. * **Vertex AI direct**: walks through Google OAuth client creation, generates the manifest, handles Azure admin consent. * **Foundry direct**: captures `azure_resource_name` and `azure_api_key`, then generates the manifest. When complete, the add-in is ready for tenant-wide deployment. Bedrock and Vertex AI paths require Node.js for manifest generation and validation. The wizard checks for it and prompts installation if missing. ### Available commands The plugin exposes the following slash commands once installed. | Command | Function | | ------------------------------------- | --------------------------------------------------------------------------------------- | | `/claude-in-office:setup` | Interactive wizard: provisions cloud resources, handles admin consent, writes manifest. | | `/claude-in-office:manifest` | Generates a customized add-in manifest XML. | | `/claude-in-office:consent` | Generates the Azure admin-consent URL for the add-in's app registration. | | `/claude-in-office:update-user-attrs` | Writes per-user configuration via Microsoft Graph extension attributes. | ### What the wizard provisions The setup wizard creates resources in your cloud account based on the connection path you choose. | Path | Provisioned resources | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | LLM gateway | None. Collects your gateway URL and token, then generates the manifest. | | Bedrock direct | IAM OIDC identity provider trusting Microsoft Entra ID tokens, role with `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream` permissions, trust policy scoped to the Claude add-in's application ID. | | Vertex AI direct | Walks through creating a Google OAuth client in the GCP Console (not automatable via CLI), enables the Vertex AI API, captures client ID and secret for the manifest. | | Foundry direct | None. Collects resource name and API key for the manifest. | ### Per-user configuration If values vary per user, such as different gateway tokens or AWS roles for different teams, run `/claude-in-office:update-user-attrs` with per-user keys after initial setup to write configuration via Microsoft Graph extension attributes. ### Deploy to Outlook Outlook requires a separate manifest file from Excel, PowerPoint, and Word. Microsoft uses a different add-in schema for mail applications, so the two cannot be combined into one file. When you tell the setup wizard you are deploying to Outlook, it generates a second file named `manifest-outlook.xml` alongside `manifest.xml`. Upload each file as its own custom app in the steps below. Claude for Outlook reads mail and calendar data through Microsoft Graph, which requires a one-time tenant-wide grant from a Global Administrator regardless of which platform serves the model. Complete the [Microsoft Graph admin consent](/docs/office-agents/outlook#grant-microsoft-graph-consent) step before deployment so users are not prompted individually. The Graph token stays in the user's Outlook client and is never sent to your gateway or to Anthropic. If your organization's policy does not permit consenting to a third-party multi-tenant application, register your own single-tenant Entra application with the same delegated Graph permissions and provide its client ID to the setup wizard as `graph_client_id`. See [Use your own Entra app instead](/docs/office-agents/outlook#use-your-own-entra-app-instead). Amazon Bedrock is not currently supported for Claude for Outlook. Bedrock remains supported for Claude for Excel, PowerPoint, and Word. Claude for Outlook on third-party platforms currently supports Claude Opus 4.7 only. ### Deploy to Microsoft 365 After the wizard generates your manifest files: Open the Microsoft 365 Admin Center and go to Settings, Integrated apps, Upload custom apps. Select "Office Add-in" as the app type, then upload the `manifest.xml` file. If you are deploying Outlook, repeat this step with `manifest-outlook.xml` as a second custom app. If all users share the same configuration, select "Entire organization". If you wrote per-user attributes, assign to "Specific users/groups" matching exactly who was configured. Others would open the add-in with no configuration. Accept permissions and finish deployment. Propagation to users takes up to 24 hours, usually faster. The add-in appears under Tools, Add-ins on Mac or Home, Add-ins on Windows in Excel, PowerPoint, and Word once deployed. In Outlook it appears in the message ribbon when an email is open. Start with a pilot group to confirm functionality, then widen assignment. You can change assignment later without redeploying. ## Connection instructions for end users ### LLM gateway Open Excel, PowerPoint, Word, or Outlook and launch the Claude add-in. On the sign-in screen, select "Cloud provider or gateway". Then choose your connection: Gateway, Vertex, Bedrock, or Azure. Contact your IT team for connection details if you're unsure which one to select. For Gateway, enter the gateway URL (HTTPS base URL of your LLM proxy, for example `https://llm-gateway.example.com`) and the API token your IT team provided. By default the add-in sends the token in the `x-api-key` header with every request. If your admin set `gateway_auth_header: authorization` in the manifest, the add-in sends `Authorization: Bearer ` instead. The add-in checks the connection by sending a test request to the gateway. On success, you see the main add-in experience. Your credentials are stored locally in your browser's localStorage within the add-in's sandboxed iframe and are not synced to Anthropic's servers. Because the Office add-in runs in a sandboxed iframe within Microsoft applications, it cannot use your OS keychain the way Claude Code does. Only enter gateway-issued tokens, not raw cloud-provider credentials. ### Bedrock, Vertex AI, or Foundry direct Open Excel, PowerPoint, Word, or Outlook and launch the Claude add-in. For Bedrock (Excel, PowerPoint, and Word only), sign in with your Microsoft work account. The add-in uses your Entra ID token to assume the AWS role your admin configured, so no separate AWS credentials are needed. For Vertex AI, sign in with the Google account your admin authorized via the Google OAuth client created during setup. For Foundry, the add-in connects automatically if your admin pre-filled the Azure resource name and API key. Otherwise, enter the values your IT team provided and select Connect. The add-in reads the configuration your admin provisioned and connects to Bedrock, Vertex AI, or Foundry directly. If you see an error at sign-in, confirm with your IT team that your account is in the group assigned to the add-in. ### Change or update your gateway connection If your gateway API token expires or your IT team provides a new URL, go to Settings in the add-in sidebar, enter the new values, and select "Test Connection". This Settings section appears only for gateway connections. For Bedrock, Vertex AI, or Foundry direct, select Logout from the account menu and sign in again with your new credentials. ## Gateway requirements for IT teams The Office add-ins support the same three API formats as Claude Code. Set `gateway_api_format` in your add-in manifest to specify which format your gateway uses. ### CORS requirements The add-in's taskpane loads from `https://pivot.claude.ai`. Every request to your gateway is cross-origin, and the browser silently discards responses lacking CORS headers. Your gateway must return `Access-Control-Allow-Origin: https://pivot.claude.ai` (or `*`) on every response: GET, POST, OPTIONS, and all error responses. Setting it only on the OPTIONS preflight is insufficient. For the preflight, return `Access-Control-Allow-Headers` listing the request headers the add-in sends, such as `x-api-key, authorization, content-type, anthropic-version`. The `*` wildcard does not cover the `Authorization` header per the Fetch specification, so list it explicitly if you set `gateway_auth_header: authorization`. ### Required endpoints The endpoints your gateway must expose depend on which API format it speaks. **`gateway_api_format: anthropic` (default):** | Endpoint | Description | | ------------------- | ----------------------------------------------------------------------------- | | `POST /v1/messages` | Send messages to Claude; supports both streaming and non-streaming responses. | | `GET /v1/models` | List available models. | **`gateway_api_format: bedrock`:** | Endpoint | Description | | ---------------------------------------------------- | -------------------------------------------- | | `POST /model/{model-id}/invoke` | Send message and receive complete response. | | `POST /model/{model-id}/invoke-with-response-stream` | Send message and receive streaming response. | Native Bedrock `InvokeModel` pass-through. `gateway_url` must point at the pass-through prefix, for example `https://litellm.example.com/bedrock`. **`gateway_api_format: vertex`:** | Endpoint | Description | | ----------------------------------------------------------------------------------------------------- | -------------------------------------------- | | `POST /projects/{project}/locations/{region}/publishers/anthropic/models/{model-id}:rawPredict` | Send message and receive complete response. | | `POST /projects/{project}/locations/{region}/publishers/anthropic/models/{model-id}:streamRawPredict` | Send message and receive streaming response. | Native Vertex pass-through. `gateway_url` must include the API-version segment, for example `https://litellm.example.com/vertex_ai/v1`. Also requires `gcp_project_id` and `gcp_region` so the add-in can build the path. ### Required header For `anthropic` format, the gateway must forward the `anthropic-version` request header to the upstream provider. For `bedrock` and `vertex` formats, the SDK places `anthropic_version` in the request body instead. The gateway must preserve it there. Failure to forward the header or preserve the body field may result in reduced functionality or prevent the add-in from working. ### Authorization header The add-in can send your gateway's authorization token in either the `x-api-key` header or the `Authorization` header. The default is `x-api-key`. To switch to `Authorization: Bearer`, set `gateway_auth_header: authorization` in the manifest. ### Model discovery For gateways using `gateway_api_format: anthropic`, the add-in attempts to discover available Claude models via `GET /v1/models` on login. If your gateway doesn't expose a model list at that path, the add-in falls back to prompting the user for a model ID manually. For `gateway_api_format: bedrock` and `gateway_api_format: vertex`, the add-in uses a built-in model list and probes the gateway to verify each model is reachable, rather than calling `GET /v1/models`. ### Differences from Claude Code gateway setup If your team already runs Claude Code through a gateway, the table below summarizes how the Office add-in setup differs. | Aspect | Claude Code | Office add-ins | | ------------------ | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Credential storage | OS keychain or environment variables | Browser localStorage (sandboxed iframe) | | Auth configuration | Environment variables, settings file, helper scripts | Manual entry in add-in UI (gateway), Entra ID (Bedrock), Google OAuth (Vertex AI), or Azure API key (Foundry) | | Token refresh | Supports helper scripts for rotation | Manual re-entry in settings (gateway), automatic via Entra ID (Bedrock) or Google OAuth (Vertex AI) | | Custom model names | Configurable via environment variables | Not configurable in v1 | ## Example gateway configuration with LiteLLM LiteLLM PyPI versions 1.82.7 and 1.82.8 contained credential-stealing malware. Do not install those versions. If already installed, remove the package, rotate all credentials on affected systems, and follow remediation steps in [BerriAI/litellm#24518](https://github.com/BerriAI/litellm/issues/24518). LiteLLM is a third-party proxy service. Anthropic does not endorse, maintain, or audit LiteLLM's security or functionality. This section is informational and may become outdated. Use at your own discretion. The example configurations below route Office add-in requests through LiteLLM to Anthropic, Bedrock, Vertex AI, or Azure. ### Route to Anthropic directly Use this `config.yaml` to point the gateway at the Anthropic API. ```yaml theme={null} model_list: - model_name: claude-opus-4-7 litellm_params: model: claude-opus-4-7 api_key: os.environ/ANTHROPIC_API_KEY litellm_settings: drop_params: true ``` ### Route to Amazon Bedrock Use this `config.yaml` to route requests through Amazon Bedrock. ```yaml theme={null} model_list: - model_name: claude-opus-4-7 litellm_params: model: bedrock/us.anthropic.claude-opus-4-7 aws_region_name: us-east-1 litellm_settings: drop_params: true ``` ### Route to Google Cloud Vertex AI Use this `config.yaml` to route requests through Vertex AI. ```yaml theme={null} model_list: - model_name: claude-opus-4-7 litellm_params: model: vertex_ai/claude-opus-4-7 vertex_project: your-gcp-project-id vertex_location: us-east5 litellm_settings: drop_params: true ``` ### Route to Azure Use this `config.yaml` to route requests through Azure AI Foundry. ```yaml theme={null} model_list: - model_name: claude-opus-4-7 litellm_params: model: azure_ai/claude-opus-4-7 api_base: https://your-resource.services.ai.azure.com/anthropic api_key: os.environ/AZURE_API_KEY extra_headers: x-api-key: os.environ/AZURE_API_KEY litellm_settings: drop_params: true ``` For detailed setup instructions, see [LiteLLM's Anthropic format documentation](https://docs.litellm.ai/). ## What Anthropic collects Even when inference goes through your own infrastructure, the add-in communicates with `pivot.claude.ai` to load its interface and with `claude.ai/api/` to evaluate feature flags. These connections transmit operational telemetry such as which features are used, performance timings, and error rates, so Anthropic can maintain and improve the add-in experience. They do not transmit your prompts or Claude's responses. Anthropic collects information in accordance with Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Azure's terms, consistent with Anthropic's arrangements with customers. Anthropic does not have access to a customer's AWS, Google, or Microsoft instance, including prompts or outputs it contains. Anthropic does not train generative models with such content or use it for other purposes. Anthropic can access metadata such as tool use and token counts, and uses such metadata for analytic and product-improvement purposes. For details on what your organization's gateway or cloud provider logs, contact your IT team. To route a full audit trail, including prompts, tool inputs, tool outputs, and document references, to your own infrastructure, see [Configure a custom OpenTelemetry collector for Claude for M365](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents). ## Differences from signing in with a Claude account When you sign in with a Claude account, the add-ins connect directly to Anthropic. When you connect through a third-party platform, the add-ins send inference requests to your organization's infrastructure instead, and your IT team controls how that traffic is routed and logged. Some features that rely on a Claude account are not available through third-party platforms yet. Support is being added. | Feature | Claude account | Third-party platform | | ------------------------------------------------------------ | -------------- | ---------------------------------------------------------------------------------------------------------- | | Chat with your spreadsheet, deck, document, or email | Yes | Yes | | Read and edit cells, slides, formulas, and document text | Yes | Yes | | Read, search, and triage your mailbox and calendar (Outlook) | Yes | Yes, except Bedrock | | Connectors (S\&P, FactSet, and others) | Yes | Coming soon | | Working across apps | Yes | No | | Dictation | Yes | No | | Skills | Yes | Coming soon | | File uploads | Yes | No | | Web search | Yes | Vertex direct, Foundry direct, and gateways the add-in detects as routing to a Foundry-compatible upstream | | Code execution | Yes | Foundry direct, and gateways the add-in detects as routing to a Foundry-compatible upstream | If your team needs these features, talk to your Claude admin about which sign-in path fits your organization. ## Troubleshooting ### "Connection refused" or network error The gateway URL or cloud endpoint is unreachable from the user's network. Verify the URL is correct, the service is running, and there are no firewall or VPN restrictions blocking the connection. Check the [Network allowlist](#network-allowlist) to confirm all required domains are allowed. ### 401 Unauthorized or "Invalid token" The auth token is invalid or expired. For gateway connections, confirm the token with your IT team. For direct-cloud connections, verify the user's Entra ID account is in the assigned group and that the OIDC trust or OAuth client is configured correctly. For Foundry, regenerate the key in Azure Portal, Keys and Endpoint. ### 403 Forbidden or "Access denied" The token is valid but lacks the right permissions. For Bedrock, verify the IAM role has `bedrock:InvokeModel` permissions. For Vertex, verify your Google account has the Vertex AI User role on the project. For gateways, check the token's scope with your IT admin. For Foundry, check the resource's networking rules, or confirm the key belongs to the right resource. ### 404 Not found The add-in could not reach the expected API path. For gateways, verify the URL is the base URL such as `https://litellm.example.com:4000`. Don't include `/v1/messages` in the URL field. ### 500 or other server errors The gateway or cloud provider encountered an internal error. Check your gateway logs, such as `docker logs litellm` for LiteLLM, for upstream provider errors. Try the request again, and contact your IT admin if the issue persists. ### "No models available" The add-in could not find Claude models. For gateways using `gateway_api_format: anthropic`, your gateway may not expose a model list at `GET /v1/models`; your IT team can configure the gateway to serve a model list or give you a specific model ID to enter manually. For gateways using `gateway_api_format: bedrock` or `vertex`, none of the built-in models responded to the add-in's probe; confirm with your IT team that the gateway routes to a region or project with Claude models enabled. For Bedrock or Vertex direct, confirm that at least one Claude model (Claude Sonnet 4.5 or later) is enabled in your account and region. For Foundry, confirm at least one Claude model is deployed in the resource Model catalog. ### Streaming responses fail or hang Verify that your gateway supports Server-Sent Events (SSE) pass-through. Some proxy configurations strip or buffer SSE connections, which prevents streaming responses from reaching the add-in. ### A feature I expected is not available Connectors, Skills, file uploads, dictation, and working across apps are not available through third-party platforms yet. If you need these, ask your admin about signing in with a Claude account instead. # Use Claude for Word Source: https://claude.com/docs/office-agents/word A Word add-in that integrates Claude into your document workflow, for Pro, Max, Team, and Enterprise plans. Claude for Word is an add-in that brings Claude into Word. Ask questions about your document with clickable section citations, edit selected passages while preserving formatting, review counterparty redlines, work through comment threads, and fill templates in your document's styles. Claude for Word is currently in beta and available to Pro, Max, Team, and Enterprise plans. ## What you can do With Claude for Word, you can: * Ask questions about your document and get answers with clickable section citations. * Edit selected text while preserving surrounding styles, numbering, and formatting. * Use tracked changes mode so every edit lands as a revision you can accept or reject in Word's native review pane. * Have Claude work through comment threads, editing the anchored text and replying with what it changed. * Summarize counterparty redlines and flag the revisions worth pushing back on. * Fill templates with drafted content that inherits your document's heading and paragraph styles. * Find every provision touching a theme with semantic navigation, not just keyword search. ## Get started with Claude for Word ### Supported versions Claude for Word runs on the following Word builds. * Word on the web * Word on Windows with a Microsoft 365 subscription, Version 2205, build 15202.10000 or later * Word on Mac, version 16.61, build 22040100 or later ### Install for yourself Go to the [Claude for Word listing on Microsoft AppSource](https://marketplace.microsoft.com/en-us/product/office/WA200010453?tab=Overview). Select "Get it now" to install. Open Word, activate the add-in, and sign in with your Claude account. ### Deploy to your organization Organization admins can deploy Claude for Word through the Microsoft 365 Admin Center. In the [Microsoft 365 Admin Center](https://admin.microsoft.com), go to Settings, Org Settings, User owned apps and services, and turn on ["Let users access the Office Store"](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-addins-in-the-admin-center). Go to Settings, Integrated apps, Add-ins. Search for "Claude by Anthropic for Word" in Microsoft AppSource. Assign the add-in to your organization or to specific users or groups. Share [Microsoft's deployment guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-deployment-of-add-ins) with your team for activation steps. After deployment, users can activate the Claude add-in from Tools, Add-ins on Mac or Home, Add-ins on Windows, sign in, and start working. Organizations that have disabled "Let users access the Office Store" may find that admin-deployed add-ins don't appear for users. To work around this, deploy using the manifest XML file described below. ### Deploy with a custom manifest For IT administrators deploying to multiple users when the Office Store is disabled: Download the [custom manifest XML file](https://pivot.claude.ai/manifest-word.xml) and save it to a secure location. Go to [https://admin.microsoft.com](https://admin.microsoft.com), sign in, and open Settings, Integrated apps. Select "Upload custom apps", choose "Office Add-in", then "I have a manifest file on this device". Upload the manifest. Choose entire organization, specific users, specific groups, or just yourself for admin testing. Review settings and select "Deploy". The add-in is available within minutes. Full organization rollout can take up to 24 hours. After deployment, users see Claude in Word's Home ribbon and sign in with their Claude credentials on first use. ### Connect through a third-party platform If your organization routes AI traffic through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway, your admin can deploy the add-in without individual Claude accounts. See [Use Claude for M365 with third-party platforms](/docs/office-agents/third-party-platforms). ## Key features ### Read and understand documents Ask Claude questions about specific sections, clauses, or defined terms in your document. Claude provides answers with clickable citations that navigate directly to the referenced section. Claude recognizes common document patterns including multi-level legal numbering, defined terms, cross-references, and standard contract structures. Verify that outputs match your specific requirements and your firm's standard positions. Example prompts: * "What's the liability cap and is it mutual?" * "Summarize the key commercial terms in this agreement." * "What assumptions drive the revenue forecast in section 3?" ### Edit selected text Select a passage and tell Claude what to change. Claude edits only the selection while preserving surrounding styles, numbering, and formatting. New text inherits the paragraph style, font, and numbering of the surrounding content. Example prompts: * "Tighten this paragraph and drop the passive voice." * "Rewrite this clause to make the indemnification mutual." * "Simplify this section for a non-technical audience." ### Tracked changes mode When you enter tracked changes mode, Claude's edits land as tracked revisions. The original text is visible as a deletion and the new text as an insertion, all reviewable in Word's native review pane. Review every edit before accepting it, and undo with Word's standard Ctrl+Z on Windows or Cmd+Z on Mac if you want to revert. Example prompts: * "Rewrite section 4.2 to cap damages at 12 months of fees, and make it mutual." * "Draft a mutual indemnification clause after section 8." ### Comment-driven editing Claude reads comment threads in your document, understands what text each thread is anchored to, and can work through them one by one. For each comment, Claude edits the anchored passage and replies to the thread with a note explaining what it did. Example prompts: * "Work through my open comments." * "Address the comment on the liability section." ### Summarize counterparty redlines When a counterparty returns a document with tracked changes, Claude can read and summarize what they changed. Ask Claude to group changes by severity or flag the ones worth pushing back on. Example prompts: * "Summarize what the other side changed and flag anything that's worth discussing." * "Which of these redlines are dealbreakers?" ### Fill templates Draft sections in your document's heading and paragraph styles. Claude uses your template's formatting when generating content, so new headings, bullets, and table entries match what's already there. Tables populate in place without reflowing layout or changing column widths. Example prompts: * "Draft the Key Risks section with four risks in the template's style." * "Populate the summary table with revenue, gross margin, and net retention for the last three years." ### Semantic navigation Find every provision or passage in your document that touches a specific theme. Claude returns thematic matches, not just keyword hits, and each result navigates to the relevant location on click. Example prompts: * "Find every provision touching data retention." * "Where does this agreement address termination?" ## Connectors and Skills Claude for Word supports connectors for pulling external context into your document, and Skills for applying reusable task recipes. See [Connectors and Skills](/docs/office-agents/connectors-and-skills) for details. ## Set persistent instructions Open Settings in the add-in sidebar and use the Instructions field to set preferences that apply to every conversation in Word. Instructions are useful for tone and style conventions such as "use formal tone" or "follow APA citation style", document structure preferences, or recurring context about your workflow. Instructions you set in Word only apply to Word. They are separate from Instructions you set in Excel or PowerPoint. ## Work across M365 apps Claude for Word shares context with Claude for Excel, PowerPoint, and Outlook, so a single conversation can span your open document, workbook, deck, and inbox. See [Work across M365 apps](/docs/office-agents/work-across-apps). ## Context and session management The add-in handles long sessions for you so a single conversation can span an entire workflow. * **Auto-compaction**: longer conversations are automatically compacted into new conversations to avoid running out of context. See [Understanding usage and length limits](https://support.claude.com/en/articles/11647753-understanding-usage-and-length-limits). Your use of Claude for Word is associated with your existing Claude account and is subject to the same usage limits. ## Models available You can switch between Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6 when using the add-in. ## Data handling Inputs and outputs are deleted on the backend within 30 days of receipt or generation, except in cases outlined in [How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data). Data is cached for a number of hours after deletion so users can access context in recently closed documents. Chat history is stored locally in your browser using IndexedDB. Conversations are not stored on Anthropic's servers, are not synced across devices, and can be cleared from Settings at any time. Claude for Word does not inherit custom data retention settings your organization might have set. Activity is not included in Enterprise audit logs or the Compliance API. Claude reads the content of your currently open document, including text, comments, tracked changes, footnotes, tables, and bookmarks. It only accesses the document you have open in Word. For highly sensitive or regulated data, follow your organization's data handling policies. ## Current limitations As a beta feature, Claude for Word is not recommended for: * Final client deliverables or counterparty sends without human review. * Litigation filings or audit-critical documents without verification. * Replacing legal or financial judgment. * Documents containing highly sensitive or privileged data without proper controls. ### Unsupported versions The add-in does not run on these Word versions. * Word 2016 and 2019 perpetual or volume license. * Word on iPad. * Word on Android. * Microsoft 365 Word builds older than Version 2205 on Windows or version 16.61 on Mac. * Legacy `.doc` files. Save as `.docx` first. ## Prompt injection risk Only use Claude for Word with trusted documents. Documents from external sources such as downloaded templates, counterparty files, or files shared via email can contain hidden instructions that manipulate the add-in into extracting data, modifying records, or performing destructive actions. Prompt injection attacks hide malicious instructions in document content such as text, comments, tracked changes, headers, and footers to trick Claude into taking unintended actions. Testing has identified scenarios where Claude for Word can be manipulated to: * Extract and share sensitive information through web searches containing your sensitive data or file system access that exposes proprietary information. * Modify critical content such as contract terms or financial figures. * Perform destructive actions without verification when allowed to act unsupervised. When Claude proposes a risky operation, you are asked to confirm before it runs. Review confirmations carefully, especially for content from external sources. ## Best practices Follow these guidelines to use Claude for Word safely and effectively. * Always review tracked changes before accepting them. * Verify that outputs match your firm's playbook and standard positions. * Use appropriate permissions and access controls. * Maintain human oversight for client-facing work. ## Example use cases ### Legal contract review Prompts that review and revise contracts and counterparty redlines. * "Summarize the key commercial terms: parties, term, governing law, and anything off-market." * "Flag provisions that deviate from standard market position, ranked by severity." * "Make the indemnification mutual and insert our standard fallback language." * "Work through all five reviewer comments as tracked changes." * "What did the counterparty change, and which revisions are dealbreakers?" ### Finance memo drafting Prompts that build out investment memos and finance writeups. * "Draft the Investment Thesis section with three points, pulling the numbers from the uploaded 10-K." * "Populate the summary table with revenue, gross margin, and FCF for the last three years." * "Too generic on point two. Use the customer count from the deck." * "Address the partner's comment on the Risks section." ### Document QA and consistency Prompts that check a document for internal consistency and quality. * "Flag inconsistent defined terms and broken cross-references." * "Check the numbering scheme for gaps." * "Proofread for spelling, grammar, and punctuation." * "Is the same party referred to by different names anywhere in this document?" ### General document editing Prompts that tighten or restructure prose. * "Tighten section 4 and drop the passive voice." * "Rewrite this for a non-technical audience." * "Add a fourth risk addressing customer concentration." * "Define this term and use it consistently throughout." # Work across M365 apps Source: https://claude.com/docs/office-agents/work-across-apps Let Claude read from one Microsoft 365 app and make changes in another in a single conversation. Claude can coordinate between the Excel, PowerPoint, Word, and Outlook add-ins in your Microsoft 365 suite. Instead of switching between apps and re-providing context each time, Claude can read from one app and make changes in another. Working across apps is available when you sign in with your Claude account directly. It is not supported when connecting through Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway. ## Requirements Install each Claude for M365 add-in and confirm your plan before turning on cross-app mode. * A paid Claude plan: Pro, Max, Team, or Enterprise. * [Claude for Excel](/docs/office-agents/excel) installed from the Microsoft AppSource. * [Claude for PowerPoint](/docs/office-agents/powerpoint) installed from the Microsoft AppSource. * [Claude for Word](/docs/office-agents/word) installed from the Microsoft AppSource. * [Claude for Outlook](/docs/office-agents/outlook) installed from the Microsoft AppSource. ## Enable cross-app mode Install Claude for Excel, PowerPoint, Word, and Outlook from the Microsoft AppSource. Open each app and activate the add-in at least once before using cross-app features. Open Settings in each add-in and turn on "Let Claude work across files". Pro and Max plans have this on by default; Team and Enterprise plans default to off. The toggle is per-device, so enable it in every host you want to coordinate from. Once enabled, connected-app indicators appear in the sidebar when other Excel, PowerPoint, Word, or Outlook sessions are linked. ## How it works When you describe a task that involves multiple files or apps, Claude coordinates automatically: * Claude uses the Excel, PowerPoint, Word, and Outlook add-ins to read from and write to open files and email threads. * Context transfers between apps automatically, so you don't need to copy and paste information manually. You stay in one place while Claude does the switching. ## What you can do ### Read and write across open apps Claude can read data from an open Excel workbook, PowerPoint presentation, Word document, or Outlook email thread, and make changes to them directly. For example: * Pull numbers from an Excel model into a PowerPoint slide or a Word memo. * Update a chart in PowerPoint with the latest figures from Excel. * Read content from a presentation and use it to populate a spreadsheet. * Summarize a Word document into PowerPoint slides. * Draft a Word memo using data from an Excel workbook. * Open an attached letter of intent in Word with the Outlook thread already loaded as context. * Pull figures from an email thread into an open Excel model. ### Pass context between apps Claude carries relevant context forward when working across multiple files. If you've been building a financial model in Excel and ask Claude to create a summary deck or draft an investment memo, Claude already understands the model's structure and key outputs, so you don't need to re-explain. ## Skills work across apps Skills you've enabled in your Claude settings apply when Claude is working in Excel, PowerPoint, Word, or Outlook during a cross-app task. If you have a Skill that enforces your team's modeling conventions in Excel and another that matches your slide template in PowerPoint, Claude uses each one in the right app as it moves through the workflow. For more on Skills, see [Use Skills in Claude](https://support.claude.com/en/articles/12512180-use-skills-in-claude). ## Manage access as an admin Team and Enterprise organization owners can control whether team members can access this capability. Go to Organization settings, Office agents. Turn "Let Claude work across apps" on or off. Admins can also manage member access to the Claude for Excel, PowerPoint, Word, and Outlook add-ins through the Microsoft 365 Admin Center. ## Data handling Inputs and outputs are deleted from Anthropic's backend within 30 days of receipt or generation, except in cases outlined in [How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data). The Claude for M365 add-ins do not inherit custom data retention settings your organization may have set, and activity is not included in Enterprise audit logs, the Compliance API, or data exports. Chat history is stored locally in your browser, not on Anthropic's servers, and can be cleared from Settings at any time. ## Current limitations * Claude can only read from and write to files that are currently open in Excel, PowerPoint, or Word, and the email or event currently open in Outlook. * Claude cannot create, open, close, or switch files directly. The files and add-ins must be open with the feature turned on. ## Troubleshooting ### Claude doesn't see my open file Make sure the add-in is activated in the app (Tools, Add-ins on Mac or Home, Add-ins on Windows) and that working across apps is turned on in the add-in settings. ### Changes aren't appearing in the other app Claude works on open files in sequence. Wait for Claude to finish its current action, then check the target file. You may need to ask Claude to refresh or re-read the file. # Plugins overview Source: https://claude.com/docs/plugins/overview Extend Claude with reusable capability packages that bundle MCP connectors, skills, slash commands, and sub-agents Plugins are reusable capability packages that extend Claude with custom functionality. They bundle together [MCP connectors](/docs/connectors/overview), [skills](/docs/skills/overview), slash commands, and sub-agents into a single shareable unit — turning Claude into a specialist tailored to your role, team, and company. ## What plugins do Plugins let you define how you like work done, which tools and data to pull from, how to handle critical workflows, and what slash commands to expose so your team gets consistent outcomes. Every component is file-based, so plugins are easy to build, edit, and share. As your team builds and shares plugins, Claude becomes a cross-functional expert. Best practices get baked into every interaction, so leaders and admins can spend less time enforcing processes and more time improving them. ## Plugin directory To help you get started, Anthropic has open-sourced 11 plugins built and used internally: | Plugin | What it does | | ---------------------- | ------------------------------------------------------------- | | **Productivity** | Manage tasks, calendars, and daily workflows | | **Enterprise search** | Find information across your company's tools and docs | | **Sales** | Research prospects, prep deals, and follow your sales process | | **Finance** | Analyze financials, build models, and track key metrics | | **Data** | Query, visualize, and interpret datasets | | **Legal** | Review documents, flag risks, and track compliance | | **Marketing** | Draft content, plan campaigns, and manage launches | | **Customer support** | Triage issues, draft responses, and surface solutions | | **Product management** | Write specs, prioritize roadmaps, and track progress | | **Biology research** | Search literature, analyze results, and plan experiments | | **Plugin Create** | Create and customize new plugins from scratch | Browse the full collection at [claude.com/plugins](https://claude.com/plugins-for/cowork) or use the Plugin Create plugin to build your own. ## Origins in Claude Code Plugins originated in [Claude Code](https://code.claude.com/docs/en/plugins), where developers create and distribute them as versioned, shareable directories. A Claude Code plugin lives in a directory with a manifest (`plugin.json`) that defines its identity, version, and available components. For technical details on plugin structure, manifests, and configuration, see the [Claude Code plugins reference](https://code.claude.com/docs/en/plugins-reference). ## Plugins in Cowork Plugins are fully supported in [Cowork](https://support.claude.com/en/articles/13345190-getting-started-with-cowork), Anthropic's agentic workspace for complex, multi-step knowledge work. In Cowork, Claude runs inside an isolated virtual machine environment, executes tasks in parallel workstreams, and writes outputs directly to your file system — and plugins extend all of that capability. A sales plugin, for example, could connect Claude to your CRM and knowledge base, teach it your sales process, and give you slash commands for everything from prospect research to call follow-ups. You define what goes in the plugin once, and Claude pulls from that context whenever it's relevant. ## How plugins compose capabilities | Plugin component | What it adds | Example | | ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Skills** | Specialized instructions Claude follows when relevant tasks arise | A "brand voice" skill that activates when drafting external communications | | **MCP connectors** | Access to external tools and data | A connector to a CRM that lets Claude read and update deal records | | **Slash commands** | Explicit, user-triggered workflows | `/sales:prospect-research` to kick off a structured research workflow | | **Sub-agents** | Delegated workstreams that run in parallel | A sub-agent that handles competitive analysis while another drafts the proposal | ## Availability Plugin support in Cowork is available as a research preview for all paid Claude users. Plugins are currently saved locally to your machine. Org-wide sharing and management are coming in the weeks ahead. | Platform | Plugin support | | ----------------- | ------------------------------------------------------------------ | | **Claude Code** | Full plugin support — create, install, and use plugins | | **Claude Cowork** | Full plugin support — plugins extend agentic, multi-step workflows | Looking to submit your own plugin? See [Submitting your plugin](/docs/plugins/submit#submitting-your-plugin). ## Next steps Browse the full plugin collection. Build and distribute plugins in Claude Code. Learn how skills work as a core plugin component. Understand MCP connectors that plugins can bundle. # Submitting your plugin Source: https://claude.com/docs/plugins/submit Submit your plugin to the plugin directory for Cowork The [plugin directory](https://claude.com/plugins-for/cowork) is a community-driven directory where developers can submit plugins for use in Cowork and Claude Code. In Claude Code, this directory is surfaced as the official `claude-plugins-official` marketplace and is automatically available to all users — see [Discover and install plugins](https://code.claude.com/docs/en/discover-plugins#official-anthropic-marketplace). This is a separate and complementary directory from the [Connectors Directory](/docs/connectors/directory), which is specific to MCP connectors. ## Getting your plugin to users Once you've built a plugin, there are several ways to get it to users: 1. **Direct install** — You can install specific plugins yourself, or guide select users to install them. This is the simplest path for internal tools or small teams. 2. **Your own plugin marketplace** — You can serve your own [plugin marketplace](https://code.claude.com/docs/en/plugin-marketplaces), which allows a subset of opted-in users to access any plugin you share. This is a great fit for enterprise contexts or communities with shared tasks. See the [Claude Code docs on sharing a marketplace](https://code.claude.com/docs/en/plugin-marketplaces) for setup instructions. 3. **[Submit to the Claude plugin directory](#submitting-your-plugin)** — You can submit to the Claude plugin directory, which is made available to all users of Cowork and Claude Code. ## Plugin Directory: Community vs. Anthropic Verified Plugins are submitted by developers and creators in the community. Anthropic performs basic automated review on submissions before adding them to the directory. Plugins with an "Anthropic Verified" badge have undergone additional review from a quality and safety perspective. That said, there are limits to what Anthropic is able to review — you should only install plugins from developers you trust. There are no guarantees that any community plugin will become Anthropic Verified. Exercise caution when installing community plugins. Always review a plugin's permissions, connected services, and data access before use. ## What makes a good plugin The best plugins bundle related capabilities together into a coherent package that solves a specific job function or workflow end-to-end. Rather than exposing a single tool, a good plugin combines skills, connectors, slash commands, and sub-agents so Claude has everything it needs to handle a category of work. For example, a sales plugin might bundle a CRM connector, a skill that teaches Claude your sales process, slash commands for common tasks like prospect research and call follow-ups, and a sub-agent that handles competitive analysis in parallel. Together, these components make Claude a specialist — individually, they're just building blocks. Plugins can include any combination of: * **Skills** — Task-specific instructions that Claude activates dynamically based on context * **MCP connectors** — Connections to external tools and data sources. Plugins can contain any MCP, including remote MCPs, local MCPs, and MCPBs. The MCP configuration within a plugin is highly customizable. * **Slash commands** — User-invoked commands for triggering specific workflows * **Sub-agents** — Custom agent definitions for delegating complex work ### Guiding Claude through MCP setup Plugins can include a `SETUP.md` skill to guide Claude through configuring and connecting any MCP servers bundled in the plugin. This lets you define step-by-step setup instructions that Claude follows when a user installs or activates your plugin. ### Using safe MCP connectors in plugins While a plugin can include any MCP of any kind in its `.mcp.json` definition, we strongly encourage using connectors that already exist in the [Connectors Directory](/docs/connectors/directory) or come from well-known developers. This will increase the likelihood of verification and will reduce the number of warnings shown to users. ## Directory terms & conditions All plugins in the directory must comply with: * [Anthropic Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms) * [Anthropic Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy) ## Security Each plugin in the directory includes a link to where you can review its contents before installing. Plugins are capable of loading remote MCP servers, local MCP servers, and other local software tools to assist you in doing work. You should review any additional software that may be installed by a plugin, as community plugins may install unverified, third-party software that could be malicious or result in unintended behavior. Best practices when using community plugins: * Review the plugin's source code before installing * Check which MCP connectors are included and what permissions they request * Prefer Anthropic Verified plugins for production workflows * Report any suspicious activity to Anthropic ## Submitting your plugin To submit a plugin to the directory, you can either share a GitHub link or upload a zip file containing your plugin (with all folder structures inside). The repo must be public—closed-source plugins are not accepted. Before submitting, run `claude plugin validate` to check formatting and structure. Review times vary with queue volume. To submit please use one of our in-app submission forms: * **Claude.ai** — [https://claude.ai/settings/plugins/submit](https://claude.ai/settings/plugins/submit) * **Console** — [https://platform.claude.com/plugins/submit](https://platform.claude.com/plugins/submit) After your plugin is published, updates pushed to your GitHub repo are picked up automatically—CI mirrors changes to the public marketplace and runs automated screening on each update. You do not need to re-submit the form for updates. Need help building your plugin? See the [Claude Code plugin guide](https://code.claude.com/docs/en/plugins) for a complete walkthrough of plugin structure, manifests, and testing, or the [plugins reference](https://code.claude.com/docs/en/plugins-reference) for full technical specifications. # Creating custom skills Source: https://claude.com/docs/skills/how-to Learn how to create, structure, and test your own custom skills Custom skills extend Claude with specialized knowledge and workflows. This guide explains how to create, structure, and test your own skills. Skills can range from simple instruction sets to multi-file packages with executable code. Effective skills: * Solve a specific, repeatable task * Have clear instructions Claude can follow * Include examples when helpful * Define when they should be used * Focus on one workflow rather than trying to do everything Skills follow the [Agent Skills specification](https://agentskills.io/specification) — see the specification for more in-depth information. ## Directory structure A skill is a directory containing at minimum a `SKILL.md` file: ``` brand-guidelines/ ├── SKILL.md ├── scripts/ # Optional: executable code ├── references/ # Optional: additional documentation └── assets/ # Optional: templates, images, data files ``` The directory name must match the `name` field in your `SKILL.md`. ## Creating a `SKILL.md` file The `SKILL.md` file must start with YAML frontmatter containing required metadata, followed by markdown instructions. ### Required fields ```markdown SKILL.md theme={null} --- name: brand-guidelines description: Apply Acme Corp brand guidelines to presentations and documents, including official colors, fonts, and logo usage. --- ``` **name**: Lowercase letters, numbers, and hyphens only. Maximum 64 characters. Must match the directory name. **description**: Explains what the skill does and when to use it. Claude uses this to determine when to invoke your skill. Claude.ai limits descriptions to **200 characters**. The [Agent Skills specification](https://agentskills.io/specification) allows up to 1024 characters, but skills uploaded to Claude.ai must use the shorter limit. ### Markdown body After the frontmatter, write markdown instructions for Claude. Include: * Step-by-step procedures * Examples of inputs and outputs * Templates or formatting requirements * Edge cases to handle Keep your main `SKILL.md` under 500 lines. Move detailed reference material to separate files. ### Complete example ```markdown SKILL.md theme={null} --- name: brand-guidelines description: Apply Acme Corp brand guidelines to presentations and documents, including official colors, fonts, and logo usage. --- # Brand Guidelines Apply these standards when creating presentations, documents, or marketing materials for Acme Corp. ## Brand colors - Primary: #FF6B35 (Coral) - Secondary: #004E89 (Navy Blue) - Accent: #F7B801 (Gold) - Neutral: #2E2E2E (Charcoal) ## Typography - Headers: Montserrat Bold - Body text: Open Sans Regular - Size guidelines: H1 32pt, H2 24pt, Body 11pt ## Logo usage Use the full-color logo on light backgrounds, white logo on dark backgrounds. Maintain minimum spacing of 0.5 inches around the logo. ## When to apply Apply these guidelines when creating: - PowerPoint presentations - Word documents for external sharing - Marketing materials - Reports for clients See the [assets/](assets/) folder for logo files and font downloads. ``` ## Adding resources For content too detailed for `SKILL.md`, add files to your skill directory: * **`references/`**: Additional documentation Claude can read when needed * **`assets/`**: Templates, images, lookup tables, schemas * **`scripts/`**: Executable code (see below) Reference these files in `SKILL.md` so Claude knows when to load them. Keep files focused—smaller files mean less context usage. ## Adding scripts Skills can include executable code in Python, JavaScript/Node.js, or Bash. Place scripts in the `scripts/` directory. Claude can install packages from standard repositories (PyPI, npm) when loading skills. Declare dependencies in your frontmatter: ```markdown SKILL.md theme={null} --- name: data-analysis description: Analyze CSV files and generate visualizations. dependencies: python>=3.8, pandas>=1.5.0, matplotlib --- ``` ## Packaging your skill To upload a skill to Claude: 1. Ensure the directory name matches your skill's `name` field 2. Create a ZIP file containing the skill directory **Correct structure:** ``` my-skill.zip └── my-skill/ ├── SKILL.md └── scripts/ ``` **Incorrect structure:** ``` my-skill.zip ├── SKILL.md # files directly in ZIP root └── scripts/ ``` ## Testing your skill ### Before uploading 1. Review `SKILL.md` for clarity 2. Verify the description accurately reflects when Claude should use the skill 3. Check that all referenced files exist 4. Validate using `skills-ref validate ./my-skill` ([validation tool](https://github.com/agentskills/agentskills/tree/main/skills-ref)) ### After uploading 1. Enable the skill in **Settings > Capabilities** 2. Try prompts that should trigger it 3. Review Claude's thinking to confirm it's loading the skill 4. Iterate on the description if Claude isn't using it when expected ## Best practices **Keep it focused**: Create separate skills for different workflows. Multiple focused skills compose better than one large skill. **Write clear descriptions**: Be specific about when the skill applies. Include keywords that help Claude identify relevant tasks. **Start simple**: Begin with markdown instructions before adding scripts. **Use examples**: Include example inputs and outputs to help Claude understand what success looks like. **Test incrementally**: Test after each significant change. **Leverage composability**: Claude can use multiple skills together automatically. ## Security considerations * Don't hardcode sensitive information (API keys, passwords) * Review any downloaded skills before enabling them * Use MCP connections for external service access ## Example skills See [github.com/anthropics/skills](https://github.com/anthropics/skills/tree/main/skills) for example skills you can use as templates. # Skills overview Source: https://claude.com/docs/skills/overview Extend Claude's capabilities with specialized instructions and workflows Skills are directories containing instructions, scripts, and resources that Claude dynamically loads to handle specific tasks. Each skill has a `SKILL.md` file that defines when it should be activated and what instructions Claude should follow. ## Availability Skills are available for users on Pro, Max, Team, and Enterprise plans. The Skills feature requires code execution to be enabled. ## How skills work Skills use progressive disclosure to manage context efficiently: 1. **Metadata loading**: Claude reads skill names and descriptions at startup (\~100 tokens each) 2. **Activation**: When a task matches a skill's description, Claude loads the full `SKILL.md` content 3. **Resource loading**: Additional files (scripts, references) are loaded only when needed This approach prevents context window overload while providing specialized capabilities on demand. ## Types of skills * **Anthropic skills**: Pre-built skills for document creation (Excel, Word, PowerPoint, PDF) that activate automatically when relevant. * **Partner skills**: Skills from partners like Notion, Figma, and Atlassian designed for seamless MCP connector integration. * **Organization-provisioned skills**: Skills deployed organization-wide by Team and Enterprise administrators. * **Custom skills**: Skills you create for specialized workflows—generating emails, applying brand guidelines, integrating with tools like JIRA or Linear, and more! ## Skills vs. other features | Feature | Purpose | | -------------------------------- | --------------------------------------------------------------------------------- | | **Skills** | Task-specific procedures that load dynamically | | **[Plugins](/docs/plugins/overview)** | Shareable packages that bundle skills, connectors, slash commands, and sub-agents | | **Projects** | Static background knowledge always loaded in specific chats | | **MCP** | Connects Claude to external services | | **Custom Instructions** | Broad preferences applied to all conversations | ## Open standard Skills follow the [Agent Skills specification](https://agentskills.io/specification), a platform-agnostic standard. Skills you create can work across any platform adopting the standard. See [Creating custom skills](/docs/skills/how-to) to learn how to build your own, or bundle skills into [plugins](/docs/plugins/overview) to share them with your team.