# Managing Uploaded Knowledge & Connectors > A Project's knowledge splits into two mechanisms that behave differently: uploads are a static snapshot a user manually maintains, and connectors are live links to external systems (Google Drive, Gmail, Calendar) built on MCP. Connectors are not one uniform capability - Gmail can only search, read, and draft (never send), while Calendar can create, update, and delete events outright, so the governance question is per-connector scope, not "is this connector on." Every connector action still requires the user's explicit approval before it executes - Calendar writes and deletes are not silent. **Domain:** CCAOF-D5 · Configuration & Knowledge Management (12% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/managing-knowledge-connectors **Last reviewed:** 2026-05-04 ## Quick stats - **Connector types covered:** 3 (Drive, Gmail, Calendar) - **Exam domain:** CCAOF-D5 - **Domain weight:** 12% - **Gmail send capability:** None, draft only - **Calendar destructive actions:** Delete + RSVP ## What it is 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. ## How it works 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. ## Where you'll see it in production ### Q3 Vendor Review Project Vendor contracts are uploaded as static project knowledge (retrieved by clause on demand), while the Gmail connector pulls the latest vendor correspondence live and the Drive connector references a shared scorecard spreadsheet that changes weekly, each source managed and revoked independently. ### Scheduling assistant built on the Calendar connector Creates, updates, and RSVPs to meetings on a user's behalf within that user's own existing calendar permissions, the two-gate model (org enables, user authenticates) bounds what it can touch even though Calendar's own capability includes real deletion. ## Comparison | Connector | Can read / search | Can create or modify | Can delete | What it explicitly cannot do | | --- | --- | --- | --- | --- | | Gmail | Search and read email (metadata only for attachments) | Create drafts | No | Send email, no matter what's confirmed in chat | | Google Calendar | View events and availability | Create, update, RSVP, set recurring meetings | Yes, with automatic cancellation notices | Nothing structurally, this is the most action-capable of the three | | Google Drive | Read text content of supported files | Save Claude-generated files back to Drive (requires code execution enabled) | No | Process images embedded inside documents | ## Decision tree 1. **Does the underlying source change over time (a mailbox, a shared calendar, a live spreadsheet)?** - **Yes:** Use a live connector so Claude sees current state, not a snapshot from upload time. - **No:** A one-time upload as project knowledge is simpler to manage and just as accurate. 2. **Is this connector being enabled for a Team or Enterprise organization rather than an individual account?** - **Yes:** An Owner or Primary Owner must enable it at the organization level first, under Organization settings, before any member can use it. - **No:** An individual user can toggle it on directly in chat via the '+' > Connectors menu. 3. **Could this connector, once enabled, take a destructive or externally visible action (e.g. deleting an event, sending on someone's behalf)?** - **Yes:** Verify the actual capability before assuming, Calendar can delete and notify attendees; Gmail cannot send under any configuration, review the specific connector's real permission surface, not an assumption. Either way, that action still requires the user's explicit approval before Claude executes it. - **No:** Lower-risk read/draft-only connectors like Gmail still need scope review, but carry no destructive-action exposure. 4. **Was this connector's permission scope reviewed after it was first granted?** - **Yes:** Low governance risk, scope matches current need. - **No:** Re-review it, an unreviewed, over-broad grant (e.g. full mailbox access when only calendar was needed) is a live governance gap even if nothing has gone wrong yet. ## Exam-pattern questions ### Q1. A user asks Claude, via the Gmail connector, to reply to a client email and send it. What actually happens? Claude drafts the reply but cannot send it, the connector is restricted to search, read, and draft creation; every email must be sent manually from the actual Gmail account regardless of what the user confirms in chat. The distractor "Claude sends the email automatically once the user confirms in chat" describes a capability the Gmail connector does not have, sending is disabled at the platform level, not gated behind a confirmation step. ### Q2. A scheduling assistant built on the Google Calendar connector is asked to cancel a recurring meeting series and notify all attendees. Can the connector do this, and does it happen automatically? Yes, it can, Calendar supports creating, updating, and deleting events, including automatic cancellation notices to attendees, this is real write and delete power, not read-only access. But it does not happen silently: Claude Help Center guidance states every connector action requires the user's explicit approval before it executes, so the user still confirms the deletion before it goes through. The distractor "Calendar connector, like Gmail, can only read or draft, not actually modify anything" incorrectly assumes uniform connector capability, Calendar and Gmail have genuinely different permission surfaces. ### Q3. An Enterprise org wants every department to have access to the Google Drive connector. What has to happen before any individual employee can use it? An Owner or Primary Owner must first enable the connector at the organization level, under Organization settings, before individual members can turn it on for themselves. The distractor "any individual employee can enable it for themselves without admin involvement" describes the individual-account flow, which does not apply once a connector is being rolled out org-wide on Team or Enterprise. ### Q4. Six months ago, an admin granted a connector full mailbox access when only calendar visibility was actually needed, and no one has revisited it since. What is the governance lesson this objective tests? Permission scope has to be set to the minimum needed and periodically reviewed, an over-broad, unreviewed grant is a live governance risk on its own, independent of whether anything has gone wrong with it yet. The distractor "once a connector is enabled it's a purely technical detail, not something governance needs to revisit" is exactly the assumption this objective is designed to catch, knowing a connector exists is not the same as knowing its scope is still appropriate. ### Q5. A PM needs Claude to reference a vendor scorecard spreadsheet in Google Drive that gets updated weekly by another team. Should they upload it once as project knowledge, or connect Drive live? Connect Drive live. A one-time upload is a static snapshot that goes stale the moment the spreadsheet changes, and would need to be manually re-uploaded every week to stay accurate; a live connector reflects the sheet's current state on every query. The distractor "upload the spreadsheet once as project knowledge since it's simpler to manage" optimizes for setup simplicity while accepting weekly-stale answers, the wrong tradeoff for data that changes on a schedule. ## FAQ ### Q1. Can Claude send emails on my behalf through the Gmail connector? No. Gmail is restricted to search, read, and draft creation, sending is disabled at the platform level, every email must still be sent manually from the actual Gmail account. ### Q2. Is a connector's data automatically more current than an upload, with nothing else to manage? It's more current, but not maintenance-free. Freshness depends on the connected account's real state, and accuracy also depends on the permission scope granted at setup, an over-broad or unreviewed scope is a governance risk that exists independently of how fresh the data is. ### Q3. If Claude has Calendar connector access, can it delete or modify events without the user noticing? No. Claude Help Center guidance is explicit that every connector action requires the user's explicit approval before it executes, this applies to all connectors, but matters most for Calendar since create, update, and delete are real, externally visible actions rather than reads. --- **Source:** https://claudearchitectcertification.com/concepts/managing-knowledge-connectors **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.