Commands, Skills, and MCP Feed the Same Capability Pool

A user sees many entrances: /init, project skills, plugin commands, MCP prompts, MCP tools, and built-in tools. The runtime cannot treat them as a mystery pile. It has to load, normalize, deduplicate, and expose them in the right place for the current turn.

getCommands(cwd)
  -> built-in commands
  -> user / project commands
  -> plugin commands
  -> skill-backed commands

AppState.mcp
  -> MCP tools / prompts / resources
  -> model-facing tool pool for the next turn

Source shape: command tables serve user-triggered routes; MCP and Skill tools enter the model-facing capability pool.

1. Commands are user-facing entrances

Built-in slash commands live in the command registry. More commands can arrive from skills or plugins. The command-loading path gives the REPL a stable table it can use when the user types /. The model does not call slash commands directly; slash commands are mostly user-facing routes into prepared behavior.

Capability unit	Raw input	Normalized record	Owner and visibility	Consumed by	Observable result
Slash command	User text such as `/compact` or a project command name.	A command object with metadata, handler behavior, and optional prompt-producing logic.	The REPL owns the command table. The model sees only the resulting prompt or state change, not the command registry itself.	The command dispatcher in the current interactive turn.	Local state changes, a generated prompt, or a specialized route such as compact or resume.
MCP tool	A connected MCP server advertises tools, prompts, or resources.	Capabilities are stored in MCP-related app state and then adapted into the model-facing tool pool.	The runtime owns the client connection and permission boundary. The model sees tool schemas, not raw server control.	Tool assembly before the provider request and the normal tool runtime after `tool_use`.	A model-visible tool option that still returns through the regular `tool_result` contract.

Command loading sources: built-in commands, project skills, packaged skills, plugin commands, and MCP prompts — Several shelves can contribute commands, but the REPL needs one command table for the current session.

2. A slash command turns text into a structured route

When a slash command is selected, the REPL handles it as a command object rather than ordinary chat text. That distinction matters because some commands modify local session state, some produce a prompt, and some start a specialized path such as compact or resume.

Slash command path from user selection to command handler and next query — The slash path lets user intent bypass fuzzy interpretation when the operation is known.

3. Skills can add both instructions and tools

A skill is not just prose. It can provide instructions, assets, scripts, and sometimes a tool surface. The runtime needs to index skill metadata, decide what is relevant, and make the resulting ability available at the right layer. This is why skills belong in a capability-pool discussion instead of a documentation-only discussion.

Skill index connecting skill metadata, instructions, assets, and tool exposure — Skills are loaded as structured capabilities, not as random text snippets.

4. MCP tools join the model-facing tool pool

MCP is different because it can expose tools to the model. After clients connect and capabilities are discovered, MCP tools are assembled with built-in tools and filtered by availability, settings, and permission rules. From the provider request's point of view, they become part of the tool schema list.

MCP clients exposing tools into the Claude Code tool pool — MCP extends the tool pool, but those tools still pass through the same runtime contracts.

5. The invariant

Extension surfaces are not magic backdoors. A capability has to become either a user command, a model-visible tool, or local runtime state. If you know which bucket it enters, you can predict which gates will govern it next.

Sources