MCP server
Let an AI agent analyze projects, write manifests, plan deployments and, if you allow it, approve them, over the Model Context Protocol.
loomctl mcp serves Loomplane's tools over the Model Context Protocol on standard input and output. An agent such as Claude Code can analyze a project, write its loomplane.yaml, plan a deployment, read what the plan would do and, if you let it, approve it.
Set it up
Make an API key under Settings, API keys, then add loomctl to your agent's MCP configuration:
{
"mcpServers": {
"loomplane": {
"command": "loomctl",
"args": ["mcp"],
"env": {
"LOOMPLANE_URL": "https://loomplane.example.com",
"LOOMPLANE_API_KEY": "lp_live_..."
}
}
}
}For Claude Code, the same thing in one command:
claude mcp add loomplane --env LOOMPLANE_URL=... --env LOOMPLANE_API_KEY=... -- loomctl mcpStart with a read-only key if you only want an agent to look around.
The tools
| Tool | What it does |
|---|---|
whoami | Who the key acts as, and its permissions |
list_projects | The organization's projects |
analyze | Reads a project's repositories, or the ones named in sources, and waits until each is done |
get_manifest, draft_manifest, save_manifest | Reads, drafts and saves loomplane.yaml |
create_plan, list_plans, get_plan, reject_plan | Plans an environment and reads the result. scope names the repositories a plan moves, and the rest stay as deployed |
list_deployments, get_deployment, deployment_for_plan | Follows deployments step by step |
status | What runs where, with addresses and drift |
list_variables, set_variable | Variables. A secret's value is never shown |
approve_plan, retry_deployment | Only with --allow-deploy |
The manifest's JSON schema is available as the resource loomplane://schema/loomplane.yaml, so an agent writing one knows every field. A manifest that doesn't parse comes back as an error listing each problem with its line, which the agent can fix and save again.
What an agent can't do
Three things decide what an agent may do, and all three have to agree.
The key comes first. An agent acts as the person who made its key, with their role, in one organization. A read-only key can list, read and follow, and the API refuses anything else whatever the agent asks.
Deploying is off by default. Without --allow-deploy an agent can analyze, edit the manifest and plan, and approving stays with a person in the dashboard or with loomctl approve. approve_plan and retry_deployment change your clouds, so they're only offered when you start the server like this:
"args": ["mcp", "--allow-deploy"]They're also marked destructive, for clients that ask before running such tools.
An approval names the plan's revision. approve_plan takes the revision the agent read with get_plan. If what's deployed changed since, the plan comes back stale and nothing happens, so an agent can't approve a plan it hasn't seen.
Everything an agent changes is in the audit trail under the person who made its key.
--allow-deploy with an admin's write key lets an agent change your clouds. Give agents a developer-role key and keep approval with a person unless you've decided otherwise.