How to Build a Shared AI Skill Library With MCP

Customer-service teams rarely have a knowledge problem. They have a distribution problem.

The exception for a delayed order lives in one person’s notes. The wording that defuses a billing question lives in another person’s chat history. A third person has built a useful AI prompt—or a skill—on their own machine. All three may be good at their jobs, but the team is running three versions of the playbook.

This article uses skill to mean a small, reusable playbook for an AI assistant: clear instructions for one recurring task. It is usually written in Markdown (opens in a new tab), a plain-text format with headings and lists. Different AI products package skills differently. The operational idea is the same: give the assistant the right guidance only when it is useful.

That works for one person. It is not yet a shared capability for a team.

What a team needs is a canonical skill library: one approved copy of each playbook, available to every authorised person when their AI assistant needs it. “Canonical” simply means the copy everyone trusts. Think of a reference shelf in a library, not ten different photocopies of the same handbook.

This is a deliberately smaller version of the architecture we follow at Typenode. A production system needs more controls than I will cover here. But this v1 is useful enough to test the working habit, and simple enough for a Head of AI or Customer Service to reason about without becoming an infrastructure project.

First, name the parts

Good systems become easier to discuss when the nouns are clear. These are the terms I will use:

The distinction between contributor and reviewer is important. If every person can silently rewrite the shared playbook, the library drifts. If only one central team can suggest improvements, it goes stale. A lightweight proposal-and-review step gives you contribution without losing control.

MCP is the librarian, not the library

MCP means Model Context Protocol (opens in a new tab). It is a common language that lets an AI client ask an outside service to do a defined job.

In this design, MCP is not where skills live. It is the librarian. Its job is to answer two questions:

1. What approved playbooks are available to this person?
2. Please bring me the full text of this one playbook.

An MCP service exposes small, named actions—called tools—with a description of what each action expects and returns. For this v1, start with just two:

list_skills()
  → returns the name and one-line purpose of skills this person may use

get_skill(skill_name)
  → returns the full Markdown guidance for one approved skill

This is a design choice, not a technical limitation. Do not make every playbook its own MCP tool. If the team has 60 skills, the assistant would see 60 tool names before it has started the customer’s task. That is like handing a representative the whole policy catalogue whenever the phone rings.

Instead, treat list_skills as the catalogue card and get_skill as the book. The assistant sees short descriptions first and opens only the relevant guide. This follows the same progressive disclosure principle used by Claude skills: show the smallest useful amount first, then load the detailed instruction when it fits the task. Anthropic documents this behaviour for Claude skills. (opens in a new tab)

The smallest useful architecture

You need four building blocks, not a new knowledge-management product.

1. Skill storage. Keep each full Markdown playbook in one place. Cloudflare R2 (opens in a new tab) is a practical object store—a durable digital filing cabinet for the long documents.
2. A skill registry. Keep the name, short description, owner, version, and review status in a database. Supabase (opens in a new tab) can hold this catalogue of what exists and who may manage it.
3. The MCP connector. A small Cloudflare Worker (opens in a new tab) checks who is asking, reads the approved catalogue, and serves list_skills and get_skill.
4. A review signal. When someone proposes a change, Slack (opens in a new tab) can alert the reviewer. Slack is where a person notices the work; the approval record still belongs in the registry.

flowchart LR
accTitle: The read path for a shared AI skill library
accDescr: A support representative uses an AI client. The client asks an MCP connector for a skill, and the connector reads the approved catalogue in Supabase and the full skill text in Cloudflare R2.
Representative[Support representative] --> Client[AI client]
Client --> Connector[MCP connector]
Connector --> Registry[Supabase skill registry]
Connector --> Storage[Cloudflare R2 skill bodies]

The diagram hides a useful separation:

• The skill body is the long playbook.
• The registry is the catalogue card: title, owner, version, status, and access rules.
• The connector combines the two only when an authorised AI client asks for a skill.

That separation is what keeps the system manageable. You can improve one playbook without asking every representative to reinstall a file. The next task can retrieve the current approved version. A conversation that already loaded an older version still has that older text in its context, so tell the AI client to retrieve a fresh skill at the start of a new task or after it resumes.

A concrete example: delayed-order replies

Do not begin with a library of 100 generic prompts. Choose one recurring support situation where correct process matters.

For example, a delayed-order-reply skill might include:

• when to use it;
• the checks the assistant should make before drafting a reply;
• the order in which to explain a delay;
• phrases to avoid promising;
• the point at which the case must go to a human; and
• a short example of a good reply.

The registry entry for that skill might say:

name: delayed-order-reply
purpose: Explain a late order without making unsupported delivery promises.
owner: Head of Customer Service
status: approved
version: 3

The full body belongs in storage. The short record belongs in the registry. list_skills returns the short record. get_skill("delayed-order-reply") returns the full playbook only when the assistant is working on that kind of customer question.

That is enough structure to make the library searchable, reviewable, and safe to change.

Build the publishing path before the browsing path

The reading path is simple: a representative asks Claude for help; Claude sees the available skills, chooses the relevant one, then retrieves the current playbook.

The publishing path is where a shared system becomes useful.

Start with this sequence:

1. A contributor spots a recurring issue and drafts a playbook in plain language with an AI assistant.
2. They submit it as a proposal; it is not live yet.
3. A reviewer checks the process owner, wording, escalation boundary, and examples.
4. Approval publishes a new version to the canonical library.
5. The next eligible request can discover that version through the connector.

flowchart TD
accTitle: The publishing lifecycle for a shared AI skill
accDescr: A contributor drafts a skill and submits it for review. An approved skill is published to the registry and the skill store, where the MCP connector can retrieve it.
Contributor --> Draft
Draft --> Proposal
Proposal --> Review
Review --> Approved
Approved --> Registry[Supabase skill registry]
Approved --> Storage[Cloudflare R2 skill bodies]

For a v1, the proposal can be a simple internal form, a protected workspace, or a small front end over Supabase. You can later build a visual authoring surface—perhaps with Lovable reading from the same Supabase registry—when people truly need a queue, ownership view, or release history.

Do not make a new interface the price of contributing knowledge. The important part is the publication rule: drafts are proposed; only approved versions are discoverable.

“The library should be invisible when the right guidance exists, and obvious when someone needs to improve it.” — Bartosz Mróz

Claude-first, not Claude-only

Claude is a useful place to start because many teams already know it. But the library should belong to the company, not to one chat interface.

The connector speaks MCP and the library stores ordinary Markdown. That means the same core library can work with another compatible AI client. Claude, ChatGPT, Codex, and Cursor are examples of clients with MCP-related capabilities, but this is not a promise that one configuration works everywhere. Each client must support the connector’s transport—the way it connects over a local process or the web—and its authentication method—the way it proves who the user is.

Treat the client as the reading surface. Treat the library as the durable asset. Before connecting a second client, test three things:

1. Can it connect to the chosen MCP service?
2. Can it sign in using the identity approach you need?
3. Does it receive only the tools and skills appropriate to that user?

That small discipline prevents a “Claude-only” pilot from becoming a Claude-only knowledge system.

This pattern already exists in more complete forms

The v1 above is not a theory waiting for a market to appear. It is a simplified version of patterns already visible in public product architecture.

Among public examples, Cloudflare’s enterprise AI-agent workspace reference architecture (opens in a new tab) is the closest match. It describes a centrally published, read-only, versioned library of skills and organisational context; an agent lists and loads skills on demand; and a separate MCP portal controls access to enterprise tools.

Cloudflare’s version goes much further than a support team needs for its first build: model governance, per-team tool policies, audit records, credential isolation, and a persistent workspace. That is precisely the point. It shows the direction of travel without pretending the first useful version needs every production control on day one.

Vercel provides a useful adjacent example: it describes skills and live platform knowledge as one concern, while its MCP server handles actions on a user’s account. The lesson is not “copy Vercel.” It is to keep guidance and actions as separate parts of the design.

The four controls that make a v1 safe enough to test

This is not a full security architecture. It still needs four non-negotiable controls.

1. Authentication. The connector must know who is connecting before it returns a skill.
2. Roles. Contributors may propose; reviewers may approve; representatives may read approved guidance. These are different permissions.
3. Approved-only discovery. list_skills must not reveal draft or rejected content to ordinary representatives.
4. No secrets in playbooks. A skill explains a process. It must not contain passwords, API keys, or customer data.

MCP can support an authentication flow, but it does not choose your organisation’s permissions for you. Your connector and surrounding systems must decide who can propose, approve, and read. That is the difference between connecting an AI client to a document folder and operating a trustworthy shared capability.

A six-step build sequence

If you want to test this without overwhelming the team, work in this order:

1. Choose one recurring support workflow with a clear process owner.
2. Write three to five playbooks, not 50.
3. Define the contributor, reviewer, and reader roles before writing code.
4. Put approved Markdown bodies in R2 and their records in Supabase.
5. Expose only list_skills and get_skill through an authenticated MCP connector.
6. Run a real support week, then inspect which skills were used, where the guidance was unclear, and what deserves a new version.

Do not start with automated publishing, broad write permissions, or a complex dashboard. First prove that the team contributes useful guidance, reviewers can keep it current, and representatives actually retrieve it while working.

When to build it yourself—and when to stop

Build the v1 yourself when the question is: “Will our team use a reviewed AI playbook, rather than keep knowledge in personal prompts and chat history?”

Move beyond it when the question becomes: “Can we operate this safely and reliably across teams, roles, and business-critical processes?”

That second question needs more than Markdown files. It brings identity, permission policy, version history, auditability, release controls, reliable execution, and infrastructure into the picture. Those are not reasons to delay learning from a v1. They are reasons not to casually rebuild a production platform while trying to learn whether the workflow matters.

That is the layer we build at Typenode. Your team keeps the operational logic: the process it wants AI to follow, the actions it permits, and the knowledge it wants it to use. Typenode takes care of the harder work around robust sharing, security, and infrastructure, so your team can spend its time improving customer-service processes instead of maintaining the platform underneath them.

The goal is not a larger collection of AI instructions. It is a living team capability: knowledge contributed by the people doing the work, reviewed by the people accountable for it, and retrieved when a representative genuinely needs it.

Frequently asked questions

Does every representative need to use the same AI app?

No. The skill library can stay independent of the app, provided each AI client supports the MCP connection and sign-in method you choose. Start with one client, then validate each additional client deliberately.

Why not simply store prompts in a shared document?

You can start there. The library becomes more useful when you need to know which version is approved, who owns it, who may see it, and how an AI client retrieves only relevant guidance. The registry and connector add that operating layer.

Should every skill be an MCP tool?

Usually no. Keep the MCP surface small. A catalogue tool plus a retrieval tool lets the assistant see a concise menu before it opens a detailed playbook.

When do we need a dedicated authoring interface?

When the review queue, ownership, and version history are difficult to manage through the workflow you already have. Build it in response to that friction, not before.