Goose + Ollama Local AI Agent Setup in 2026: Tool Calling, MCP, Context & Security

Local AI is moving from “chat with a model” toward agents that can inspect files, run commands, edit code and call external tools. That makes the agent runtime just as important as the model. One current project worth understanding is goose, an open-source agent with desktop, CLI and API interfaces. Its v1.52.0 release on September 23, 2026 added Live Voice conversations in the desktop app, new provider work and other agent improvements.

This guide focuses on a practical use case: running goose with a local Ollama model so that coding and automation tasks can stay on your machine. The important part is not merely getting a chat window working. You need a model that supports the capabilities an agent needs, a sufficiently large context window, carefully scoped tool permissions and a reliable way to verify which service goose is actually calling.

What makes goose different from a normal local chatbot?

A normal local chat application mainly sends prompts to an inference server and displays responses. An agent adds a control loop around the model. The model can decide that it needs to inspect a file, run a command, search a project, call an extension or make another tool request before answering.

goose supports desktop and CLI workflows, multiple model providers and extensions through the Model Context Protocol (MCP). The official project describes it as a general-purpose agent for coding, research, writing, automation and data analysis. That flexibility is useful with local models, but it also means that model compatibility and permissions matter much more than they do in a simple chat application.

Why pair goose with Ollama?

This separation is valuable when troubleshooting. If a model can answer in Ollama but goose cannot complete a tool call, the model runtime may be healthy while the agent/provider compatibility is the actual problem.

Prerequisites

• A supported Windows, macOS or Linux machine.
• Ollama installed and reachable at its local API, normally http://localhost:11434.
• A local model that supports the tool-calling behavior required by your goose workflow.
• Enough RAM or VRAM for the model plus its context and agent tool traffic.
• A project directory that does not contain secrets you are unwilling to expose to an agent.

Do not start with the largest model your hardware can barely load. An agent needs memory for conversation history and tool results as well as model inference. A smaller model with reliable tool calling can be more useful than a larger model that constantly runs out of memory or context.

Install goose

The official goose project provides desktop applications for macOS, Linux and Windows and also provides a CLI installer. For a CLI installation, the project currently documents:

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

After installation, verify that the executable is available:

goose --version

For reproducible environments, record the version rather than relying indefinitely on a moving “latest” build. goose v1.52.0 was released September 23, 2026 and its official release page lists platform-specific assets.

Install and verify Ollama first

Before involving goose, make sure Ollama itself works:

ollama --version
ollama list

Run a model that you know is available and suitable for tool use. The goose documentation's Ollama examples use models that support tool calling, and its provider setup expects the local Ollama service to be reachable.

ollama run qwen2.5

The exact model you choose can be different. Check the model's current Ollama metadata and capabilities before assuming that every chat model supports reliable agentic tool calls.

Connect goose to local Ollama

goose can be configured interactively:

goose configure

Choose Configure Providers, select Ollama, enter the Ollama host and then select the installed model. For a normal local Ollama installation, the documented endpoint is:

http://localhost:11434

goose also supports environment variables for provider selection. A useful diagnostic configuration is:

export GOOSE_PROVIDER=ollama
export GOOSE_MODEL=qwen2.5
export OLLAMA_HOST=http://localhost:11434

On Windows PowerShell, use:

$env:GOOSE_PROVIDER="ollama"
$env:GOOSE_MODEL="qwen2.5"
$env:OLLAMA_HOST="http://localhost:11434"

These variables are process-level configuration. goose's current configuration documentation also describes persistent provider configuration in its YAML files.

Verify the connection before testing tools

Start a goose session and send a trivial request first. Then ask for a harmless filesystem operation inside a test project. The order matters:

1. Verify Ollama responds.
2. Verify goose can start a session.
3. Verify the selected model is the one you intended.
4. Verify a simple tool action.
5. Only then enable additional MCP extensions.

If the simple conversation fails, adding more extensions will make diagnosis harder rather than easier.

The biggest local-agent problem: model capability

Tool calling is not just a matter of model size. The model needs to understand the tool schema and reliably produce the structured request expected by the runtime. Some models can produce convincing natural-language instructions while failing when an actual function call is required.

goose's own documentation warns that models without tool-calling support can fail when a session requires tools. This is especially important for coding agents because file inspection, terminal commands and other operations are not optional extras; they are part of the agent loop.

Context length matters more with agents

Agent sessions accumulate more than user messages. Tool results, file contents, command output and previous decisions all consume context. A model that feels fine in a short chat can become ineffective when goose has to inspect a medium-sized project.

The goose provider documentation specifically notes that a low context window can cause problems with extensions and .goosehints. If an agent appears to forget instructions or repeatedly loses the result of a tool call, check context configuration before assuming that the model is “bad.”

With Ollama, the context window can be configured through the environment when appropriate. Do not set an enormous context merely because the model advertises one. Context consumes memory, and your actual hardware still has to hold the model, KV cache and runtime buffers.

What to do when goose connects but tool calls fail

1. Test the model directly in Ollama

Confirm that the model itself responds. If direct Ollama inference fails, fix that layer first.

2. Check the provider endpoint

Confirm that goose is pointing at the intended host:

curl http://localhost:11434/api/tags

You should receive Ollama's model listing. If this fails, goose cannot be expected to work.

3. Check model support for tools

Do not infer tool support from the fact that a model can produce JSON. Structured JSON generation and actual tool calling are related but not identical capabilities.

4. Check the context window

Agent prompts can grow rapidly when tools return logs or source files. Start with a small project and a simple operation.

5. Reduce the number of extensions

Enable one extension at a time. If the base agent works and adding one extension breaks the workflow, you have narrowed the fault domain.

A current caveat with Ollama and reasoning models

There is an open goose issue filed September 9, 2026 concerning Ollama provider requests and the think control for hybrid-reasoning models. The report says goose's Ollama paths use Ollama's OpenAI-compatible /v1/chat/completions route rather than the native /api/chat route, which can prevent the Ollama-specific think field from controlling reasoning behavior.

Treat this as an attributed project issue, not a universal guarantee about every goose or Ollama version. If you are troubleshooting a reasoning-heavy model, check the current goose issue status and test the exact versions you have installed. This is one reason release-specific troubleshooting is better than copying an old configuration from a blog post.

Security: local does not automatically mean safe

Running the model locally reduces the need to send prompts to a hosted inference API, but an agent can still access sensitive information on the machine. If goose has shell, filesystem or MCP extensions, the risk moves from “what does the cloud model receive?” to “what can the agent do on this computer?”

• Use a dedicated project directory.
• Keep API keys, SSH keys, production databases and personal documents outside the agent workspace.
• Review tool permissions before enabling automatic execution.
• Be especially careful with MCP servers that can access external systems.
• Do not expose the Ollama API publicly just to make a local agent connect.
• Use a private network and authentication when a remote Ollama host is genuinely required.

When goose + Ollama is a good fit

FAQ

Can goose use Ollama completely locally?

Yes. goose supports Ollama as a provider and can connect to an Ollama instance running on the same machine. The model inference remains local, although any extensions or external services you deliberately configure may communicate outside the machine.

Why does my Ollama model work in chat but not in goose?

The most common conceptual difference is tool calling. An agent needs structured tool interactions, not just good text generation. Also check context size, provider configuration and the exact model/runtime versions.

Does goose require a powerful GPU?

Not specifically. The hardware requirement is driven by the model and inference runtime you select. CPU-only inference is possible for compatible models, but interactive agent workflows can become impractical if each tool cycle takes too long.

Can goose connect to a remote Ollama server?

Yes. goose's provider configuration supports an Ollama host other than localhost. If you do this, secure the network path and do not expose an unauthenticated inference endpoint to an untrusted network.

Is goose an MCP client?

Yes. goose uses MCP extensions to connect agents with tools and data sources. That makes MCP configuration a powerful part of the system, but also an important security boundary.

Official sources

• goose v1.52.0 release
• Official goose website and documentation
• goose provider configuration documentation
• goose configuration files
• goose Ollama reasoning-control issue

Related GyanAangan guides

• OpenCode + Ollama Troubleshooting
• Ollama 0.34.4: What Changed
• Ollama vs llama.cpp vs LM Studio vs vLLM
• How to Calculate VRAM Usage Before Downloading a Local AI Model
• Ollama Out of Memory: VRAM, RAM, Context and Quantization Fixes