Skill and MCP
Skills and MCP both extend an Agent, but solve different problems: a Skill mainly provides a reusable method and resources, while an MCP Server mainly provides callable external tools.
| Comparison | Skill | MCP Server |
|---|---|---|
| Primary purpose | Teach an Agent to follow a workflow | Provide new executable Tools |
| Typical content | Instructions, references, templates, resources, and optional scripts | A tool catalog, parameter schemas, and call results |
| Lifecycle | Discovered and activated for one Run | Provides a tool catalog while the local process is connected |
| Current sources | Bundled with the application, installed by the user, or project Workspace | User-configured local stdio Server, plus built-in application capabilities |
| Automatically authorized? | No | No |
Skill: package experience
A Skill uses SKILL.md as its entry point and can include references, templates, assets, and scripts. The Agent initially sees a short catalog and loads the full instructions only after selection, reducing unnecessary context use.
Three source types have different scopes:
- Bundled: Supplied with the application, including documents, spreadsheets, presentations, PDFs, image generation, and Skill Creator.
- Installed: Inspected and installed by the user from GitHub or an authorized local directory, then available globally.
- Workspace: Located under
.agents/skills/in the current project and discovered only in that project.
Activation normally applies only to the current Run. A package is bound to an exact version when activated; modifying its source files during a Run does not silently replace the loaded instructions.
A Skill's “trusted source” also does not grant permission. Writing files, running scripts, and generating Office documents remain subject to their own validation and approvals. Skill Scripts currently support only constrained Python paths, require elevated permissions, and require approval for every execution. The system does not install missing dependencies automatically.
MCP: connect tools to an Agent
MCP is a protocol that lets an application discover and call external tools. A user-configured MCP Server is currently a local stdio process. Captain Who starts it, reads a complete tool catalog, and then adds compliant tools to the Agent's available set.
Connecting has four separate actions: save the configuration, authorize startup, enable the connection, and approve a specific tool call. They cannot be combined into one “trust forever” toggle. Tool descriptions and read-only labels supplied by a third party are also insufficient to lower security requirements on their own.
Captain Who's built-in browser automation also uses a managed MCP capability internally. It is fixed by the application and runs through dedicated browser risk gates; it is not an arbitrary Server added by the user.
When to choose each one
- The team uses a fixed report format: create a Skill.
- You need to call a local database or a specialized service tool: connect an MCP Server.
- You need to apply a team process before using a specialized system: use a Skill and MCP together.
- You have one simple task: write a clear prompt instead of adding an extension for its own sake.
What neither one can do
- Expand Agent permissions through its own instructions.
- Bypass file-path, command, network, or approval policies.
- Guarantee that third-party content is trustworthy.
- Automatically resolve uncertainty in model context or external side effects.
Try it yourself: Create a Workspace Skill or Connect a local MCP Server.