MCP, Plugins, Hooks, and the Extension Architecture — Inside Grok Build

THE INCIDENT · CHAPTER 07

A teammate says, ‘Let us make it a plugin.’ Another says MCP. A third proposes a skill and a fourth reaches for a hook. They are using four different mechanisms as if they were synonyms.

The question: Which extension point belongs to instructions, external capabilities, packaging, and lifecycle policy?

Start from first principles

A skill is a playbook, MCP is a loading dock to another system, a hook is a checkpoint at a lifecycle boundary, and a plugin is the box that can ship several of those pieces together.

Agent ecosystems become hard to secure when every customization is called a plugin. Grok Build exposes several mechanisms because they solve different operational problems.

Ask who invokes the extension, whether code executes, where trust is recorded, how long state lives, and whether the mechanism can block an action.

This chapter builds that decision tree, then combines a procedure, external service, and deterministic policy without confusing their authority.

In one sentence. 'Extension' is too broad to guide design. A skill adds instructions. MCP adds external tools. A hook reacts deterministically to lifecycle events. An agent definition changes a session. A plugin packages several mechanisms. Choose the narrowest mechanism whose lifecycle and authority match the problem.

1 · NEEDWhich extension point belongs to instructions, external capabilities, packaging, and lifecycle policy?

2 · MECHANISMThe harness must own a clear extension-quality boundary.

3 · PROOFObserve the model, harness, environment, and verifier separately.

The equation for the whole series. Coding-agent effectiveness = model capability × harness quality × environment quality × verification quality. If any factor approaches zero, the product approaches zero too. This chapter isolates extension-quality, then reconnects it to the complete system.

Build the smallest useful mental model

Classify extensions on invocation and authority. Skills are selected context. MCP exposes model-callable external tools. Hooks are lifecycle-triggered commands or HTTP callbacks. Plugins distribute several components.

Separate enabled content from trusted executable content. A discovered project plugin does not automatically get to run hooks, MCP, or LSP processes.

Prefer the narrowest mechanism: instructions for procedure, hooks for deterministic reactions, and MCP for structured service capabilities.

Fig 7.1 — Extension choice depends on invocation and executable authority.

Now open the hood

Only after the idea is clear does Mira open the source. She ignores most of the workspace and follows the few boundaries that must exist for this part of the story to work.

1. The next clue — Connect MCP over explicit transports

Mira now needs one small mechanism: External tools need stdio or HTTP/SSE transport, timeouts, and credential strategy.

She follows that responsibility into the repository. The MCP guide documents command/args/env and URL/headers forms plus list/add/remove/doctor commands. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Protocol configuration avoids embedding every service client in the core harness.

Then she tests the unhappy path: Cold starts, expired OAuth, committed headers, and timeouts fail independently of model reasoning. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 07-mcp-servers.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

2. The next clue — Namespace and discover tools

Mira now needs one small mechanism: Different servers need collision-free identities and bounded discovery.

She follows that responsibility into the repository. A server/tool becomes server__tool; search_tool and use_tool support discovery and invocation. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Origin remains visible without placing every external schema in permanent context.

Then she tests the unhappy path: Hooks and rules must match the qualified real name rather than an internal dispatcher alias. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: MCP tool-naming/discovery sections and hook matcher notes. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

3. The next clue — Bound integration output

Mira now needs one small mechanism: Large external results need inline caps and durable spill artifacts.

She follows that responsibility into the repository. The guide documents a default MCP/use_tool cap and full payload spill under the session mcp/ folder. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. The model receives a manageable observation while deeper inspection remains possible.

Then she tests the unhappy path: Truncation can hide the causal line; carry a truncation marker and artifact path. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: MCP guide output-size section. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

4. The next clue — Use skills for reusable procedure

Mira now needs one small mechanism: A skill packages SKILL.md, trigger metadata, and optional supporting resources.

She follows that responsibility into the repository. Skill discovery supports Grok, agents, Claude, and Cursor paths with priority and name deduplication. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Procedures load when needed rather than taxing every request.

Then she tests the unhappy path: Skill instructions do not bypass tool policy; executable resources still require normal authorization. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 08-skills.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

5. The next clue — Use hooks for deterministic reactions

Mira now needs one small mechanism: Lifecycle events can invoke command or HTTP handlers; only explicit PreToolUse denial blocks.

She follows that responsibility into the repository. The hook guide defines events, matchers, stdin/stdout JSON, timeouts, exit codes, and deny output. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Audit export, formatting, and hard policy should not depend on model memory.

Then she tests the unhappy path: Crashes, malformed output, and timeouts fail open; enforcement handlers must convert internal errors to explicit denial when required. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 10-hooks.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

6. The next clue — Package components as plugins

Mira now needs one small mechanism: One distributable unit can carry skills, commands, agents, hooks, MCP, and LSP configuration.

She follows that responsibility into the repository. The plugin guide defines convention paths, optional manifest, CLI lifecycle, and marketplaces. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Teams can version a coherent capability set without inventing a new execution model.

Then she tests the unhappy path: A bundle expands supply-chain surface; review each executable component and update origin. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: User guide 09-plugins.md. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

7. The next clue — Separate enabled from trusted

Mira now needs one small mechanism: Project content may be visible while executable components remain blocked pending trust.

She follows that responsibility into the repository. Project plugins require explicit trust; user and caller-controlled session plugin locations have different trust assumptions. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Opening an untrusted checkout should not silently launch its processes.

Then she tests the unhappy path: Trust is authorization, not a security audit. A trusted package can still be malicious or compromised. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Plugin guide trust model. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

8. The next clue — Inspect effective state

Mira now needs one small mechanism: Operators need an inventory of source, enabled/trusted state, skills, agents, hooks, servers, and tools.

She follows that responsibility into the repository. grok inspect, plugin details, MCP doctor/list, and TUI tabs show discovered components. The important point is not the Rust syntax. It is ownership: this is where the system decides what crosses the boundary.

Why the story changes here. Files on disk are not the same as active behavior when precedence and compatibility imports apply.

Then she tests the unhappy path: Reload semantics vary; confirm whether a change applies mid-session or next session. If the model, operator, and saved session do not receive the same honest outcome, the mechanism is not yet trustworthy.

Source: Plugin, skills, MCP, and hooks guides. Verified against Grok Build c68e39f60462f28d9be5e683d9cbe2c57b1a5027.

Mira runs the experiment — one procedure, one external tool, one policy hook

Reading source gives her a hypothesis. A small experiment tells her whether that hypothesis survives contact with a real workspace. Build a release workflow whose instructions, service access, and deterministic guard remain separate.

Write a release-review skill.
Configure a project-scoped read-only tracker MCP endpoint using environment references.
Run MCP doctor and authenticate outside committed config.
Add a PreToolUse shell matcher.
Explicitly deny pushes to the protected branch.
Inspect discovery and trust state.
Invoke the skill and discover the MCP read tool.
Verify a prohibited push is blocked even when requested.

grok mcp add --transport http --scope project tracker https://mcp.example.com/mcp
grok mcp doctor tracker
grok inspect

What she learns. The endpoint is illustrative; the command shapes are documented. Actual tools and authentication depend on the service.

The proof she demands. Record skill origin, qualified MCP name, trust state, hook decision JSON, and unchanged protected branch.

That last check matters. Grok Build can expose a mechanism and report an observation; the repository, operating system, CI platform, and reviewer decide whether those observations prove the actual task succeeded.

The whiteboard test

Before Mira explains the chapter to her team, she reduces it to three questions: what owns the decision, what evidence comes back, and what changes when the mechanism fails?

Review question	Source-backed answer	Operational consequence
Need instructions?	Skill or command.	Avoid adding a process.
Need an API?	MCP with scoped credentials.	Treat server/results as untrusted.
Need deterministic policy?	Hook.	Handle fail-open errors.
Need distribution?	Plugin.	Review each contained authority.

This is not a feature scorecard. A mechanism can work exactly as implemented and still be the wrong control for a particular threat. Defaults also change, so recheck the pinned source path before copying configuration into production.

Signals Mira keeps

Component origin, version, enabled/trusted state.
MCP transport, OAuth identity, qualified tool, duration, spill artifact.
Hook event, matcher, timeout, exit, decision, reason.
Plugin source, manifest digest, update path, executable inventory.

Together, those signals tell a complete story: the model proposed an action, the harness admitted and routed it, the environment performed something, and a verifier measured the result.

Limits and uncertainty

Supply chain. Plugins, package runners, local servers, and callbacks add trust outside Grok Build.

Fail-open hooks. Broken hooks do not block by default; enforcement must deny explicitly.

Secrets. Committed MCP config should reference environment variables, not contain credentials.

The public repository is unusually detailed, but it is not the complete deployed product. The snapshot has one visible public commit, so it cannot support a rich historical explanation of why every boundary evolved. Hosted xAI model serving, account systems, and production topology remain outside this study. Where code and guide differ, this series gives the pinned implementation priority and marks documentation-only behavior instead of silently merging versions.

FAQ

Is a skill a plugin?

A skill is one prompt-package mechanism; a plugin can bundle several mechanisms.

Can a hook allow bypass permissions?

No. Allow declines to deny; remaining permission checks apply.

Why MCP instead of a CLI?

MCP offers structured discovery. A CLI may be simpler when shell policy and existing tooling suffice.

Do project plugins execute immediately?

Executable components require trust under the documented project model.

What MCP name should policy match?

The qualified server__tool identity using the permission system's documented rule syntax.

What changed for Mira

Mira chooses extension mechanisms by required authority and lifecycle instead of by whichever name sounds most powerful.

Next: The project is now extensible, but a larger task raises a new question: how should work be divided?

Key takeaways

Mechanisms differ by invocation, lifecycle, and authority.
MCP adds tools; skills add procedure; hooks add deterministic reaction.
Plugins package components without merging their security semantics.
Enabled and trusted are distinct.
Inspect effective state and pin supply-chain inputs.

References & source notes

Pinned Grok Build repository — default branch snapshot researched July 16, 2026.
Grok Build README — first-party overview and source-build entry points.
MCP guide — transport and tool discovery.
Plugin guide — packaging and trust.

Freshness boundary. Grok Build claims in this article are pinned to c68e39f60462f28d9be5e683d9cbe2c57b1a5027. Pi comparison claims, where present, are pinned to 97f9978fa66685f78d2da19ae22e20c46d125f74; Hermes claims are pinned to c9c9bb33fcc6ab479846a1c496a6e9efe2c1c7d4. Recheck paths, symbols, commands, and defaults if those branches advance.

MCP, Plugins, Hooks, and the Extension Architecture.