TL;DR: registry.ollama.ai/library/<model> does not support tools is Ollama refusing your request before the model ever runs, because your coding agent sent a tools array to a model whose chat template has no tool-calling support. It is not a bug in Cline, Continue.dev, or Claude Code, and no client-side retry will clear it. The fix is one of three things: switch to a model that lists tools under ollama show, re-pull a model whose library template has since been fixed, or add a {{ .Tools }} template to a custom import.

What you’ll be able to do after this guide:

• Diagnose the error in 30 seconds with ollama show <model> and its Capabilities list — no log spelunking
• Match the failure to its layer: wrong model, stale template, broken custom import, or a client that insists on sending tools
• Pick a replacement coding model that actually tool-calls, sized to your VRAM

Honest take: Nine times out of ten this error means you pointed an agent at a completion-era model — codellama, plain llama3, a base tag, or a community GGUF with a gutted template. Don’t fight the template unless you imported the model yourself. Run ollama pull qwen3-coder:30b (24GB card) or devstral:24b (16GB card) and get back to work.

This is the fifth entry in our Ollama troubleshooting series, after connection errors, the silent context-length trap, out-of-memory crashes, and silent CPU fallback. Everything below was verified on August 17, 2026 against the Ollama source on main and Ollama v0.32.14 (released August 15, 2026), Cline 4.1.10, and Continue.dev 1.3.40.

The exact error, and where each tool hides it

Hit the API directly and the failure is clean — an HTTP 400 with the model’s fully resolved name:

$ curl http://localhost:11434/api/chat -d '{
  "model": "codellama",
  "messages": [{"role": "user", "content": "list files"}],
  "tools": [{"type": "function", "function": {"name": "list_files", "parameters": {}}}]
}'
{"error":"registry.ollama.ai/library/codellama:latest does not support tools"}

The request never reaches the model. Ollama checks the model’s declared capabilities first, sees that a tools array arrived for a model that can’t consume one, and rejects the whole call.

Inside the coding tools, the same 400 wears different costumes:

• Cline surfaces it as a red API-error banner, usually prefixed with the status code: 400 codellama:latest does not support tools. That exact string has been reported against Cline since issue #460 in 2024, and it still fires in 2026 because Cline’s Ollama provider attaches a tools parameter to every request — issue #11263 (June 2026) traced it to the provider converting Cline’s toolset on every call regardless of what the model supports.
• Continue.dev typically doesn’t show the raw 400. Chat keeps working — chat requests carry no tools — but Agent mode is either grayed out for the model or fails on its first tool-bearing request. Continue’s docs are explicit that the tool_use capability is what Agent mode runs on.
• Claude Code (wired to Ollama’s Anthropic-compatible endpoint) fails immediately, because Claude Code cannot operate without tools — every session opens with file-read, edit, and shell tools attached. Ollama’s own Claude Code integration guide points local users at the tool-capable model filter rather than the general library for exactly this reason.
• Goose, Codex CLI, and Kilo Code behave like Claude Code: the agent loop is tool-native, so a non-tool model is unusable rather than degraded. Goose’s docs go as far as requiring extensions to be disabled if the model can’t tool-call — see our goose + Ollama guide.

One thing this error is not: a model that accepts tools and then misuses them. If your model takes the request but loops forever, emits raw JSON into the chat, or never calls a tool, that’s a different failure with different fixes — covered in Cline + Ollama stuck in a loop.

The 30-second diagnosis

Ask Ollama what the model can actually do:

$ ollama show qwen3-coder:30b
  Model
    architecture        qwen3moe
    parameters          30.5B
    ...
  Capabilities
    completion
    tools

If tools is missing from that list, you’ve found your answer, and nothing you change in Cline or Continue will fix it. The capability list is computed by the server itself — the same list the 400 check reads.

Where the list comes from matters for the fixes below. Reading the current Ollama source (server/images.go), a model earns the tools capability from any of: an explicit capability in its config, a Go template that references the tools variable, or — on recent Ollama versions — a GGUF chat_template that contains tools/tool_call markers. The error string is assembled in the same file: a bare does not support joined to tools, prefixed with the resolved model name by the scheduler. That’s why the message quotes registry.ollama.ai/library/... even though you typed a short name.

Symptom → cause → fix

Symptom	Cause	Fix
400 on a library model (codellama, llama3, base tags)	Model was never trained or templated for tool calling	Switch models (Fix 1)
400 on a model whose library page now shows a Tools badge	You pulled it before the template was updated	ollama pull again (Fix 2)
400 on a model you imported from Hugging Face or built with a Modelfile	Your template lacks a {{ .Tools }} node	Repair the template or update Ollama (Fix 3)
400 only in one tool, others fine	That client always sends tools (Cline) or you enabled agent features for a chat-only model	Per-tool config (Fix 4)
No 400, but tools never fire / infinite loop	Model has the capability but flubs the format	Not this error — see the tool-use loop fix

Fix 1: switch to a model that can actually tool-call

For coding agents, the shortlist we’ve verified across this site’s setup guides, sized by card:

Model	Quant size	Card that fits it	Why
qwen3-coder:30b	~19GB Q4	24GB (RTX 3090/4090)	The default agent pick; MoE with 3.3B active params, strong tool discipline on Ollama v0.32.1+
qwen3.8:27b	18GB Q4_K_M	24GB	Newest of the group (Aug 14, 2026); ships with tools, vision, and thinking capabilities — our full review
devstral:24b	~15GB Q4	16GB	Dense Mistral coding-agent model; the most reliable tool-caller we’ve tested under 20GB
gpt-oss:20b	~12GB MXFP4	16GB	OpenAI’s open-weight model, runs within 16GB of memory per its official repo; Codex CLI’s default local model

Browse the full set through Ollama’s tools capability filter — if a model doesn’t carry the Tools badge there, don’t build an agent on it. And remember the sibling trap from earlier in this series: agents need context, and Ollama’s VRAM-scaled default can be as low as 4K. Set 64K+ for agent work or your newly tool-capable model will silently truncate its own tool definitions.

What to stop using: codellama (2023-era, no tool template, the model in the original Cline report), base/-base tags of anything, and deepseek-r1 distills for Agent mode — Continue.dev users have repeatedly hit “does not support tools” with R1 variants whose reasoning template leaves no room for tool markers.

Fix 2: re-pull — your template may be months stale

An Ollama model is weights plus config plus template, and the library copies get corrected over time — several popular models gained working tool templates well after release. A pull refreshes whatever changed, and matching layers aren’t re-downloaded, so this is cheap:

$ ollama pull qwen3-coder:30b
$ ollama show qwen3-coder:30b   # confirm 'tools' now appears

If you pulled a model in 2025 and its library page shows a Tools badge today while your local copy 400s, this is almost certainly your fix. It costs one command and a manifest download.

While you’re at it, update Ollama itself. Capability detection has broadened over the v0.30–v0.32 series — current builds can derive tool support from a GGUF’s embedded chat_template, which older builds ignored in favor of the Go template alone. A Hugging Face import that 400s on an old Ollama can pass on v0.32.14 with no other change.

Fix 3: custom imports — give the template a {{ .Tools }} node

If you built the model yourself — ollama create, a Hugging Face GGUF import, or a fine-tune — the capability check is telling you your template never mentions tools. This is the exact situation in ollama issue #15857, where a user’s hand-built -tool variant was rejected despite its name.

Ollama’s template docs state it directly: “Tools support can be added to a model by adding a {{ .Tools }} node to the template.” The clean way to do it is to steal the template from the closest official model rather than writing one:

$ ollama show --template qwen3-coder:30b > tools.tmpl   # a known-good tool template
$ cat Modelfile
FROM ./my-finetune.gguf
TEMPLATE """<paste the template matching your model's training format>"""
$ ollama create my-finetune-tools -f Modelfile
$ ollama show my-finetune-tools                          # verify 'tools' appears

Two honest caveats. First, the template must match the format the model was actually trained on — Qwen-style tool markup fed to a Llama-tuned model produces garbage calls, which lands you in loop territory instead of 400 territory. Second, a template can make Ollama accept the request, but it cannot teach a model that never saw tool-calling data how to emit well-formed calls. If the base model can’t do it, no Modelfile will save you; pick a model from Fix 1.

Fix 4: per-tool settings

Cline (4.1.10). Cline’s Ollama provider sends its toolset natively on every request, so there is no toggle that makes a non-tool model work — issue #11263’s proposed “use native tool-calling” switch hadn’t shipped as of this writing. Your options are exactly two: use a Fix-1 model, or route through a different provider entirely. Don’t waste time on the base-URL field; this isn’t a wiring problem like connection refused was.

Continue.dev (1.3.40). Chat and autocomplete never send tools, so a non-tool model is fine there — only Agent mode needs tool_use. If Continue’s autodetection misses a tool-capable model (common with custom names or your own imports), you can add the capability in config.yaml:

models:
  - name: my-finetune-tools
    provider: ollama
    model: my-finetune-tools
    capabilities:
      - tool_use

Continue’s docs are precise about the direction this works: capabilities are additive — “you cannot override autodetection — you can only add capabilities.” And declaring tool_use only changes what Continue sends; if the Ollama-side template still lacks tools, the 400 comes right back. Fix the model first, then the config.

Claude Code. No client-side escape hatch exists or should: the whole product is tool calls. Pick from the tools filter, give it a 64K+ context window per Ollama’s integration guide, and follow our Claude Code + Ollama setup for the env-var wiring — including the background-model trap where a forgotten default Haiku model triggers its own capability errors.

Codex CLI and Goose. Same rule, tool-capable models only. Codex’s --oss default (gpt-oss:20b) already qualifies — details in our Codex CLI + Ollama guide. Goose adds one wrinkle: with a non-tool model it doesn’t 400 gracefully, it just can’t run extensions, so disable them or don’t bother — our goose guide covers which models clear the bar.

Running bigger tool-capable models than your card allows? A rented A100 with OLLAMA_HOST pointed at it sidesteps the VRAM question entirely — RunPod works fine for this, runaihome’s VRAM guide covers what fits locally before you spend anything, and aifoss.dev tracks the FOSS serving-stack side.

FAQ

Why does the error show registry.ollama.ai/library/... when I never typed that? Ollama resolves short names to their full registry path before the capability check, and the error is built from the resolved name. llama3 and registry.ollama.ai/library/llama3:latest are the same model.

The model’s card says it was trained for function calling. Why the 400? Training and template are separate layers. Ollama grants the tools capability from the template (or GGUF chat template), not from the model card. A tool-trained model behind a tool-less template still 400s — that’s Fix 2 or Fix 3.

Can I just strip the tools from the request instead? Only if the client lets you. Continue does (don’t use Agent mode); Cline currently doesn’t; Claude Code, goose, and Codex can’t function without tools. An agent without tools is a chatbot.

Does this affect the OpenAI-compatible /v1 endpoint too? Yes. The capability check runs server-side on both the native and OpenAI-compatible APIs — Cursor and other /v1 clients get the same 400 when they attach tools.

Is does not support thinking the same problem? Same mechanism, different capability. Ollama runs identical checks for thinking, insert, vision, and embedding, and each produces the matching does not support ... message. The ollama show capability list diagnoses all of them.

Sources

• Ollama tool calling documentation — Official docs
• Ollama template reference (Tools node) — Official docs
• Ollama server capability checks — server/images.go, ollama/ollama source
• Ollama chat endpoint tools gate — server/routes.go, ollama/ollama source
• Ollama releases (v0.32.14, Aug 15 2026) — GitHub
• Cline issue #460 — 400 codellama does not support tools
• Cline issue #11263 — Ollama tools parameter sent unconditionally
• Ollama issue #15857 — custom -tool import rejected
• Continue.dev model capabilities documentation — Official docs
• Ollama Claude Code integration guide — Official docs
• Ollama tool-capable model filter — ollama.com

Last updated August 17, 2026. Model capabilities, templates, and client behavior change frequently; run ollama show against your own install before acting on any list above.