Goose, Block’s Open-Source Agent: What It Is and How It Uses MCP

Goose is an open-source AI agent that runs on your own machine as a desktop app, a command-line tool or an embeddable API. It began at Block and now lives under the Agentic AI Foundation at the Linux Foundation, with its code under the Apache 2.0 licence. It is not tied to one model: you point it at Anthropic, OpenAI, Google, a cloud platform or a local model. Everything it can do beyond chat comes from extensions, and every extension is an MCP server, so the same servers you use with Claude Code or Cursor plug straight into it. Recipes turn a working session into a reusable file you can share or run in a script. Choose it if you want an agent that is open, model-neutral and not limited to code.

What Goose is, and where it lives now

The project’s GitHub repository↗ (opens in a new tab) describes Goose as a native open-source agent, “desktop app, CLI, and API”, for code, workflows and everything in between, and says it is part of the Agentic AI Foundation (AAIF) at the Linux Foundation. Two things moved with that change, which matters if you are following older links. The repository is now aaif-goose/goose, and the old block/goose address redirects there. The documentation moved from Block’s GitHub Pages site to goose-docs.ai, and the old site now shows only a notice that Goose has moved. The Homebrew packages still carry the old name, block-goose-cli and block-goose.

• Desktop: native apps for macOS, Linux (DEB, RPM or Flatpak) and Windows.
• CLI: installed with a download script or Homebrew; goose session starts an interactive chat and goose run runs instructions or a recipe without one.
• API: the same agent embedded in other software.

# macOS or Linux
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash
# or: brew install block-goose-cli

goose configure     # choose a provider and model, add extensions
goose session       # start chatting in the current folder

Providers and models

Goose brings no model of its own. goose configure, or Settings → Models in the desktop app, connects it to a provider with an API key: Anthropic, OpenAI, Google, Azure, Amazon Bedrock, OpenRouter, Groq and many more, or a local model through Ollama or LM Studio. You can also define a custom provider for any endpoint compatible with the OpenAI, Anthropic or Ollama APIs. The repository adds that you can use an existing Claude, ChatGPT or Gemini subscription through ACP, where Goose hands its extensions to that agent as MCP servers.

Model choice has one hard limit. Goose’s provider documentation↗ (opens in a new tab) says it relies heavily on tool calling and currently works best with Claude 4 models, and that a model without tool calling can only chat, with all extensions switched off. A small local model that handles tools poorly will make Goose look worse than it is. Pairing it with Ollama is covered in MCP with local models via Ollama.

Extensions are MCP servers

An extension in Goose is an MCP server, nothing more exotic. Goose’s extensions guide↗ (opens in a new tab) says extensions are based on the Model Context Protocol, and splits them into two groups.

• Built in and on by default: Developer (files and shell), Analyze (code structure), Extension Manager (finds and enables other extensions during a session), Skills (loads skill instructions) and Summon (hands work to subagents).
• Built in but off until you enable them: Computer Controller, Memory, Todo, Chat Recall, Auto Visualiser, Apps, Code Mode, Tutorial and Top of Mind.
• Custom: any MCP server, added as a command-line extension (a local process over stdio) or a remote extension over Streamable HTTP. Remote extensions can sign in with OAuth; Goose registers itself with the server automatically where the server allows it.

You add a custom extension in the desktop app under Extensions → Add custom extension, through goose configure → Add Extension, or for one session with a flag. Extensions are stored in ~/.config/goose/config.yaml with a name, the command or URL, environment variables and a timeout in seconds. The guide also says Goose checks external extensions for known malware before activating them and blocks a match. That is a useful floor, not a review: a server with no known malware can still do more than you expect, which is the subject of MCP security risks.

# a local stdio server
goose session --with-extension "memory:npx -y @modelcontextprotocol/server-memory"

# a remote server over Streamable HTTP
goose session --with-streamable-http-extension "https://example.com/mcp"

# inside a running session
/builtin memory

Recipes and subrecipes

A recipe is a YAML or JSON file that packages instructions, an optional opening prompt, the extensions to load, parameters and model settings, so a workflow that worked once can be run again by you or anyone else. You create one in the desktop app from the Recipes panel or write the file yourself, run it with goose run --recipe release-notes.yaml, pass values with --params, and share it as the file or as a deep link from goose recipe deeplink. Parameters are filled into the text with {{ name }} placeholders.

A recipe can call other recipes. Goose’s subrecipes page↗ (opens in a new tab) says a main recipe lists them under sub_recipes, each with a name, a path and optional preset values, and that each subrecipe runs in its own session without the main recipe’s history, memory or state. Independent subrecipes can run in parallel. There is one limit to design around: a subrecipe cannot define subrecipes of its own.

version: 1.0.0
title: Weekly report
description: Summarise the week's merged work and open risks
instructions: Read the merged pull requests and write a short report for the team.
parameters:
  - key: team
    input_type: string
    requirement: required
    description: Team name
prompt: Write this week's report for {{ team }}.
sub_recipes:
  - name: risk_scan
    path: ./subrecipes/risk-scan.yaml

Permissions and modes

This is the setting to check before anything else. Goose’s permission modes page↗ (opens in a new tab) lists four, and says Autonomous is the default.

• Completely Autonomous (/mode auto): modifies files, uses extensions and deletes files without asking.
• Smart Approval (/mode smart_approve): approves low-risk actions itself and asks about the rest.
• Manual Approval (/mode approve): asks before using any tool or extension.
• Chat Only (/mode chat): talks, and uses no extensions and changes no files.

Switch in the desktop app from the mode button or Settings → Chat, in the CLI with /mode, or permanently through goose configure → goose settings → goose mode. On a machine with anything you cannot afford to lose, start in Smart Approval or Manual Approval, and loosen it once you have watched what your extensions actually do. Goose also reads project instructions: it loads AGENTS.md and then .goosehints from your working folder up to the repository root, plus a global ~/.config/goose/.goosehints, and the CONTEXT_FILE_NAMES variable changes which names it looks for.

Goose and Claude Code, honestly compared

• Models: Goose runs on almost any provider or a local model. Claude Code runs Claude, through Anthropic or a cloud provider.
• Scope: Goose is a general agent that happens to be good at code, with a desktop app for people who never open a terminal. Claude Code is built around a codebase, with checkpoints, hooks, subagents and IDE integrations.
• Starting mode: Goose starts Completely Autonomous, with no approval at all. Claude Code v2.1.283 and later starts terminal and VS Code sessions in auto, where a classifier reviews each action, and Manual is one keypress away.
• Reuse: Goose’s recipes are shareable, parameterised workflow files. Claude Code’s nearest equivalents are skills and custom commands. Both read AGENTS.md and both load Agent Skills.
• Openness: Goose is Apache 2.0 and community-governed. Claude Code is distributed under Anthropic’s terms.

Goose suits people who want one agent across models, including local ones, teams that want an open project they can audit and change, and anyone automating work that is not only code. Claude Code suits developers who live in a repository and want the most capable loop on Claude models. Many other agents are side by side in the best AI coding agents.

Giving Goose a task board

Because Goose speaks MCP over Streamable HTTP, a fenbs board is one more remote extension: add https://fenbs.ai/api/mcp and approve it in the browser, or send a token you issue under Settings with the scopes you choose. Goose can then read the next task, move it through To Do, Next Up, In Progress and Completed, record what it tested, and comment with what it changed, and History shows each change under its name. fenbs is deliberately small: there are no sprints, due dates or epics, so it suits a team that wants the work and who did it in one place, not a planning suite.