Configuration
This is the critical step. You need to add the Gitea MCP extension to Goose's configuration file.
The Config File
Goose's configuration lives at ~/.config/goose/config.yaml. You'll add an entry under the extensions: section.
The Exact Entry
Replace:
https://YOUR_GITEA_INSTANCE with your Gitea server URL
YOUR_ACCESS_TOKEN with the token from Installation
Field Reference
| Field |
Value |
Notes |
type |
stdio |
Goose spawns the binary as a child process |
cmd |
/usr/local/bin/gitea-mcp |
Full path to the binary (see below) |
args |
-t stdio -H <url> -T <token> |
MCP transport mode, host, and token |
envs |
{} |
Empty — token is in args, not env vars |
timeout |
300 |
5 minutes for long-running operations |
bundled |
null |
Marks this as user-installed, not bundled |
available_tools |
[] |
Empty = allow all tools |
Why the Full Path for cmd?
Goose uses a SearchPaths resolver that calls the Rust which crate to find the command. The which crate only reliably resolves short command names (like npx, uvx) from PATH — it does not handle absolute paths well. However, the fallback in Goose's resolve_command function falls back to PathBuf::from(cmd), which works correctly with absolute paths.
If you prefer short names, you can use cmd: gitea-mcp — just make sure the binary is in a directory that which can find (PATH directories like /usr/local/bin).
Restart and Start a New Session
- Fully quit Goose (Cmd+Q on macOS)
- Relaunch Goose
- Start a brand new chat session — existing sessions cache their extension list and won't pick up the new extension
Verify It Works
In the new chat, ask Goose:
"List my Gitea repositories"
If Goose can list your repos via the MCP, the integration is working.
Diagnostics
If something goes wrong, check:
~/.local/state/goose/logs/server/ — goosed logs show extension loading errors
- Run
gitea-mcp -v to confirm the binary works
- Test the token:
curl -s -H "Authorization: token YOUR_TOKEN" https://YOUR_GITEA/api/v1/user
See Troubleshooting for more.