Skip to main content

Why Use Monk Through MCP

Monk can work alongside your coding agent so you can keep building the application with your preferred assistant while Monk handles deployment, infrastructure, runtime operations, monitoring, and cost visibility. This gives you a clean split:
  • Your coding agent focuses on code
  • Monk focuses on getting that code running and keeping it healthy

Before You Start

Make sure you have:
  • Monk installed in a supported IDE
  • A project open in that IDE
  • A coding agent that supports MCP, such as VS Code with GitHub Copilot, Claude Code, Gemini, Codex, Cursor, or Windsurf
If Monk is not installed yet, start with Installation.
Monk MCP is not enabled by default right now. For every client below, the first step is always to open the project in an IDE where Monk is installed and explicitly enable Monk MCP for that workspace.

Pick Your Client

Choose the client you want to connect to Monk:

Common Step 1: Enable Monk MCP

Every client setup starts the same way.

Open the Project in a Supported IDE

Open the project in VS Code, Cursor, Windsurf, Antigravity, or another VS Code-compatible IDE where Monk is installed. Monk activates per workspace, so the project you open here becomes the project context Monk will expose over MCP.

Enable Monk MCP

Open the command palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Windows/Linux) and run:
Monk: Manage MCP Server
Then choose:
Enable MCP server
Monk saves this choice in workspace settings, so you only need to enable it once per project.

Choose Which Clients Should See Monk

Monk will ask which client configs it should manage for the current workspace. You have two options:

Smart defaults

This is the easiest option. Smart defaults are intentionally broad compatibility defaults, not host-only defaults. Smart defaults configure:
  • VS Code / GitHub Copilot when Monk is running inside VS Code
  • Claude Code
  • Gemini / Antigravity
  • Codex
  • Cursor / Windsurf when Monk is running inside a Cursor-compatible IDE

Custom target list

Use this when you want different projects to expose Monk to different agents. For example:
  • one repo may only need Codex
  • another may need Claude and Gemini
  • another may use Monk only from the built-in Monk chat

What Enablement Does on the Monk Side

When you enable Monk MCP for a workspace, Monk does two things:
  1. Starts the local Monk MCP server for that workspace
  2. Writes or updates the selected client-specific MCP config files for that project
What this does not do is automatically approve Monk inside the client. Most clients still require one more step on their side, such as trusting the server, enabling it in an MCP settings screen, or allowing tool usage in chat.

Two Setup Patterns

There are two different ways to use Monk through MCP:

Embedded IDE clients

For VS Code / GitHub Copilot, Cursor, Windsurf, and Antigravity, the user does everything in that same IDE:
  • install Monk there
  • open the project there
  • enable Monk MCP there
  • allow or enable Monk from that IDE’s MCP UI
VSCode MCP Enablement

Standalone agents and companion clients

For Claude Code, Gemini CLI, and Codex:
  • keep Monk running in one supported IDE with the project open
  • open the standalone client in the same directory
  • verify that the client sees Monk through the generated project config

What Monk Configures Automatically

Monk writes client-native MCP settings for the current project:
  • Claude Code: project-local entry in ~/.claude.json
  • Gemini / Antigravity: .gemini/settings.json
  • Codex: .codex/config.toml
  • VS Code / GitHub Copilot: .vscode/mcp.json
  • Cursor / Windsurf: .cursor/mcp.json
Monk only manages its own entries. If you later disable Monk MCP, Monk removes only the Monk entry. If that file only contained Monk, the empty file is deleted automatically.