How to Connect Any Agent to a Skill Library Over MCP

The Model Context Protocol turns a skill library from a folder you copy files out of into a live service your agent can query. This is a practical walkthrough of how MCP works and how to connect an agent to a skill library over MCP, using a real server as the example.

How MCP works: client, server, tools

The Model Context Protocol (MCP) is an open standard Anthropic released in late 2024 and the wider ecosystem adopted through 2025. It defines a common way for an AI application to talk to external systems, so you wire up a capability once and any compliant client can use it. For fuller background, see MCP explained for teams.

Three pieces matter here:

• Client — the AI app you already use: Claude Code, Cursor, or any MCP-capable agent. It manages the connection and decides when to call a tool.
• Server — the system exposing a capability. A skill library is a server: it holds your skills and answers requests about them.
• Tools — the named operations the server offers, each with a JSON input schema. The client discovers them at connect time and can call them during a task.

Transport is usually either local stdio (the client launches the server as a subprocess) or HTTP (the client calls a remote URL). A hosted skill library uses HTTP, which is what the examples below assume.

What a skill library exposes as tools

An agent skill is a reusable set of Markdown instructions an agent follows — a convention Anthropic introduced in 2025. If the idea is new, see what are agent skills. A skill library over MCP exposes a small, predictable set of tools for reading and writing those skills. Using Roget as the concrete example, its MCP server offers four:

• list_skills — list every skill the key's owner can access, owned or shared.
• get_skill — fetch the full Markdown of one skill by id or slug.
• create_skill — add a new skill.
• update_skill — change a skill's content or description (write access required).

That read/write split is the whole point. An agent can pull the current version of a convention mid-task, and — when you allow it — write a new skill back so the next agent inherits it.

Connect an agent to a skill library over MCP, step by step

The flow is the same for any client: get a key, register the server, verify. Below uses Roget's HTTP endpoint, but the shape is identical for any MCP skill server.

Step 1: Create an API key

A hosted server needs to know who is calling. In Roget, open Agent keys and create one; the raw key is shown once and stored only as a hash, so copy it immediately. You pass it as a bearer token on every request:

Authorization: Bearer YOUR_KEY

Treat the key like a password — put it in an environment variable or your client's secret store rather than committing it to a repo.

Step 2: Connect Claude Code

Claude Code adds HTTP MCP servers from the command line. Point it at the server URL and pass your key as a header:

claude mcp add --transport http roget https://roget.cc/api/mcp \
  --header "Authorization: Bearer YOUR_KEY"

Confirm it registered and check the connection:

claude mcp list

Once connected, Claude Code discovers the tools automatically. Ask it to "list my skills" and it calls list_skills; ask it to follow your review skill and it calls get_skill to read the current version. Add --scope project if you want the server recorded in the repo so teammates inherit it, rather than only on your machine.

Step 3: Connect Cursor (and other JSON-config clients)

Cursor and many other clients describe MCP servers in a JSON file — a project-scoped .cursor/mcp.json, or the global ~/.cursor/mcp.json. HTTP servers are declared with a url and optional headers:

{
  "mcpServers": {
    "roget": {
      "url": "https://roget.cc/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_KEY" }
    }
  }
}

Save and reload; Cursor lists the server and its four tools in its MCP settings. The same mcpServers shape works across most JSON-configured clients, so one snippet ports almost anywhere.

Step 4: Verify it works

Whatever the client, the first real request proves the whole chain — auth, transport, and tools:

• Ask the agent to list your skills. A correct setup returns your skill names; a 401 Unauthorized means the key is wrong or missing.
• Ask it to read one skill by name. You should get the Markdown body back verbatim.
• If you have write access, ask it to create a throwaway skill, then confirm it shows up in list_skills.

Under the hood these are plain JSON-RPC calls — tools/list to discover, tools/call to run — but you never write that by hand; the client speaks the protocol for you. If the server rejects the request, it is almost always the header: confirm the key hasn't been rotated and that Bearer precedes it with a single space.

What you get once connected

With the library wired in, your instructions stop being files each tool copies and lets go stale. Every connected agent reads the same versioned skills live, so an update in one place reaches Claude Code, Cursor, and anything else you connect. Because the server enforces per-key access, shared skills reach teammates without passing a repo around.

That is the payoff of connecting an agent to a skill library over MCP: one source of truth your tools read, instead of drifting copies each tool maintains alone. Browse ready-made skills in the skill directory, or wire up your own at roget.cc.