Clarify the value of Skills over MCP vs. locally installed Skills, and the Tool–Skill association model

Background

I am trying to understand the architectural value of serving Agent Skills over MCP, especially from the perspective of an Agent Host that already supports locally installed Skills.

My current understanding is roughly:

MCP Server
├── tools/list
│   └── tool name / description / input schema
│
└── skills/list
    └── skill name / description / URI

Agent Host
├── Tool Registry
└── Skill Registry
    ├── local filesystem Skills
    └── MCP-served Skills

The MCP-served Skill eventually enters the same Skill loading and context mechanism as a locally installed Skill.

This raises a few questions about the actual relationship between MCP Tools and MCP-served Skills.

1. What associates a Tool with a Skill?

Suppose an MCP server exposes a tool with a sufficiently good description:

create_pull_request

Description:
Create a pull request for the specified repository and branch.
...

The model can inspect the tool description, determine that this is the right tool, and call it directly.

At that point, is there any protocol-level mechanism that tells the Host or model:

Before using this tool, consider/load Skill X

or:

This tool is related to these Skills:
- skill://pull-request-workflow/SKILL.md

As far as I can tell, the current model is instead:

User task
   │
   ├── model may select a Skill from Skill descriptions
   │      ↓
   │   load SKILL.md
   │      ↓
   │   Skill influences planning/tool selection
   │
   └── model may directly select a Tool from Tool descriptions
          ↓
       tool/call

So Skill selection and Tool selection are effectively two parallel model decisions.

If this understanding is correct, then a model can legitimately bypass a Skill whenever the Tool description is sufficient.

Is that intentional?

2. If a Tool description is sufficient, is the Skill simply unnecessary?

Consider a well-designed MCP server where:

• tools have clear descriptions;
• schemas are precise;
• errors are actionable;
• the model can reliably choose and call the correct tool.

For simple or atomic operations, it seems preferable for the model to call the Tool directly:

User intent
    ↓
Tool description
    ↓
tool/call

A Skill appears valuable mainly when the task requires higher-level knowledge such as:

multi-step workflow
conditional logic
organization-specific policy
multiple Tools
multiple MCP servers
large supporting documentation

For example:

"Create a pull request"

may need only a Tool.

Whereas:

"Perform our production release process"

may need a Skill that instructs the agent to:

check CI
→ check incidents
→ verify migrations
→ create release
→ observe metrics
→ rollback on failure
→ notify the team

If that is the intended boundary, it may be useful to state more explicitly that:

Skills are not an enhancement layer required for every MCP Tool. They are workflow-level context for cases where Tool descriptions alone are insufficient.

3. What is the incremental value over installing the Skill directly on the Agent Host?

Assume an Agent Host already supports:

~/.agent/skills/foo/SKILL.md

or a plugin/package model such as:

github-plugin/
├── mcp.json
└── skills/
    └── release-workflow/
        └── SKILL.md

Installing the Skill together with the MCP configuration is relatively inexpensive.

At runtime, both approaches seem to converge to roughly the same architecture:

Skill Registry
    ↓
Skill Loader
    ↓
SKILL.md enters model context
    ↓
model uses Tools

The main difference seems to be distribution:

Local installation:

Skill package
    ↓
Agent Host

versus:

Skills over MCP:

MCP Server
    ↓
skills/list / skills/get / resources/read
    ↓
Agent Host

If so, is the core value proposition of Skills over MCP primarily:

making the MCP server itself a standard remote distribution source for Skills?

That would make capabilities such as these the main differentiators:

• automatic discovery;
• server-driven updates;
• server/Skill lifecycle alignment;
• dynamic or generated Skills;
• RBAC / tenant-specific Skill exposure;
• distribution without a separate Skill registry.

If the Skill is static, rarely updated, and easy to package with the Agent, the local installation model seems substantially simpler and requires less Host-side MCP-specific functionality.

Is this considered an expected case where Skills over MCP should not be used?

4. Is there intentionally no Tool ↔ Skill binding?

There appear to be at least three different relationships that could exist:

MCP Server → Skill
distribution relationship

Skill → Tool
dependency / orchestration relationship

Tool → Skill
recommended or required guidance relationship

The current proposal seems primarily focused on the first relationship.

The second can be expressed informally in SKILL.md, but does not appear to have a standardized dependency model.

The third does not appear to exist at all.

For example, there is no apparent equivalent of:

tool:
  name: deploy
  relatedSkills:
    - skill://production-release/SKILL.md

or:

---
name: production-release
requires:
  tools:
    - deployment.get_ci_status
    - deployment.deploy
    - deployment.rollback
---

I am not necessarily suggesting that these fields should be added, but understanding whether this separation is deliberate would make the architecture much clearer.

5. Host complexity vs. benefit

Supporting Skills over MCP requires additional Host behavior around areas such as:

extension discovery
skills/list
skills/get
remote Skill identity
origin tracking
resource loading
progressive disclosure
permissions / approval
remote Skill security boundaries

If the execution semantics are otherwise identical to local Skills, this is meaningful additional Host complexity.

So I think the key architectural question is:

Under what conditions does remote Skill distribution through MCP provide enough value to justify this additional Host surface compared with simply installing the same Skill locally?

A decision guide based on concrete deployment patterns would be useful.

For example:

Static Skill
+ single Agent
+ simple installation/update
→ local Skill may be preferable

Dynamic / tenant-specific Skill
+ MCP-authenticated users
+ frequent server-side changes
+ centralized enterprise distribution
→ Skills over MCP may be preferable

Questions

I would appreciate clarification on the intended answers to these questions:

1. Is it expected and correct that an Agent may call an MCP Tool directly without loading any Skill?
2. Is there intentionally no standardized Tool → Skill association?
3. Is a Skill expected to be used only when Tool descriptions are insufficient for the higher-level task?
4. Is the main architectural value of Skills over MCP distribution/lifecycle management rather than a new Tool orchestration mechanism?
5. For static Skills that can easily be installed with the Agent or plugin, is local installation considered a first-class and potentially preferable alternative?
6. Are there plans for standardized Skill → Tool dependencies or Tool → Skill recommendations in future work?

I think clarifying these boundaries would help avoid an interpretation that every MCP server or Tool should have an associated Skill, when in many cases a well-designed Tool description may already be sufficient.

Review the Skills-over-MCP architecture described here, including SKILL.md, skills/list, skills/get, resources/read, and the separate Tool and Skill registries. Compare remote distribution with local installation and determine whether the existing documentation answers the six questions. Done means documenting the intended boundaries, trade-offs, and any future dependency or association model.