Managing Uploaded Knowledge & Connectors.

A Project's knowledge is whatever it draws on beyond the base model, and a business user configuring one is really doing two different jobs. The first is curating static knowledge: files uploaded directly, indexed and retrieved on demand, a snapshot that only changes when someone re-uploads it. The second is managing live connectors: links to external systems, Google Drive, Gmail, Google Calendar, and other apps through Anthropic's Connectors directory, built on the Model Context Protocol (MCP), that let Claude read current, real-time state rather than a snapshot from whenever it was uploaded.

Both feed the same conversation, but they fail differently. A stale upload gives a wrong answer until someone notices and re-uploads it, a predictable, self-contained failure. A connector's accuracy depends on two things at once: the connected account's actual current state, and the permission scope granted when it was enabled, an over-broad grant is a live, ongoing exposure, not a one-time mistake that surfaces once and gets fixed.

Uploads are the simpler half and are covered in depth on the Projects page, click "+" on the project's knowledge panel, upload a document, and Claude retrieves the relevant portion at query time via RAG once the knowledge base grows large, automatically, on every plan. See Study Next for the full mechanics; this page focuses on the connector half.

Connectors are discovered and enabled through Anthropic's Connectors directory, a one-click browsing experience at claude.ai's directory built on MCP, where a user clicks "Connect" to authenticate a remote service or "Install" for a desktop extension. Individually, a user toggles a connector on or off inside a chat via the "+" menu's Connectors option. For Team and Enterprise plans, an Owner or Primary Owner must first enable a connector at the organization level, under Organization settings, before individual members can use it at all, an individual employee cannot unilaterally enable an org-managed connector for themselves.

Per-connector capability is asymmetric, and the exam tests knowing the specific asymmetry, not just "connectors are live." The Gmail connector can search, read, and summarize email, and create drafts, but sending is disabled at the platform level: every email must still be sent manually from the actual Gmail account, and attachment content is unavailable, only metadata. The Google Calendar connector, by contrast, has real write power: it can create, update, and delete events, manage attendee lists, respond to invitations, and set up recurring meetings, deleting an event triggers an automatic cancellation notice to attendees. The Google Drive connector reads text content from supported file types (images embedded in documents are not processed) and, when code execution is enabled, can also save Claude-generated files back to Drive. Across every connector, Claude Help Center guidance is explicit: each action Claude takes on the user's behalf requires the user's explicit approval before it executes, this matters most for Calendar since creating, updating, and deleting events are real, externally visible actions, not just reads.

Governance runs on the same access-scoping principle regardless of which connector: Claude only accesses connected data when a specific question or action requires it, and retrieves the minimum information needed for that request, rather than pulling everything available up front. But scope still has to be set correctly at grant time, granting full mailbox access when only calendar visibility was needed is a governance gap even though it may work fine that day, the exam trap is treating "the connector exists and is enabled" as sufficient, when the actual objective is scoping and periodically reviewing what each connector was granted.