MCPSkill
MCP and Skill MarketMCP vs Skill
MCP

MCP Architecture

How clients, servers, tools, resources, prompts, permissions, and results fit together.

The basic model

MCP separates the agent runtime from the systems it needs to use. The client talks protocol; the server owns the integration with a database, file system, SaaS product, or internal workflow.

User request
   ↓
AI client / agent runtime
   ↓ discovery + invocation
MCP server
   ↓ controlled access
Tool, data source, workflow, or local system

Capability types

Tools

Callable actions with structured inputs, such as search, create ticket, query database, or validate file.

Resources

Readable context, such as documents, records, schemas, configs, or project metadata.

Prompts

Reusable prompt templates that guide common interactions or workflows.

Responsibility split

LayerOwnsShould not own
ClientDiscovery, selection, model context, permission UXBusiness logic hidden inside external systems
ServerIntegration logic, validation, execution, errors, audit logsUnbounded model reasoning or unrelated task workflow
SkillTask procedure and reusable expertiseDirect protocol transport or server implementation

Concrete request flow

This is the same documentation-search workflow written as a sequence. It shows what each layer knows and what it should not guess.

1. User asks:
   "Which page explains how Skills are structured?"

2. Client prepares available capabilities:
   search_docs(query, limit)

3. Model selects the capability:
   query = "Skill structure"
   limit = 3

4. Server validates input:
   query must be a non-empty string
   limit must be between 1 and 10

5. Server executes search and returns:
   results: [{ title, url, snippet }]

6. Client gives result back to the model.

7. Model answers with a link and a short explanation.
Boundary test The client should not know how the search index works. The server should not decide the whole user-facing lesson. The Skill can describe how to teach the answer.

Security boundaries

MCP does not remove the need for permissions. It gives you a place to define and enforce them.

Least privilegeExpose narrow capabilities instead of raw system access.
Input validationReject malformed or dangerous inputs at the server boundary.
Human approvalRequire confirmation for destructive, costly, or externally visible actions.
AuditabilityLog calls, inputs, outputs, actor identity, and failure states.