Plugins, Connectors & MCP — Interactive Explainer

🔌 What Is a Plugin?

By default, Claude Cowork sees only what's in the conversation and the folder you've connected. A Plugin opens a single, controlled door — Claude can now read your SOPs in Drive, post a status to the IRT Safety Slack channel, query the datalake for case data, or look up a Pax / Dax / Mex in D365.

Plugin is Cowork's friendlier name for an MCP server — Model Context Protocol. The AI industry's adopted standard for "how does an AI tool talk to a business system." If you've heard the term MCP from your tech team, the Plugin marketplace inside Cowork is the same idea — pre-packaged, pre-vetted, with the technical wiring already done.

🍳

The kitchen analogy continues. If a Skill is a recipe and Project Instructions are the house rules, a Plugin is a piece of kitchen equipment — the oven, the fridge, the espresso machine. Each one extends what your team can cook. Your IT team installs them. You just open the door and use what's inside.

🤝 Your Team Handles the Plumbing — You Use the Result

This is the most important framing for GS Cyborg buildership. Plugins are an IT/admin concern. Configuring an MCP server, OAuth scopes, network policy, and credentials is a technical job. Using a Plugin is a GS Support concern. Once it's installed, you just say "check Drive for new invoices" — the same way you tell a new agent to "go look up the SOP in Glean."

📁

Google Drive / SharePoint

Read the latest SOP corpus. Pull the QA audit guidelines. Find the case-handling decision tree.

💬

Slack / Teams

Post the AP exception list to #ap-review every Monday. Notify the credit committee on a HIGH risk flag.

☁️

AWS

Query live Bedrock pricing in Singapore. Check S3 for the overnight reconciliation file. Read the latest CloudWatch metric.

🗄️

Databases & Internal APIs

Look up a vendor in your ERP. Read live FX rates from Treasury. Check transaction status in PayLater.

💡

Why this is the unlock for agentic workflows. Without Plugins, Claude can only work with whatever you paste into the conversation. With Plugins, Claude can fetch data when needed and act when authorised. That's the leap from "smart assistant on my desk" to "team member who can see the same systems I can." Every workflow pattern from earlier today — chaining, parallel, routing, orchestration — only really comes alive once Plugins are in place.

🎯 The Three Things a Plugin Adds to Claude

When IT installs a Plugin, three new capabilities appear inside your Cowork project. You don't see them as a list — you just notice Claude can now do things it couldn't before.

Capability	What it means	Finance example
Tools	Specific actions Claude can take — read a file, send a message, query an API	Drive Plugin adds `read_file`, `list_files`, `search_drive`. Slack Plugin adds `post_message`.
Resources	Live data the Plugin can pull on demand — not pre-loaded into the conversation	The latest vendor master CSV from your ERP. Today's FX rates. The current GST schedule.
Prompt templates	Suggested ways to use this Plugin — almost like built-in mini-Skills	"Summarise these IRT cases for stakeholder briefing." The Plugin author has pre-written it for you.

⚠️

Plugins are how Claude becomes risky. A Plugin can read sensitive data and (in some cases) write to systems. This is exactly why your IT team — not you — installs them. The 3-layer auth model (next section) is what keeps this safe. Read it before you start asking IT to enable connectors for your team.

🛣️ Three Ways a Plugin Reaches Your Cowork Project

If you open Cowork → Customize → Plugins & Connectors, you'll see three different routes. They look similar but represent very different trust and ownership models. Knowing which is which matters when you're asking your IT team for access.

Path 1

🛒

Cowork Plugin Marketplace

Who sets it up Anthropic curates the catalogue; your org admin (or your IT team) approves which plugins your account can install.
When to use The first place to look for any common capability — Drive, Slack, GitHub, Notion, Linear, Asana, Box. Pre-vetted, no IT build cost.
Trust level Highest — code reviewed by Anthropic + your org admin.

Finance example Browse Marketplace → install "Google Drive" → GTS confirms scopes → you mount the SOP / KB shared drive into your project.

Path 2

🔧

Custom MCP Server

Who sets it up Your internal IT/Data team builds it (or wraps an existing internal API). They publish a server endpoint and authentication recipe; you "+ Add server" in Cowork settings.
When to use When you need to reach an internal system that's not in the Marketplace — your ERP, your in-house pricing engine, the proprietary FX feed.
Trust level You own it. Security is your IT team's responsibility, just like any internal tool.

Finance example GTS / GSTF builds a "D365 Case Lookup MCP" wrapping the case's REST API. You add the server endpoint once; from then on, Claude can look up any vendor by code.

Path 3

🔗

Connectors (OAuth)

Who sets it up Anthropic hosts the MCP server itself; you authorise it with your own credentials via an OAuth pop-up. No infrastructure for IT to deploy.
When to use When the system you need is on the official Connectors list — Microsoft 365, Box, AWS Knowledge, AWS MCP, Asana, Atlassian, GitHub, etc. Fastest path to "it just works."
Trust level High — Anthropic-hosted, OAuth-scoped to your account, revocable in one click.

Finance example Click "AWS MCP" → OAuth flow → instructor's AWS account connected → Claude can now query Bedrock, S3, CloudWatch directly. (This is the live demo on the next tab.)

🧭

How to choose between the three. Start at Path 1 (Marketplace) — most common needs are already there. If your system is on the Connectors list (Microsoft 365, AWS, Box, GitHub), Path 3 is fastest because there's nothing for IT to host. Only fall back to Path 2 (Custom MCP) when the system you need is internal-only and unlikely to ever be in a public marketplace.

📋 Side-by-Side Comparison

Aspect	🛒 Marketplace Plugin	🔧 Custom MCP Server	🔗 OAuth Connector
Catalog source	Anthropic-curated marketplace	Your internal teams or third-party vendors	Anthropic's hosted Connectors list
Where it runs	Plugin server published by author	On your infrastructure (or vendor's)	Anthropic-hosted
Set-up effort	One-click install (after admin approval)	IT build + deploy + maintain	OAuth pop-up — under 60 seconds
Authentication	Varies — usually OAuth or token	Whatever your IT chose (OAuth, API key, mTLS)	Always OAuth — scoped to your account
Best for	Common SaaS tools your team already uses	Internal-only systems (ERP, pricing engine, data warehouse)	Anything on the supported Connectors list
Org-managed?	Yes — admin can pre-install with 🔒	Yes — IT chooses what to publish internally	Often yes — admin can pre-approve
Finance example	Slack, Drive, Box, GitHub, Notion	D365 Case Lookup, Datalake SQL, Slack escalation channel	Microsoft 365, AWS MCP, AWS Knowledge, Atlassian, Asana

🔒

The lock icon you'll see in settings. If your org admin has pre-deployed a plugin or connector for the whole organisation, it appears with a 🔒 in your Cowork plugin list. You can use it but you can't remove it. That's how AnyCompany Finance can guarantee that, say, the "Approved Vendor Master" Plugin is always available to every CoE analyst — not optional, not tamperable.

🔐 The 3-Layer Auth Model — The Biggest Teaching Moment of Day 2

This is where most people — including senior IT folks — get tripped up the first time. A Plugin appearing in your Cowork settings does not mean Claude can use it yet. There are three independent layers, and all three must be on for the Plugin to actually work in a project.

The good news: once you understand the model, the troubleshooting flowchart is two steps long ("which layer is off?"). The bad news: most participants in your team will skip Layer 2 and conclude "the AI doesn't work."

1
Install Account-wide · One-timeThe Plugin or Connector exists in your Cowork account. It shows up in Customize → Plugins & Connectors. This is the IT/admin step — Marketplace install, custom server registration, or Connector OAuth.
Once installed, it's available to every project in your account — but not necessarily turned on yet.
2
Activate Per-project · The step everyone missesOpen the project. Toggle the Plugin on for this specific project. Until you do, Claude cannot see it — even though it's clearly in your account list. This is by design: you don't want every Plugin loaded into every conversation. Most participants in the workshop will see "I installed it but Claude says it doesn't have the tool" — this is the layer to check.
Where to look: top-right of the project, the Plugins panel — toggles per project. Some Connectors auto-activate on first use; many don't.
3
Authenticate Credentials · Sometimes per-sessionProvide credentials to the upstream system. The form depends on the connector type: an OAuth pop-up (Drive, Slack, AWS MCP), AWS access keys + region (some AWS plugins), an API token (custom internal MCP), or — for fully internal servers — nothing extra because they trust the network. Some OAuth tokens expire and require periodic re-auth.
If a Plugin is installed and activated but you're getting "permission denied" or "no access" errors, it's almost always Layer 3 — the credentials expired, the OAuth scope is too narrow, or the AWS profile is missing.

🎯

Layer 2 is the silent failure mode. In the workshop, the single most common participant error will be: "I installed the AWS Connector. Claude says it can't query Bedrock." The cause, 9 times out of 10, is that the Connector is in their account list (Layer 1 ✅) but not toggled on for this project (Layer 2 ❌). Train your team to check Layer 2 first. If unsure: ask Claude "what tools do you have available?" If your Plugin's tools aren't in the answer, it's a Layer 2 problem.

🩺 Symptom-to-Layer Diagnostic

When something doesn't work, walk down this table. The order matters — Layer 1 → Layer 2 → Layer 3.

Symptom	Likely layer	Fix
"I don't see the Plugin anywhere in Cowork."	Layer 1 — Install	Browse Marketplace and install, or ask IT to add it. For OAuth Connectors, click Connect in the Connectors panel.
"It's in my account list, but Claude says 'I don't have a tool for that.'"	Layer 2 — Activate	Open the project's Plugins panel and toggle the Plugin on for this project. Refresh the conversation.
"Claude tries the tool but gets 'unauthorized' or 'no permission'."	Layer 3 — Authenticate	Re-run the OAuth flow, refresh the AWS credentials, or check that your account has the required upstream scope (e.g. AP shared drive read access).
"Some queries work, others get 'access denied' for specific files."	Layer 3 — Scope	OAuth scopes are correctly granted but the upstream system (Drive, SharePoint) restricts the file. This is your IAM problem, not Cowork's.
"Worked yesterday, broken today, no settings changed."	Layer 3 — Token expiry	OAuth tokens or AWS session credentials have expired. Re-authenticate. Build a habit: check Layer 3 first thing on Monday morning.

🧰

The "show me your tools" debug trick. If you suspect a Plugin isn't loaded, ask Claude directly: "What tools do you have available right now?" Claude will list them by name. If your expected tool isn't there, it's Layer 1 or 2. If it's listed but failing, it's Layer 3. This single question replaces 80% of the diagnostic conversation.

🧬 Cowork & Claude Code — Two Different Plugin Ecosystems

Your IT team almost certainly knows about Claude Code — Anthropic's CLI tool for developers. It also has Plugins, Skills, and MCP. This causes a real surprise the first time GS Cyborg builders compare notes with engineering: "My developer told me to install plugin X, but I can't find it in Cowork."

The two products share the underlying MCP protocol — they speak the same language to upstream systems. But they have separate plugin marketplaces and separate installed lists. Installing a Plugin in one does not install it in the other.

🖥️ Cowork (this workshop)

Desktop app · for GS Support finance & business usersamp; Cyborg builders

Where Plugins live	Cowork Marketplace + your account
Install path	UI: Customize → Plugins & Connectors → Browse / Add server / Connect
OAuth Connectors	Anthropic-hosted (Microsoft 365, AWS, Box, GitHub, Atlassian, Asana…)
Custom MCP	"+ Add server" Blank option — paste server URL + auth
Where state is stored	Your Anthropic account — follows you across machines
Org admin controls	Org-managed plugins appear with 🔒 — pre-installed, not removable
Audience	Knowledge workers — GS Ops, TQM, WFM, Strategy

⌨️ Claude Code (your IT team's tool)

CLI / IDE · for developers

Where Plugins live	Claude Code's own marketplace + local config
Install path	CLI: `/plugin install <name>` or `claude mcp add`
OAuth Connectors	Subset overlaps with Cowork — auth flows are CLI-driven
Custom MCP	Edit `~/.claude/plugins/` + `mcp.json` by hand
Where state is stored	Local machine — `~/.claude/`
Org admin controls	Provisioned via dotfiles, repos, or enterprise MDM
Audience	Developers — code, infra, automation

🪤

The trap that came up in our own pilot session. An IT team member ran /plugin install aws-mcp in Claude Code, confirmed it worked at the CLI, then was surprised when GS Support users couldn't see it in Cowork. They are two different installs. To make AWS MCP available to GS Support users, the same Connector has to be enabled in Cowork — either via OAuth per-user, or as an org-managed pre-install.

🤝 What Cowork & Claude Code Genuinely Share

It's not all bad news. The pieces that do transfer between the two tools are the conceptual ones — the same vocabulary, the same auth model, often the same MCP server endpoints behind the scenes.

Concept	Same in both?	What that means
MCP protocol	✅ Identical	An MCP server your IT team builds works for both Cowork and Claude Code clients. Build once, reach both audiences.
3-layer auth model	✅ Identical	Install → Activate → Authenticate applies in both. Same diagnostics, same fixes.
Tools / Resources / Prompts model	✅ Identical	Same three capability types appear; same invocation pattern.
Skills	≈ Conceptually same	Same anatomy (name + description + body). Cowork stores per account; Claude Code stores in `~/.claude/skills/`.
Marketplace catalog	❌ Separate	Don't expect cross-availability. Verify each plugin in each tool's catalogue.
Installed plugins list	❌ Separate	Installing in Claude Code does not make it available in Cowork (or vice-versa).
Org-managed lock 🔒	≈ Both support, different mechanism	Cowork: admin pushes via account. Claude Code: pushed via dotfiles / managed config.

🎓

Working talking-point for IT meetings. "We need the same MCP server to be reachable from both Cowork (GS Support users) and Claude Code (developers). One server, two clients. The auth model is identical, but the install lists are separate — please make sure both surfaces are provisioned." This sentence saves about three back-and-forth emails.

🎬 Live Demo — Connecting AWS MCP to Claude Cowork

This is the demo that makes Plugins concrete in front of the room. The exact flow we discovered in the pilot session: from "Cowork can only see what you paste" to "Claude is querying live AWS Bedrock pricing for Singapore" — in under three minutes. The whole demo runs in the instructor's Cowork window; the room watches.

🎯

Why AWS MCP for the demo. Three reasons. (1) The room — GS Cyborg builders — recognises AWS as "the cloud our infra runs on." (2) The Bedrock pricing question is one they'd actually ask. (3) The Singapore inference profile reality (Claude 4.x is cross-region only) is a non-trivial fact that's easy to dismiss in slides — but uncontestable when the model itself surfaces it from the live AWS data.

Step-by-Step

1

Open Cowork → Customize → Plugins & Connectors

From the workshop-leader Cowork window. Show the room three sections: Plugins (Marketplace), Connectors (OAuth-based), and Add custom server. Point to all three so the participants can locate them later.

2

Choose "AWS MCP" from the Connectors list

Scroll to the AWS MCP entry — described as "AWS knowledge, regional availability, AWS CLI commands, and infrastructure scripts." Click Connect. Note out loud: this is Layer 1 — Install.

3

Complete the OAuth flow

The pop-up walks you through AWS sign-in (or in our demo, an instructor sandbox account is already pre-authorised). Note: this is Layer 3 — Authenticate happening at install time. AWS MCP doesn't have a separate per-project Layer 2 toggle in the current UI — it's auto-active once connected.

4

Confirm the new tools — show the room

In a fresh conversation, type the diagnostic prompt:

What AWS tools do you have available right now? List them by name.

Claude will list the ten AWS MCP tools. Read the names aloud — they're the alphabet of what Claude can now do for you in AWS:

call_aws get_presigned_url get_regional_availability list_regions read_documentation recommend retrieve_skill run_script search_documentation get_tasks

"Ten tools, no code written. Yesterday Claude could only read what I pasted. Today it can run AWS CLI, search AWS docs, check regional availability — and the auth was a single OAuth click."

5

Run the headline demo prompt

The marquee question — GS-relevant, Singapore-specific, requires Claude to actually call AWS:

Use the AWS pricing tools to fetch current Bedrock pricing for Claude Opus 4.7 in ap-southeast-1. Show input, output, cache write 5-min, cache write 1-hour, and cache read prices in USD per million tokens. Note any regional caveats Singapore users should be aware of.

Claude will run call_aws and search_documentation live. Expect it to surface the pricing table from our cheat sheet — but with today's data, not pre-baked content. The pricing should come back at $5 input / $25 output / $0.50 cache read per 1M tokens. Caveat — Singapore is cross-region.

6

Land the Singapore reality

The crucial GS / compliance moment. Highlight Claude's response and read this aloud:

🇸🇬

Singapore reality check. Claude 4.x is not available for direct in-region inference in ap-southeast-1. Every call routes via cross-region inference profiles like global.anthropic.claude-opus-4-7. Opus 4.7 is hosted in N. Virginia, Tokyo, Ireland, and Stockholm. Pricing is at the source-region rate, with no surcharge — but for data-residency-sensitive GS workloads, this is the kind of fact that has to come from GTS / GSTF review, not a slide. Now imagine asking the AI this question yourself, instead of waiting two weeks for an architecture review email.

7

Wrap — connect to what they'll build

Close with one sentence: "This is what your IT team will install for the GS Support team — but instead of Bedrock pricing, the Plugin will read invoices from your Drive, post exception summaries to Slack, and write to your reconciliation log." That's the bridge to the afternoon hands-on exercise.

⏱️

Demo timing. 8–10 minutes total: 2 minutes on the install paths recap, 1 minute on Connectors UI, 1 minute on the OAuth flow, 2 minutes on tool list + diagnostic prompt, 3 minutes on the Bedrock pricing query and Singapore caveat, 1 minute closing bridge.

🛟 Demo Backup Prompts (if AWS Connector Is Unavailable)

If the OAuth flow fails on the day, or AWS MCP is rate-limited, fall back to one of these prompts. They still demonstrate the "Plugin in action" idea, but use a different connector.

Backup A — Microsoft 365 Connector

List the last 5 documents I've edited in OneDrive. For each, show the title, last edited date, and a one-sentence summary.

Backup B — Box / Drive (when mounted as a project folder)

Look at the SOPs folder. How many SOP articles are there, what are the most recently updated ones, and which ones reference deprecated procedures?

Backup C — "Diagnose your tools" generic

Show me every Plugin and Connector you currently have access to in this project. For each, list the tools by name and explain in one sentence what kind of GS task (case handling, SOP lookup, escalation) it would unlock.

📎

The diagnostic prompt is the hidden star. Even if everything else fails, "show me your tools" is a fascinating moment for the room — they realise Claude can introspect its own capabilities. That alone often justifies the segment.

🛤️ Workshop Recommendation — Two-Track Format

Our 28-person AnyCompany Finance cohort is mixed: ~3 leadership, ~12 finance solutions / citizen developers / tech & data, ~3 process owners, and the rest spread across FP&A, Controllership, Audit, Tax, Treasury, and Reporting. A single "everyone installs the connector themselves" segment overwhelms half the room and bores the other half. A single instructor demo leaves the technical participants without hands-on time on the one tool they're most curious about.

The fix: split tracks for this segment, then merge again for the afternoon hands-on. Total time spent is the same as a single track — but every participant lands in the right zone.

👁️ Track A — Watch the Demo Everyone · 10 min

For: Leadership, Process Owners, FP&A, Audit, Tax, Treasury

Instructor runs the live AWS MCP demo from Section 5 in their Cowork window
Room watches the OAuth flow, the new tools appearing, the live Bedrock pricing query
Singapore inference profile reality is surfaced from real AWS data — not slides
Closing bridge: "Your IT team installs these. You use what's installed."
Outcome: Every participant leaves with a working mental model of how Plugins reach Cowork

🛠️ Track B — Try It Yourself Citizen Devs + Tech · 15 min

For: Finance Solutions Excellence (Citizen Devs), Tech & Data team (~12 participants)

Run alongside Track A — these participants stay at their machines after the demo
Each opens their own Cowork → Connectors → installs the AWS MCP Connector
Runs the same diagnostic + Bedrock pricing prompt locally on their own credentials
Bonus: each tries one of the backup prompts (Microsoft 365 or Box) on their own data
Outcome: Track B participants leave with the AWS Connector active in their Cowork — they can replay the pattern next week without instructor support

🤝

Why this split is the right call for this audience. The 12 Citizen Devs and Tech & Data members are exactly the people who'll champion plugins inside AnyCompany Finance after the workshop — they need to leave having actually done it once. The 16 others are the ones who'll request plugins from IT — they need to leave understanding what they're asking for, not having configured it themselves. Two needs, one segment, well served.

🎬 Running the Two Tracks Smoothly — Instructor Notes

1. Pre-flight (before the workshop day): Confirm with IT that the AWS MCP Connector is enabled on the Cowork tenant for Citizen Devs + Tech & Data. If org-managed pre-install (🔒) is set, even better — Track B doesn't have to wait on per-person approvals.
2. Set Track B expectations early: When you start the segment, name the split: "If you're in Citizen Devs, Tech & Data — open Cowork now and follow along. Everyone else — sit back, watch, and ask questions." This avoids the awkward "wait, am I supposed to be doing this?" middle ground.
3. Keep one co-instructor floating: Track B will hit Layer 2 confusion — guaranteed. Have a co-instructor (or AWS SA) walking the back of the room, ready to point at the per-project toggle. Time-box troubleshooting to 90 seconds — if it's still broken, hand the participant a fallback ("watch the front, you'll get it set up at lunch").
4. Re-merge for the afternoon: The afternoon Build-First-Agent exercise does not require AWS MCP — it uses a local invoice folder. So Track B's extra capability is bonus, not gate. Both tracks rejoin seamlessly at 13:30.
5. Watch for the OAuth pop-up blocker: On corporate-managed Windows/Mac, the OAuth window can be blocked silently. If a Track B participant's "Connect" button does nothing visible, ask them to check pop-up permissions — single most common ground-zero issue in connector demos.

🚀 Where This Slots Into Day 2

This explainer is the bridge between the conceptual morning and the hands-on afternoon.

When	Module	What it does for this page
Morning · Module 9	Automation Stack	Establishes the four layers: Project Instructions + Skills + Scheduled Tasks + Plugins/MCP
Morning · Module 10	Skills Deep-Dive	Goes deep on the Skills layer — anatomy, lifecycle, finance examples
Late morning · Module 11	This page — Plugins, Connectors & MCP	Goes deep on the Plugins layer — three install paths, 3-layer auth, AWS demo
Afternoon · Hands-on	Build First Agent	Participants build a working agent — the Skill is theirs to write; the Plugins are mostly already installed by IT
Reference	Agentic Cheat Sheet	Per-day reference — verified Bedrock pricing, when-to-use-what, 3-file collaboration pattern

🎯

What every participant should leave this segment knowing — even if they remember nothing else. (1) A Plugin is a controlled door from Claude to a business system, installed by IT. (2) There are three install paths — Marketplace, Custom MCP, OAuth Connectors — and they each suit a different use case. (3) Three layers must all be on for a Plugin to work — Install, Activate (per-project, easy to miss), Authenticate. (4) Claude Cowork and Claude Code share the protocol but not the marketplace — install separately for each. That's it. The rest is depth they can return to via this page after the workshop.