Plumbing reference
Six kinds of plumbing give the agent hands and eyes — CLIs, MCP servers, skills, plugins, hooks, and permissions. Four are tool-shaped extensions; two (hooks and permissions) are deterministic policy layers. Knowing which to reach for cuts most "should I install this?" debates short. This page lists the categories, when each fits, and the starter set worth installing today.
The four tool primitives, at a glance
| Kind | What it is | Reach for it when | Cost |
|---|---|---|---|
| CLI | A command-line tool the agent shells out to. | Default. The job is mostly text in / text out, you have a tool that already does it. | ~50 tokens of stdout per call. |
| MCP server | A typed, discoverable tool surface (Model Context Protocol). | Auth is involved, output is structured + large, you need typed tool discovery, no CLI exists. | ~500+ tokens per call (schema + envelope). |
| Skill | A bundled prompt + procedure loaded on demand. | You're encoding a repeatable workflow. "How we do X here." | Free until invoked; tokens cost when loaded. |
| Plugin | A bundle of skills, MCPs, and hooks shared as one install. | A workflow you've built deserves to travel — to teammates, across projects, or to a public registry. | Depends on what's bundled. |
And a fifth concept: hooks
Hooks are scripts that fire automatically on agent events — when a session starts, when a tool is about to run, when the agent stops, when a file is saved. They're how you wire side-effects around the agentic loop without modifying the agent itself. They sit alongside the four above more than under them — different shape, similar role.
What you can do with them
- Inject context on session start. Run
git statusand pipe it into the agent's first message — the agent always knows what's changed. - Block dangerous commands automatically. A pre-tool hook checks the proposed command and returns "no" before the agent runs it.
- Log everything. A post-tool hook writes a JSON record of every command, diff, and output. Audit trail without effort.
- Run lint or format on save. The agent's edit triggers a hook that fixes formatting before the next read.
Where they live in the Google stack
Gemini CLI ships hooks since v0.26.0 — configured in .gemini/settings.json, with startup, shutdown, and tool-lifecycle events. Full docs: geminicli.com/docs/hooks/.
Antigravity — the IDE we use today — does not expose hooks yet (as of April 2026). The workshop is short enough that the manual equivalent is faster anyway, but expect this gap to close in future releases.
When to reach for them
Hooks earn their cost when you have a recurring side-effect — auditing, formatting, context-loading, gate-keeping. For a one-off task, just write the command yourself. For something that should happen on every session of every project, hooks are the right shape.
In this workshop you won't write hooks. But once you graduate to Gemini CLI for power-user workflows, hooks are one of its highest-leverage features over the IDE-only path.
And a sixth concept: permissions
Permissions are declarative rules in your settings file — which tools the agent can run unattended, which files or paths it's allowed to write, which environment variables it can read. Where hooks fire imperatively on events ("when the agent runs rm, intercept and check"), permissions are declarative rules consulted before the agent acts ("the agent never needs approval for git status"). Same goal — bound the agent's behaviour deterministically — different shape.
What you can do with them
- Auto-approve safe commands.
git status,ls, read-onlygcloudcalls — let them run without prompting. - Constrain write access. Allow writes only to specific paths (
src/,tests/) and block edits everywhere else. - Expose env vars selectively. Share
GEMINI_API_KEYwith the agent but keepSTRIPE_SECREThidden. - Block dangerous patterns. Deny
rm -rf,curl | sh, or any command that touches paths you've marked off-limits.
Where they live in the Google stack
Gemini CLI — settings live in .gemini/settings.json alongside hooks. You'll find autoApprove, denyTools, and similar declarative knobs.
Antigravity — exposes a permissions surface in IDE settings; finer-grained per-project control as of recent releases.
When to reach for them
The moment you find yourself hitting allow for the same command for the tenth time in a session — that's your cue. Permissions trade some safety review (you've decided git status is fine; you don't review it anymore) for flow. The trade is almost always right for routine read-only operations and almost always wrong for write/delete operations.
The mental model: hooks for dynamic checks (event-triggered logic), permissions for static allow/deny lists (config-driven policy). Both bound the agent. Both are deterministic. They compose well — a permission that auto-approves git commit can sit alongside a pre-commit hook that runs the test suite first.
The starter MCP set
Context7 — fresh docs, always (recommended post-workshop install)
Single most useful MCP server in 2026. Without it, the model uses library APIs from its training cutoff — half-renamed flags, removed methods, confidently broken code. With it, the agent fetches current docs for any library on demand. Especially worth it if you do a lot of web work — the JavaScript/TypeScript ecosystem moves fast enough that the model is always slightly out of date on framework APIs.
We don't install it during the workshop — every extra MCP costs setup minutes and we kept the harness lean. If you install one MCP server after today, install Context7. Hallucinated APIs are the biggest source of wasted-time bugs in agentic coding, and a one-line MCP config kills most of them.
Install: context7.com — follow the Antigravity setup instructions.
Stitch — design hand-off (used in this workshop)
Lets the agent read your Stitch designs directly and translate them into code. We use it in step 4 of the workshop. You don't need a separate install — it's set up as part of the workshop tooling.
The starter CLI set
git
The agent shells out to git constantly — git status, git diff, git log. Make sure your git config is set, your global ignores are sensible. The agent uses git as its primary observation surface.
gcloud
Installed in step 1 of the workshop. The agent uses it for project-level commands, deployments, secrets. Authenticate once, and the agent inherits your auth.
gws · Google Workspace from the terminal
One CLI for Gmail, Calendar, Drive, Docs, Sheets. The agent runs gws calendar list instead of an MCP round-trip. Optional, but useful if you want the agent to schedule, draft emails, or pull data from Sheets.
Install: npm i -g @speed-kit/gws (or follow the project's README for the latest). Authenticate once with gws login.
The starter skill set
Today's workshop runs lean — Antigravity (or Gemini CLI as a fallback), the spec from step 3, and small commits. If you want a structured framework for the brainstorm → spec → plan → execute → review → finish loop after the workshop, see the spec-driven workflow deep-dive. Don't add a heavy framework until you have a project where the structure pays off.
Plugins · packaging your team workflow
The primitives above (CLI, MCP, skill, hook, permission) cover what the agent can do by itself. Plugins cover how you share a working configuration with someone else. A plugin bundles whatever combination of skills, MCP servers, hooks, and permissions you've found useful into one install. Teammates run the install once, and the same agent harness works the same way for everyone — no "did you also enable Context7?", no "which version of the lint hook are you on?".
When it's worth bundling
- The same skill + MCP + hook combo travels together. If "review-PR" needs the diff-skill, the GitHub MCP, and a lint hook — bundle them. Otherwise teammates miss one and the workflow silently degrades.
- Onboarding a new project or teammate. "Install our team plugin" beats a wiki page of 12 manual steps that nobody updates.
- Open-sourcing a workflow. A plugin in a public registry is how a workflow leaves your laptop and helps a stranger.
When to skip it
If you only have one skill or one MCP worth sharing, just point teammates at the install line. Plugins are for sets — three or more primitives that need to travel together. Below that, the bundle is overhead.
The curate, don't accumulate rule
Every tool description, every skill, every MCP server eats context every turn. 40 mediocre skills crowd out the model's better instincts. Mediocre tooling actively hurts you.
Once a quarter, walk through your installed skills and MCP servers. For each, ask:
- Have I used it this quarter?
- Did it produce a better result than the model would have without it?
- Would I notice if it disappeared tomorrow?
If the answer is no on any two, uninstall.