Skip to main content

​
What Monk MCP Does

Monk exposes itself as an MCP server so 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

The Monk plugin installs a local companion process, monk-agent, which serves the Monk MCP endpoint on http://127.0.0.1:7419/mcp. The plugin registers this endpoint with your coding agent through the host’s native plugin mechanism — Claude Code, Cursor, and Codex wire it up on install, and the Antigravity plugin writes a monk entry to ~/.gemini/config/mcp_config.json. Nothing is written into your project repositories. The host still decides whether Monk is visible and usable. Depending on the agent, you may need to approve tool usage in chat or complete a one-time MCP sign-in. Any other MCP-capable agent can connect to the same local endpoint once monk-agent is running, though the plugin hosts above are the supported paths.

​
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

Install the Monk plugin in your coding agent — the MCP connection is set up automatically as part of the install. See Install Monk.

Install Monk

Install the Monk plugin in your coding agent

Autonomous Deployment

Let Monk handle the full deploy pipeline