Skills on demand

Anvil can do a great deal — files and shell, web, databases, browsers, image generation, a whole marketplace of installable skills. If it put all of that in front of the model on every turn, the list of tools would be larger than the work. So it doesn't. Anvil keeps a small core always loaded and brings everything else in on demand, the moment a task reveals it's needed.

The core, always ready

A fixed set of core tools is advertised to the model on every single turn — the things almost any task reaches for: reading and writing files, running shell commands, searching, the built-in analysis sandbox, web fetch and search, delegating to an agent or a workflow, and the task tools. Alongside them sit the discovery tools — find_capability, use_capability, ToolSearch, and Skill — which are never deferred, because they're how everything else gets found.

Everything beyond that core starts deferred: present in Anvil, absent from the model's view, until something calls for it.

[!NOTE] This behaviour is the tools.defer setting, on by default. Turn it off and Anvil advertises every tool every turn — simpler, but much heavier on context. On is almost always the right choice.

How a capability gets loaded

When the model hits a need it doesn't already have a tool for, it doesn't guess — it searches. The flow is:

1. Describe the need in plain words. The model calls find_capability with something like "convert this notebook to a script" or "query the production database".
2. Anvil searches its whole surface. Behind find_capability is a ranked index over everything Anvil can do — commands, built-in tools, MCP tools, squads, installed skills, chains, routines. It returns the best matches with, for each, what it's for, when to use it, how to invoke it, what side effect it has, and whether you're allowed to run it.
3. The capability loads. Once found, that tool joins the model's advertised set from the next turn on — and anything actually used stays loaded for the rest of the session, so it's never lost mid-task.

For capabilities that are really Anvil's own commands, the model can go one step further and run them directly with use_capability, through the very same handler the slash command uses — gated, per call, on what the command actually does (read-only, writes, network, spend, destructive), and refused outright in read-only or plan mode. If a capability isn't exposed to run this way yet, you get an honest refusal that says so — never a pretend success.

The system prompt steers the model toward this: when it lacks a direct tool for what you asked, it's told to call find_capability with your need in plain words before reaching for a web search.

Installed skills work the same way

A skill you install from the marketplace with /hub install <name> isn't wired in by hand. Anvil discovers it on disk, folds it into the same capability index, and from then on it surfaces through find_capability like anything else — invoked with the Skill tool when the moment comes. Install it today; the model finds it the next time a task needs it.

If you install (or remove) a skill from AnvilHub while a machine is offline, the change is queued and applied when the host next checks in — so the web and the terminal stay in step.

Why it matters

Three payoffs, all from the same design:

• Context stays lean. The model spends its attention on your task, not on a catalogue.
• It scales. Install a hundred skills and the always-on footprint doesn't grow — they're all reachable, none are in the way.
• It's honest. A capability is either found and run, or refused with a reason. Anvil doesn't claim a tool it can't actually use.

Where to next

• Marketplace — find and install skills, plugins, agents and themes.
• Squads — the same on-demand idea, applied to specialists.
• Command reference — the full surface, if you'd rather browse it yourself.