How Gemini CLI Grows: MCP, Extensions, Skills, Hooks, and Subagents

Gemini CLI becomes more useful when it can reach beyond its built-in tools, but “extension” covers several different kinds of change. This chapter explains how MCP servers, commands, context files, skills, hooks, and subagents enter the agent loop, who invokes them, and what they can influence. The practical goal is to choose an extension surface by its behavior and reach while keeping the trust, permission, and maintenance questions visible.

The distinction matters because adding a new capability is not the same as adding a new instruction. A database connector can let the model perform an external query. A context file can change how it interprets a task. A skill can supply a procedure only when activated. A hook can stop or rewrite work at a lifecycle boundary. A subagent can create a second, focused agent loop. Gemini CLI's control model remains useful only when those differences are understood.

MCP is a capability bridge with its own trust boundary

Model Context Protocol, or MCP, gives Gemini CLI a standardized way to connect a model to external tools, data, and prompts. An MCP server can expose operations for an API, database, local script, or specialized workflow, along with resources that can be read into the conversation. The server is not the model and does not become part of the terminal merely because it is configured. Gemini CLI must discover it, represent its capabilities, and decide how calls are governed.

Discovery begins with the configured servers. Gemini CLI chooses a transport—stdio for a local subprocess, Server-Sent Events, or streamable HTTP—then attempts a connection with a timeout. It asks the server for tool definitions, validates and sanitizes their schemas for the Gemini API, applies include or exclude filters, and registers usable tools. Resources and prompts can be registered as well. A server that fails to connect is tracked as disconnected rather than being presented as a working capability.

This sequence protects an important interface. The server describes what it offers; Gemini CLI decides which descriptions can enter the model-facing tool registry. Schema sanitization removes or adjusts features that the model API cannot safely or reliably use. Filtering can expose only the operations an installation needs. The result is not a direct tunnel from a server into the model. It is a translated and filtered capability surface.

Every discovered MCP tool receives a namespaced model-facing name in the form mcp_{serverName}_{toolName}. That namespace prevents ordinary name collisions and lets the registry retain the relationship between a tool and its server. The naming choice also matters to policy: server identity can be used to target a rule, allow all tools from one server, or apply a decision to a single operation. The documentation warns that underscores in server names can confuse the parser that splits fully qualified names, so naming is part of the security configuration rather than a cosmetic convention.

When the model requests an MCP tool, the wrapper validates the arguments, asks whether confirmation is needed, invokes the original server-side name, and formats the response for two audiences.