MCP2Skill logoMCP2Skill Docs
MCP2Skill logoMCP2Skill Docs
HomepageMCP2Skill User Manual

Overview and Core Concepts

Get to know MCP2Skill's positioning, core objects, and how to use it

Overview and Core Concepts

Before you actually start configuring anything, first understand the problem MCP2Skill really solves. With that in mind, the features covered later will make it much clearer why this is not just another ordinary MCP configuration panel.

What Is MCP2Skill

The core goal of MCP2Skill is not to simply pile up a bunch of MCP tools, but to convert those tools into reusable Skills, leveraging the on-demand loading mechanism of Skills so that AI Agents can use them in a more Token-efficient way.

Beyond this primary goal, MCP2Skill also takes on three responsibilities:

  • Manage MCP services in one place, and let multiple AI clients reuse the same configuration through the gateway
  • Manage the Skills directories of AI Agents and their installation results
  • Provide call statistics, logs, and trends, filling the gap most AI clients have in MCP observability

You can think of it as a "unified runtime layer":

  • First, add or import MCP services in MCP2Skill
  • Then choose one of two paths depending on your goal
  • Recommended path: convert to Skills and install them into an AI Agent
  • Secondary path: expose them to external AI clients through workspaces and gateway endpoints

The Difference Between MCP and Skills

From a purely product-usage perspective, you can think of them as two different paths:

  • MCP: expose tools directly to the AI workflow
  • Skills: convert tools into Skills, so the AI first sees only a brief description and reads the full content only when needed

The difference that matters most to users is not the file format, but how context enters the model:

  • With a direct MCP connection, the AI faces a set of tools it can call immediately
  • After converting to Skills, the AI usually only needs to know each Skill's name and purpose at startup
  • Only when a task actually matches does it go on to load the full SKILL.md, scripts, or reference materials

So the reason MCP2Skill advocates the Skill path first is not "an extra layer of wrapping," but that on-demand loading has a better chance of reducing Token consumption.

Why Not Just Configure MCP in Every AI Client

Configuring MCP repeatedly in every AI client looks simple, but it comes with plenty of real problems:

  • Higher Token cost: in many scenarios, exposing MCP directly is worse than converting to a Skill first, which makes it easier to use on-demand loading to reduce context consumption
  • Duplicated configuration: the same tool has to be entered, updated, and maintained again and again across multiple clients
  • Duplicated resource usage: every client has to spin up its own MCP processes
  • Poor observability: on the client side, you usually cannot see the full picture of call trends, error distribution, and runtime logs

The value of MCP2Skill is absorbing all of these scattered costs in one place.

Value at a Glance

  • Save Tokens: convert MCP tools into Skills first
  • Less repeated configuration: configure once, use everywhere
  • Fewer duplicate processes: run in one place, reducing duplicate usage on your machine
  • Fill the observability gap: see calls, trends, and errors
  • Keep compatibility: you can still connect any AI client through the gateway

The Core Objects in MCP2Skill

Skills

Skills are the first main line of MCP2Skill. You can think of them as "capability packages converted from MCP tools"—their value lies not only in reuse, but even more in on-demand activation.

In the current version, Skills can:

  • Be generated from an MCP service
  • Be generated from a workspace
  • Be exported to a directory
  • Be installed into the directory of a configured AI Agent
  • Be viewed and managed centrally on the Skills page

If your goal is to save Tokens, start with the Skills path by default.

MCP Services

An MCP service is the most basic connection unit. The current version supports three types:

  • STDIO: an MCP service started by a local command
  • SSE: an MCP service connected through a remote SSE address
  • Streamable HTTP: an MCP service connected through a remote HTTP address

Each MCP service can be individually enabled, disabled, have its tool list viewed, and have its call logs inspected. It is the shared foundation of both the Skills path and the gateway path.

Workspaces

A workspace groups multiple MCP services together by scenario, for example:

  • A web development workspace
  • A data analysis workspace
  • A writing workspace

A workspace decides not only "which MCP services are included," but also goes further to decide "which tools to keep and which to disable." If you take the MCP gateway path, the workspace is usually the core vehicle.

Gateway Endpoints

A gateway endpoint is the second main line of MCP2Skill, used to stay compatible with and serve external AI clients. The current version mainly offers three kinds:

  • An endpoint for a single MCP service
  • An endpoint for a single workspace
  • The aggregated endpoint of the system workspace ALL

You can copy the endpoint address directly, or copy a Claude Code-compatible JSON configuration. It fits the "unified management, multi-client reuse" scenario.

AI Agent

In MCP2Skill, AI Agent is mainly related to Skills management. You can maintain the corresponding Skill installation directory for each AI Agent, so MCP2Skill installs generated results directly into it instead of you copying files by hand.

What Is the System Workspace ALL

MCP2Skill maintains a system workspace called ALL. You can think of it as "the full collection of all currently available tools":

  • It aggregates the tools of all enabled MCP services
  • It appears in the sidebar alongside regular workspaces
  • Its endpoint is well suited for quickly verifying overall connectivity
  • It is not a regular workspace, so some operations differ from workspaces you create yourself

If you are not yet sure whether to split things into multiple workspaces of your own, you can start with ALL to verify that the gateway path works end to end.

Which Import Sources Does MCP2Skill Support

The current version supports importing MCP configuration from the following sources:

  • Clipboard
  • Local JSON file
  • Claude Desktop
  • Cursor
  • Claude Code
  • Gemini CLI
  • Codex

These sources are shown automatically in the import interface. For applications whose configuration files have been detected, MCP2Skill provides an import entry directly.

A Typical Usage Flow

  1. Import an existing MCP configuration, or manually add a new MCP service
  2. Enable the service and confirm the tool list displays correctly
  3. If you want to save Tokens: generate a Skill first and install it into an AI Agent
  4. If you want to serve multiple clients: create a workspace and copy the gateway endpoint or JSON configuration
  5. Observe the results through the statistics and logs pages

When to Prefer Skills, and When to Prefer the Gateway

  • To save Tokens, turn high-frequency tools into on-demand capabilities, and serve AI Agents: prefer Skills
  • To manage configuration in one place and reuse it across multiple AI clients: use the MCP gateway
  • To bundle multiple tools by task and expose them externally: use a workspace
  • To quickly verify the whole pipeline first: use the system workspace ALL

Next Steps

  • To start configuring right away: see Quick Start
  • To go straight to the Skills primary path: see Generate and Install Skills
  • To learn about import sources: see Import and Export Configuration

Table of Contents

Overview and Core Concepts
What Is MCP2Skill
The Difference Between MCP and Skills
Why Not Just Configure MCP in Every AI Client
Value at a Glance
The Core Objects in MCP2Skill
Skills
MCP Services
Workspaces
Gateway Endpoints
AI Agent
What Is the System Workspace ALL
Which Import Sources Does MCP2Skill Support
A Typical Usage Flow
When to Prefer Skills, and When to Prefer the Gateway
Next Steps