MCP setup for Balsam CoE

Playbooks in the CoE repo are designed to be run in your Claude chat. They work better when your Claude can reach out to the systems where Balsam context actually lives — the CoE repo, Atlassian, Granola. Those outbound connections are called MCP servers.

This page walks you through connecting the three MCPs that matter for CoE work right now, gives you a one-line check for each, and documents the pre-flight pattern playbooks use to stay useful even when you haven’t set any of this up.

What MCP is

Think of an MCP server as a skill plug-in for your Claude chat. Without MCPs, Claude only knows what you paste into the conversation. With an MCP connected, Claude can actively fetch — read a CoE intake file, search a Confluence page, pull a Granola transcript — without you having to copy-paste.

You connect MCPs inside your Claude chat’s settings. Each one is a separate, per-user thing: connecting Granola for yourself doesn’t connect it for anyone else. Goose Group can’t connect them for you.

Every CoE playbook is written to degrade gracefully without any MCPs. If you’re unconnected, the playbook will ask you to paste the links or IDs it would otherwise fetch. You won’t be blocked — you’ll just do a bit more copy-paste.

The three MCPs that matter for CoE right now

CoE repo MCP — mcp.coe.goosegroup.co

What it does: Lets a playbook read the CoE’s own content — cohorts, workflows, intake files, resources, prior ideas, research. This is what makes “find near-duplicate ideas before filing a new one” possible without asking you to search GitHub by hand.

Setup: The CoE repo MCP is being built (see issue #8). Setup instructions — including the Claude config snippet and token-request flow — will land on this page when #8 ships.

Verify it worked (once available): ask your Claude chat something like “via the CoE MCP, list the current cohorts” — if it comes back with the product-data cohort, you’re connected.

Atlassian MCP — Jira + Confluence

What it does: Lets a playbook check whether Balsam engineering has already scoped something in Jira, or whether a Confluence page already documents the topic. This is your own Balsam SSO-gated connection — Goose Group doesn’t provide it, and we don’t have access to your tickets through it.

Setup: Atlassian publishes the current instructions at developer.atlassian.com. You’ll authenticate with your Balsam SSO.

Verify it worked: ask your Claude chat “via Atlassian, search Jira for tickets about [something you know exists]” — if it returns a ticket list, you’re connected.

Granola MCP

What it does: Lets a playbook pull past call transcripts — so when you say “this came up with Priscilla last week,” the playbook can find the transcript itself instead of asking you to paste it.

Setup: Granola publishes setup instructions in-app and at granola.ai. You’ll authenticate with your Granola account.

Verify it worked: ask your Claude chat “via Granola, list my meetings from last week” — if it returns a list of calls, you’re connected.

When you don’t have them

You don’t need any of these to get value from CoE playbooks. The only cost of not having them is that the playbook will ask you to paste things it would otherwise fetch — a Granola link instead of pulling the transcript directly, a Jira ticket URL instead of searching. You’ll get the same output; it just takes a few more copy-pastes.

If a playbook ever hard-requires an MCP — refuses to proceed without one — that’s a bug in the playbook. Every playbook should have a degraded path.

Pre-flight pattern (for playbook authors)

If you’re writing or running a playbook, this is the canonical pre-flight. Paste the shape into your playbook’s opening, adapted for the playbook’s needs. The goal: check what’s connected, tell the user what that means, and never block on a missing MCP.

Before I dig in, quick check — which MCPs do you have connected? I can ground this more thoroughly the more of these you have:

  • CoE repo MCP (mcp.coe.goosegroup.co) — lets me read the CoE’s cohorts, intakes, resources, workflows, existing ideas.
  • Atlassian MCP (your Jira + Confluence) — lets me check if anyone at Balsam has already worked on this.
  • Granola MCP — lets me find past call transcripts on the same topic.

If you don’t have any of these, that’s fine — just tell me what you know and we can paste things as we go. If you’d like to connect them first, see the MCP setup guide.

Rules for playbook authors:

  • Ask once, near the top. Don’t re-ask later in the playbook.
  • Tailor the list to what the playbook actually needs. A content-production playbook probably doesn’t need Jira; say so.
  • When an MCP the playbook expected isn’t present, ask the user to paste the equivalent (a link, an ID, a summary). Don’t stop.
  • Flag any gap the conversation couldn’t fill in the final artifact — e.g., under “Open questions” in a GitHub issue — so follow-up can close the loop.
  • Never hard-require a specific MCP. If the playbook can only work with one connected, that’s a design bug.