MCP Server

The Loha MCP server lets AI coding agents (Claude Code, Cursor, Claude Desktop, Windsurf) drive Loha from inside your editor. Ask your agent "why did the build fail?" and it pulls the failing step's logs and proposes a fix, without you leaving the editor.

It speaks the Model Context Protocol and is the agent-native sibling of the CLI: where you'd type loha deploy, an agent calls a trigger_pipeline tool. Every tool wraps one /api/v1 endpoint and uses your existing personal access token: there's no separate login.

It's a hosted service at https://mcp.loha.longtumlab.com/: nothing to install or run.

Rolling out

The hosted MCP endpoint is newly launched. If your workspace doesn't have access yet, ask your administrator or give feedback.

Connect your agent

Create a personal access token in the dashboard under your workspace's Settings → API Keys (scope it to what you want the agent to do: start read-only). Members, admins and owners can create one (guests cannot), where member self-service is enabled for the workspace; starting builds (triggers:run) needs the member role or higher.
Add the hosted server to your MCP client.

Claude Code:

claude mcp add --transport http loha https://mcp.loha.longtumlab.com/ \
  --header "Authorization: Bearer loha_xxxxxxxx"

Cursor / Claude Desktop / .mcp.json:

{
  "mcpServers": {
    "loha": {
      "type": "http",
      "url": "https://mcp.loha.longtumlab.com/",
      "headers": { "Authorization": "Bearer loha_xxxxxxxx" }
    }
  }
}

Your token determines which workspace the agent acts in and what it can do: scopes are enforced by Loha.

Tools

Tool	What it does
`whoami`	Show the workspace this token is bound to + its scopes
`list_repos`	List repositories, each with its last build status
`list_triggers`	List triggers (optionally for one repository)
`validate_pipeline`	Validate a `.loha.yml` against the real schema
`list_builds`	List recent builds (filter by repo, trigger, status, branch)
`get_build`	Build detail with per-step status and exit codes
`get_build_logs`	Build logs as structured, secret-redacted lines
`list_releases`	Which commit produced which image, and its digest
`trigger_pipeline`	Fire a manual trigger run (guarded)

Authentication

The MCP server uses the same personal access tokens as the CLI and API: it exposes nothing beyond the API the CLI already uses. The token travels as an Authorization: Bearer header on each request and is forwarded to /api/v1; the server never stores it. A request without a valid token is rejected.

An agent acts with exactly your token's permissions, nothing more. Because /api/v1 is already the surface the CLI talks to, the scope of the token you hand the agent is what makes it safe.

Give agents a read-only token by default

Create the agent's PAT with read-only scopes: builds:read, repos:read, pipelines:read. The agent can then inspect builds, read logs, and validate .loha.yml, but cannot start a build. Add triggers:run only when you specifically want the agent to trigger runs, and even then, runs stay guarded.

Rate limits

The hosted server throttles requests per token. If an agent exceeds the limit it receives a standard 429 with a Retry-After header (in seconds); well-behaved MCP clients back off automatically. The limit is generous for normal agent use: you only hit it with runaway loops. The platform's own API rate limits still apply underneath.

Guarded writes

trigger_pipeline starts a real build, so it is guarded: by default the agent gets a dry-run describing what it would do, and nothing is dispatched unless it explicitly confirms.

Agents act autonomously

Only grant a write scope (triggers:run) to a token you've decided should be able to start builds. With a read-only token, the guarded write tools simply can't dispatch: Loha rejects them.

How tools map to the API

Each tool is a thin wrapper over the public API:

Tool	Endpoint
`whoami`	`GET /api/v1/whoami`
`list_builds` / `get_build` / `get_build_logs`	`GET /api/v1/builds…`
`list_releases`	`GET /api/v1/releases`
`validate_pipeline`	`POST /api/v1/pipelines/validate`
`trigger_pipeline`	`POST /api/v1/triggers/{id}/run`

Because validate_pipeline runs the same parser the platform uses at build time, "valid in your editor" means "valid in the cluster."

Data sovereignty

When an agent reads build data (logs, commit metadata, branch names), that data enters the agent's model context, which may be processed outside Thailand depending on which model you use. Build logs are secret-redacted before they leave Loha, but review your organization's data-classification policy before pointing an agent at sensitive build output. See Sovereignty.

Feedback

The MCP server is new. Tell us what tools you want next. File an issue or reach out through your usual Loha support channel.

Connect your agent​

Tools​

Authentication​

Rate limits​

Guarded writes​

How tools map to the API​

Data sovereignty​

Feedback​