Skip to main content

Use Kumoto with MCP

Kumoto’s Model Context Protocol (MCP) server lets an authorized AI client work with your Kumoto infrastructure. It is useful when you want to build a project, configure components, or follow a deployment through a natural-language workflow instead of performing each dashboard action manually.

MCP is a companion to the dashboard, not a replacement for careful review. Use it to accelerate routine work, then confirm the proposed project state and deployment outcome just as you would in Kumoto itself.

Connect an MCP client​

Kumoto is a remote MCP server. Use the connection instructions for your AI client below. Every client uses the same endpoint:

https://mcp.kumoto.app/mcp

When the client first uses Kumoto, it opens the Kumoto sign-in and authorization flow. Your account must have access to the projects and servers you want the client to use.

Claude Team and Enterprise​

An Owner or Primary Owner must add Kumoto as a custom connector before members can use it, including in Claude Desktop:

  1. In Claude, open Organization settings → Connectors.
  2. Select Add, then choose Custom → Web.
  3. Enter https://mcp.kumoto.app/mcp and finish adding the connector.
  4. Each member can then open Customize → Connectors, find Kumoto, and select Connect to sign in to their own Kumoto account.

The organization administrator controls whether the custom connector is available. Each member authorizes it with their own Kumoto account, so the client can act only on infrastructure available to that account.

Claude Pro and Max​

Open Customize → Connectors, select Add custom connector, enter the Kumoto endpoint, and complete the sign-in flow.

tip

Connect the client with the same care you would use for a deployment credential. It can act on infrastructure available to your account, so use your own account and do not share its authenticated session.

What an AI client can do​

An authorized client can help you:

  • Find projects, servers, component types, and connected repositories.
  • Create a project and assemble its infrastructure draft.
  • Add, update, connect, and remove components.
  • Set application variables and secrets.
  • Start a project deployment and follow its status.

The client can act only on infrastructure available to your Kumoto account. Secret values can be set, but Kumoto never returns their existing values to the client.

A safe workflow​

  1. Ask the client to inspect available projects, servers, repositories, and component options before it creates anything.
  2. Have it build or update the project draft, including component targets and connections.
  3. Ask for a concise summary of the intended change and inspect the resulting project canvas in Kumoto.
  4. Start a deployment only after you are satisfied with the draft and its target servers.
  5. Follow the deployment status and logs until it succeeds or you have identified the problem.

This approach is particularly helpful for multi-component applications: you can describe the desired architecture, then review the concrete components, variables, and links that the client created.

Give precise instructions​

An MCP client works best when you provide the constraints that matter. Include the project name, target server, application type, source revision, and any service dependencies. For example:

Create a project named website. Add a Node.js application on production-app-1, use the main branch of the selected repository, add PostgreSQL, connect it to the application, and show me the draft before deploying.

Avoid vague requests such as “make this production-ready” when a change could affect existing infrastructure. Ask the client to inspect first and propose a plan before it performs a destructive or wide-reaching action.

Verify deployments​

Deployments started through MCP are asynchronous: asking the client to deploy means the rollout was queued, not that it completed. Ask it to check the deployment status, and use the dashboard's Deployments tab for the full task history and logs.

Protect your account​

Review proposed changes before approving them and revoke client access when it is no longer needed. For changes involving secrets, domains, databases, or server removal, use the dashboard review and deployment history as your final confirmation.