claude code mods vs hooks vs skills vs mcp: which one do you need?
claude code now has four different ways to change how it works. they overlap, the names collide, and the newest one is the most powerful and the least safe to install blind.
a mod is code that runs inside claude code and can redraw its interface or rewrite an event first. a settings hook runs a script to allow, block, or log an event. a skill is markdown instructions claude reads. an mcp server gives claude tools for outside systems. most solo builders need a skill first and a mod last.
what anthropic added on october 1
mods are plugins made of javascript or typescript functions that claude code calls when something happens: a tool call, a submitted prompt, or part of the screen being drawn. each function can watch the event, change it, or answer it so the normal behavior never runs. anthropic announced them on october 1, 2026 on the claude blog.
the announcement's most telling line is a short one.
"You can also use Claude Code to mod Claude Code." (anthropic, october 1, 2026)
that is the practical part for a non-developer. you describe the feature you want in a session, and claude writes the mod using a built-in skill called plugin-authoring. some of claude code's own features already ship this way: the /diff pane is a mod.
mods need claude code v2.1.287 or later and are on by default (claude code docs, accessed october 5, 2026).
the four, side by side
the short answer: skills change what claude knows, mcp servers change what claude can reach, settings hooks enforce rules from outside, and mods change claude code itself from the inside. anthropic's docs compare the four directly. this is that comparison in plain terms.
| mod | settings hook | skill | mcp server | |
|---|---|---|---|---|
| what it is | functions in a plugin, running inside claude code | a script, http call, or prompt that runs on an event | a markdown file of instructions | a separate service that hands claude tools |
| what it can change | tool calls, prompts, commands, turns, and the screen | whether a call or prompt goes ahead, its arguments and result, added context | what claude knows and how it works | which tools claude has |
| can it draw on screen | yes | no | no | no |
| what you write | javascript or typescript | a script plus a settings.json entry | markdown | a server, any language |
| reach for it when | you want a pane, a custom command, or to rewrite an event | a rule must hold every time and you have a script for it | you keep pasting the same instructions | claude needs your crm, calendar, or database |
one detail that saves confusion: a plugin can hold all four. a single install can bring a skill, an mcp server, and a mod together, which is why mods install through the same /plugin install name@marketplace command as everything else. how plugins and marketplaces work is in claude plugins explained and the three layers of the claude marketplace.
"hooks" now means two different things
in anthropic's mod docs, "hook" means a mod's function, and the older kind you configure in settings.json is now called a "settings hook." if you set up hooks before october, yours are settings hooks, and they still work exactly as before.
the practical difference is where the code runs. a settings hook runs outside claude code as a shell command, http request, or prompt, so it can say yes, no, or log it. a mod's hook runs inside claude code, so it can also hold a tool call while it asks you a question, send one request to a different model, or keep a running count in one hook and show it in another. the settings-hook version, with the events worth knowing, is in claude code hooks explained.
when a mod is the right pick
a mod is worth it when you want to see or steer claude code while it works, not just change what it knows. anthropic shares three sample mods, without support, that show the range:
- token-weather draws a forecast of how full your context window is, above the prompt.
- blast-radius holds a risky shell command, like a force push, shows what it would change, and gives you buttons to go ahead or cancel.
- replay-theater adds a
/replaycommand that steps through the file edits claude made in the last turn.
none of those is a skill problem or an mcp problem. they are about what you see and when you get a say. if your need is "claude should know how i write proposals," that is still a skill, and prebuilt skills vs your own covers which to build. if your need is "never let it run this command," a settings hook or a deny rule does it with less code.
what a mod can reach before you install one
a mod runs with your permissions and is not sandboxed, so install mods only from authors and marketplaces you trust. anthropic's docs list what a loaded mod can do:
- read and write files anywhere your account can, start programs, and make network requests
- read environment variables and settings files, including api keys kept there
- see every prompt you send and every tool call claude makes
- approve a tool call before you are asked, including one your own
PreToolUsesettings hook blocked - call a model on your plan or api key, which spends your usage
even with sandboxing on, a process a mod starts runs outside the sandbox. a mod can restyle much of the interface, but not the permission prompt itself.
the check takes one command. clone the mod's folder and run claude plugin validate ./the-mod in your shell. the output lists every event the mod handles and every call it makes, such as a file read or a network request, without running it. if a mod that claims to draw a chart is making network calls, do not install it. to switch every installed mod off for one session, start claude code with --safe-mode. how much claude code does without asking in the first place is set by your permission mode, compared in claude code permission modes.
where mods actually show up
a mod's logic runs everywhere its plugin loads, but anything it draws only appears in the terminal and in the code tab of the claude desktop app. in the vs code extension's chat panel and in claude -p, the hooks still run and nothing is drawn, per anthropic's docs. cloud sessions work the same way, for a plugin that carries over to the cloud session. so a guard mod works in an automated run, and a dashboard mod does not.
the order i would add them in
add them from the least code to the most: skill, settings hook, mcp server, mod. this is my read from setting claude up on real businesses, not anthropic's rule.
- skill. the instructions you repeat every week. markdown, no code, the biggest return. start here if you have nothing yet; prompts, skills, plugins, and mcps covers the basics.
- settings hook. the rules that cannot slip, like formatting after every edit or blocking a destructive command.
- mcp server. when claude needs to read or act in a tool you already use.
- mod. when you want a pane, an instant command, or to step into a tool call. ask claude to write it, then read what it wrote.
the takeaway
mods are the first way to change claude code itself rather than what claude knows or can reach. that makes them the most capable of the four and the one to add last. get your repeated instructions into skills, your hard rules into settings hooks, your outside tools into mcp, and only then decide whether you want claude code to look or behave differently. and never install someone else's mod without running validate first.
start with the layer that pays back first
the ai builder toolkit is a set of claude skills that encode how the work gets done in a one-person business, ready to install and run today. it is the skill layer this post says to build first.
see the toolkitnewer to this and want the version with people in the room? the ai builders lounge is where the weekly builds happen.
or just follow along. new field notes most weeks on x, instagram, and tiktok.