Skip to content

Instantly share code, notes, and snippets.

@PatrickJS
Created June 21, 2026 03:23
Show Gist options
  • Select an option

  • Save PatrickJS/7d1c664d85a5c62244498028ecdb4520 to your computer and use it in GitHub Desktop.

Select an option

Save PatrickJS/7d1c664d85a5c62244498028ecdb4520 to your computer and use it in GitHub Desktop.
When to build a skill, MCP server, CLI, or plugin

When To Build A Skill, MCP Server, CLI, Or Plugin

Use this guide to choose the right interface for developer tooling.

Quick Definitions

Thing What It Is Best For
Skill A reusable set of instructions and workflow rules. Teaching the environment how to approach a task.
MCP server A typed tool interface around live systems or local capabilities. Structured calls with clear inputs and outputs.
CLI A command-line interface for humans, scripts, tests, and setup. Operability, debugging, automation, and portability.
Plugin A packaged bundle of capabilities. Distribution, installation, versioning, and grouping related tools.

Decision Rule

Need behavior guidance?        Make a Skill.
Need typed tool access?        Make an MCP server.
Need shell usage?              Make a CLI.
Need to distribute a bundle?   Make a Plugin.

When To Create Each

Skill

Create a skill when the main value is repeatable behavior.

Examples:

  • Code review checklist
  • Release readiness workflow
  • Incident triage procedure
  • Data analysis methodology
  • Design critique rubric

Skills should describe how to work. They should not be the only place where critical implementation details live.

MCP Server

Create an MCP server when the environment needs structured access to something stateful, live, or external.

Examples:

  • Search a database
  • Read calendar availability
  • Control a browser
  • Query a local app
  • Inspect build status
  • Fetch project metadata

Use MCP when JSON-shaped inputs and outputs matter.

CLI

Create a CLI when humans, scripts, tests, or setup flows need direct shell access.

Examples:

  • tool status
  • tool init
  • tool validate
  • tool deploy
  • tool export
  • tool doctor

A CLI is usually the best first interface for local operability.

Plugin

Create a plugin when you want to distribute a complete capability as one installable unit.

Examples:

  • A company workflow pack
  • A database toolkit
  • A browser automation toolkit
  • A cloud provider toolkit
  • A design system toolkit
  • A repo maintenance toolkit

A plugin can bundle skills, MCP servers, CLIs, templates, scripts, docs, and app integrations.

Common Combinations

Combination Use When Example
Skill only The task needs a method, not code. Review checklist, planning workflow, writing standard.
CLI only A local utility is useful from the shell. release-notes generate, repo doctor, logs tail.
MCP only Structured tool access is needed, but humans rarely call it directly. Internal search, metadata lookup, browser state inspection.
Plugin only Rare; usually a plugin contains another capability. A bundle that installs templates or static assets.
Skill + CLI A workflow should run shell commands. Release skill that uses release check and release publish.
Skill + MCP A workflow should call typed tools. Triage skill using issue, email, or database tools.
CLI + MCP One capability should serve humans and structured tool calls. browser status CLI plus get_browser_status MCP tool.
Skill + CLI + MCP Full local workflow with instructions, operability, and typed access. Local app automation, repo maintenance, deployment control.
Plugin + Skill Distribute reusable workflows. Engineering standards pack.
Plugin + MCP Distribute tool integrations. Database, calendar, browser, or cloud provider pack.
Plugin + CLI Distribute command-line tooling. Internal platform toolkit.
Plugin + Skill + MCP + CLI Productized toolkit. Complete workflow bundle with docs, commands, and structured tools.

Recommended Architecture

For anything non-trivial, keep the real logic in a shared core:

core library or local service
  -> CLI
  -> MCP server
  -> Skill
  -> Plugin package

The CLI, MCP server, and skill should be thin surfaces over the same implementation.

Practical Defaults

Start with a CLI when you need local setup, debugging, or scripting.

Add MCP when structured tool calls are useful.

Add a skill when there is a preferred workflow or decision process.

Wrap it in a plugin when it should be installed, shared, versioned, or reused as a bundle.

Anti-Patterns

Avoid these:

  • Putting separate business logic in the CLI and MCP server.
  • Making a plugin for a one-off script.
  • Making an MCP server when a simple CLI is enough.
  • Making a skill that depends on undocumented hidden behavior.
  • Shipping a bundle without a doctor, status, or validation path.

Rule Of Thumb

Skill = how to work
MCP = typed access
CLI = human/script operation
Plugin = packaged distribution
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment