Goose: the MCP-native, on-machine AI agent that talks to anything with a server

👁️ — views

Goose is an Apache-2.0 general-purpose AI agent (CLI, desktop, API) that runs on your machine. New capabilities come from Model Context Protocol extensions, not a closed plugin store, and governance now sits with the Linux Foundation.

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

What it is

Goose is a general-purpose, on-machine AI agent that ships as a CLI, a native desktop app, and an embeddable API. It is not just autocomplete or a chat box: it runs shell commands, edits files, executes code, and chains multi-step workflows toward a goal you give it in plain language. The repo’s one-line tagline reads “your native open source AI agent — desktop app, CLI, and API — for code, workflows, and everything in between.”

The project is open source under the Apache-2.0 license and written primarily in Rust. It began at Block (the Square/Cash App company) under the codename “goose,” but in a notable governance move it has since migrated to the Agentic AI Foundation (AAIF) at the Linux Foundation — the canonical repo now lives at aaif-goose/goose. As of this writing the GitHub repo sits at roughly 48,100 stars, and the latest release, v1.37.0, is dated June 3, 2026 — days before I checked it, so this is a live, fast-moving project. It connects to a broad set of model providers (Anthropic, OpenAI, Google, Ollama, OpenRouter, Bedrock, and more) rather than locking you to one vendor.

Why the architecture is interesting

The defining bet is that capability should come from an open protocol, not a proprietary plugin catalog. Goose was one of the earliest and deepest adopters of the Model Context Protocol (MCP), the open standard for exposing tools and data to agents. Its repo advertises connecting to 70+ extensions via MCP, and the consequence is large: any service that ships an MCP server — GitHub, Jira, Slack, a database, a monitoring dashboard — becomes available to Goose without the maintainers writing a bespoke integration for each one. The agent’s reach grows as the ecosystem grows, not as one company’s roadmap allows.

The second structural choice is governance. Moving the project under a neutral foundation means its direction is no longer subject to a single vendor’s commercial priorities — a real consideration if you are betting infrastructure on an agent. Compare the two postures:

The honest reading: the same openness that makes Goose powerful also widens its blast radius. An agent that runs shell commands and connects to arbitrary third-party MCP servers can reach a lot, which is exactly why the trust boundary deserves thought.

Install and run

The install command shown on the project’s own site and README is a curl-to-bash bootstrap of the CLI:

# install the goose CLI (verbatim from goose-docs.ai / the repo README)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# then configure a provider + model and start a session
goose configure
goose session

As always with a curl | bash installer, read the script before piping it to a shell if you are at all unsure — it is fetched from the project’s GitHub releases, but the habit is worth keeping.

Practitioner note

What I would actually do: stand up Goose with a deliberately small set of MCP extensions first, not the whole catalog. The temptation is to wire in everything — GitHub, Slack, your database, your cloud — on day one. I would instead start with the built-in developer (shell + file edit) extension on a throwaway branch, watch how the agent plans and acts, and only add a remote MCP server once I understand what credentials and scopes it demands. Each extension you enable is new attack surface and a new set of secrets in your environment; treat “add an MCP server” with the same care you’d treat adding a dependency. The interruptible session helps here — keep a hand on the wheel for the first few runs rather than letting it free-run against anything that matters.

I reach for an agent like this specifically when a task spans tools, not just files: reproduce a CI failure, query a real datastore, file the PR, ping a channel. That cross-tool reach is where the MCP model earns its keep over a pure code-editing agent.

Under-considered angle

The headline is “open agent,” but the quieter, more consequential shift is where the lock-in moves to. By decoupling the agent from any one model vendor and any one plugin store, Goose doesn’t eliminate dependency risk so much as relocate it onto the MCP ecosystem itself — the servers, their auth models, and their maintenance health. A team that builds its workflows around a dozen third-party MCP servers has traded vendor lock-in for a diffuse supply-chain dependency: each server is code someone else ships, with its own update cadence, security posture, and odds of going unmaintained. That is arguably a better place to be — open standards beat closed ones — but it is not no dependency. The teams that win with Goose will treat their enabled MCP servers like production dependencies: pin them, review them, and know which ones they could not live without. Governance by a foundation solves the agent’s neutrality; it says nothing about the longevity of the long tail of extensions you bolt onto it.