Skip to main content

​
What Monk MCP Does

Monk can expose itself as an MCP server so other coding agents can call Monk directly from the same project context. That means you do not need to choose between your coding agent and Monk. You can use:
  • your coding agent for building and changing application code
  • Monk for deployment, infrastructure, connected services, runtime operations, monitoring, scaling, and cost visibility

​
Why This Matters

Most coding agents are strongest when working on source code. Monk is strongest when turning that source code into a running system. Through MCP, your coding agent can delegate operational tasks to Monk without forcing you to:
  • switch tools
  • copy context between chats
  • hand-edit agent config files
  • leave unwanted configuration files behind in every repo

​
How the Mechanism Works

When you enable Monk MCP for a workspace, Monk starts a local MCP server from the Monk extension running in your IDE. Monk then writes native MCP configuration for the selected clients:
  • VS Code / GitHub Copilot: .vscode/mcp.json
  • Claude Code: project-local entry in ~/.claude.json
  • Gemini / Antigravity: .gemini/settings.json
  • Codex: .codex/config.toml
  • Cursor / Windsurf: .cursor/mcp.json
These settings are managed per workspace, not globally for every project on your machine. The client still decides whether Monk is visible and usable. Depending on the client, you may still need to trust the server, enable it in an MCP settings screen, or approve tool usage in chat.

​
Workspace-Based by Design

Monk stores MCP enablement and target selection per workspace because different projects often need different agent setups. That is useful when:
  • one repo should expose Monk to Codex and Claude
  • another repo should only expose Monk to Gemini
  • a third repo should use Monk only through the built-in Monk chat
Each IDE window runs its own Monk MCP server for the active project context, which keeps connections isolated and predictable.

​
Cleanup Behavior

Monk is designed to be unobtrusive. When Monk MCP is disabled:
  • Monk removes only Monk-owned entries from the generated MCP config
  • unrelated MCP servers in those files are preserved
  • if Monk was the only entry, the empty config file is deleted automatically
This avoids the common problem of agent integrations leaving junk files behind after you stop using them.

​
What Other Agents Can Ask Monk To Do

Once connected through MCP, a coding agent can use Monk to:
  • inspect the project and explain what infrastructure it needs
  • deploy a service or full multi-service application
  • provision databases, queues, caches, and third-party services
  • configure networking, domains, TLS, and secure service-to-service wiring
  • inspect logs, health, and runtime state
  • scale workloads and optimize cost
  • migrate workloads between clouds or hosting models
In short, the coding agent handles code work, and Monk handles operational work.

​
Typical Workflow

  1. Build or modify the application with your coding agent
  2. Ask that agent to use Monk to analyze deployment needs
  3. Let Monk provision services and deploy the stack
  4. Ask Monk for logs, status, scaling, or cost follow-up
This creates a much smoother path from local development to production operations.

​
How To Enable It

To enable Monk MCP for a project:
  1. Open the project in an IDE where Monk is installed
  2. Run Monk: Manage MCP Server
  3. Enable the MCP server for the workspace
  4. Choose Smart defaults or a custom target list
For the full tutorial, see MCP Getting Started.