Skip to main content

Set up MCP for Claude

The Model Context Protocol (MCP) is how an AI assistant discovers and calls tools that live outside it. An MCP server advertises a list of tools with typed inputs, the assistant decides which to call, and the server executes the call and returns the result. The CLIKA Platform serves its own API as MCP, so an assistant can list your devices, register a model, launch a benchmark and read the results without you writing an integration.

What is served​

Every documented platform operation is a tool, with one exception: the platform-admin API (/api/admin/**) is not served on any MCP surface. The generated CLI commands keep it, because the CLI is an administrator's tool and the MCP surface is the assistant's.

A toolset is a curated subset, served at its own endpoint. Toolsets exist to reduce noise: a smaller tool list costs an assistant less context and makes it likelier to pick the right tool. A toolset is not a permission boundary. Every call still goes through the platform's authentication, permissions and licensing, and a client that knows a tool name can call it on the full endpoint. Restricting what a credential may do is an API key scope, not a toolset.

EndpointWhat it serves
/api/mcpEvery documented operation outside the platform-admin API.
/api/mcp/device-opsDay-to-day device work: list and inspect devices, read health, run a command, transfer files, browse artifacts.
/api/mcp/benchmark-opsThe benchmark loop end to end: list benchmark types, check compatibility, list and register models, pick devices, launch a run, poll it, read its results and samples.
GET /api/mcp/toolsetsDiscovery. Lists the toolsets this deployment serves, with a one-line description and the tool count of each.

Ask a deployment what it carries before configuring anything:

curl -H "Authorization: Bearer $CLIKA_API_KEY" https://platform.clika.io/api/mcp/toolsets

Get a credential first​

MCP requests authenticate exactly like REST requests: Authorization: Bearer <credential>. Use an API key rather than your session token, and scope it to what the assistant should be able to do. A key carries a subset of its owner's permissions, so a key scoped to benchmarks and devices cannot touch members or licenses however the assistant is prompted.

An unactivated deployment answers the MCP endpoints with a licensing refusal, like the rest of the API.

Two ways to connect​

Over HTTP, to the deployment. The assistant talks to /api/mcp (or a toolset endpoint) directly. The tool surface follows the server, so a platform upgrade changes the tools with no client update.

Over stdio, through the CLI. clika-rt mcp runs an MCP server on standard input and output, dispatching to the platform from the bundle embedded in the CLI. Use this when the assistant cannot reach the deployment's HTTPS endpoint directly, or when the deployment uses a self-signed certificate: --insecure-tls scopes that trust to this one connection. Adding --remote proxies to the deployment's own endpoint instead of dispatching from the embedded bundle, which gets you the server's live tool surface through a local process.

clika-rt mcp                                  # every tool, from the embedded bundle
clika-rt mcp --toolset device-ops             # one curated toolset
clika-rt mcp --remote --profile onprem        # proxy to the deployment's own endpoint

The CLI takes its credentials the usual way: a saved profile (clika-rt login --profile onprem --api-key), or CLIKA_BASE_URL and CLIKA_API_KEY in the environment.

Claude Code​

Add the platform as an HTTP server for the project:

{
  "mcpServers": {
    "clika-rt": {
      "type": "http",
      "url": "https://platform.clika.io/api/mcp/benchmark-ops",
      "headers": {
        "Authorization": "Bearer clika_your_api_key"
      }
    }
  }
}

That file is .mcp.json in the project root, which Claude Code reads for project-scoped servers. Or add it from the terminal, which writes the same configuration for you:

claude mcp add --transport http clika-rt https://platform.clika.io/api/mcp/benchmark-ops --header "Authorization: Bearer clika_your_api_key"

The stdio form runs the CLI instead:

{
  "mcpServers": {
    "clika-rt": {
      "command": "clika-rt",
      "args": ["mcp", "--toolset", "benchmark-ops"],
      "env": {
        "CLIKA_BASE_URL": "https://platform.clika.io",
        "CLIKA_API_KEY": "clika_your_api_key"
      }
    }
  }
}

Claude Desktop​

Claude Desktop launches local MCP servers from claude_desktop_config.json (Settings, then Developer, then Edit Config). The stdio form is the one to use, with an absolute path to the CLI:

{
  "mcpServers": {
    "clika-rt": {
      "command": "/usr/local/bin/clika-rt",
      "args": ["mcp", "--toolset", "benchmark-ops"],
      "env": {
        "CLIKA_BASE_URL": "https://platform.clika.io",
        "CLIKA_API_KEY": "clika_your_api_key"
      }
    }
  }
}

Restart Claude Desktop after editing the file. The platform's tools then appear in the tool list of a new conversation.

A first prompt to try​

With benchmark-ops connected:

List the devices that are online, and the benchmark types that can run against Qwen/Qwen2.5-0.5B-Instruct. Then launch an LLM performance run of that model on the fastest online Linux device, wait for it to finish, and summarize tokens per second and time to first token.

Every step there is one tool call: the device list, the type catalog, the compatibility check, the run, the poll, the results. The assistant is doing what the tutorial walks through by hand.

Choosing a toolset​

Start with benchmark-ops or device-ops. Move to the full surface when the assistant needs something outside them, and expect a larger tool list to cost more context per turn. If a toolset endpoint answers with an error naming the servable toolsets, the deployment does not carry that one: its API surface is missing one of the operations the toolset promises, and the platform refuses to serve a partial toolset rather than quietly hiding tools.