MCP server and generic dispatch

The Model Context Protocol, MCP, is a standard way for an AI assistant to call external tools. clika-rt mcp turns the CLI into an MCP server, so an assistant such as Claude Code or Cursor can read your devices, launch a benchmark and fetch its results by calling tools rather than by shelling out.

tools and call are the same machinery exposed to you directly. tools lists every operation by its tool name, and call invokes one. They are useful for scripting, for reaching an endpoint that has no convenient subcommand, and for reproducing by hand exactly what an assistant did.

Setting up a Claude client end to end is covered in the how-to guides; this page documents the commands and their flags.

mcp

clika-rt mcp [flags]

Runs an MCP server on standard input and output. You do not run this at a terminal yourself. You configure an AI harness to launch it, and the harness speaks the protocol over the pipe.

Every documented platform operation is exposed as a tool with a JSON schema, except the platform administration API (/api/admin/**), which no toolset serves.

Flag	Type	Default	Meaning
--toolset	string	full	Which named toolset to serve.
--remote	bool	false	Proxy to the orchestrator's own HTTP MCP endpoint instead of dispatching from the embedded API description.

The global flags all apply, and the ones that matter here are --profile, --token, --api-key, --base-url and --insecure-tls, because the server authenticates to the platform exactly as any other command does.

clika-rt mcp
clika-rt mcp --toolset device-ops
clika-rt mcp --profile onprem --insecure-tls
clika-rt mcp --remote --profile onprem --insecure-tls

Toolsets

The full surface is several hundred tools, and an assistant pays a discovery and context cost for every one of them, most of which it will never call. A toolset serves a curated subset instead.

Toolset	What it covers
full (default)	Every documented operation except the platform administration API.
device-ops	Day-to-day device work: list and inspect devices, read health, run commands, push and fetch files, browse artifacts.
benchmark-ops	Benchmark runs end to end: the type catalog, the model pool, the compatibility check, picking registered or hosted targets, launching a group, polling it, reading results.

Ask a deployment what it serves:

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

A toolset is only offered where the product's API covers all of it, and an unknown or unavailable name fails with the servable names listed.

A toolset is not a permission boundary. It changes only which tools are listed. Every call still passes the platform's full authentication, licensing and permission checks, and a client that already knows a tool name can call it through the full endpoint. To restrict what a credential may do, scope the API key instead. See authentication.

Local mode versus --remote

By default the CLI answers from its own embedded copy of the API description, and dispatches each call as an HTTP request to the platform. That works everywhere, including against a self-signed on-premise deployment, because the CLI terminates TLS itself and --insecure-tls is scoped to its own connections.

With --remote, the CLI instead proxies to the orchestrator's Streamable HTTP MCP endpoint at /api/mcp, fetching the tool list from the server when it connects. Two consequences:

• The tool surface follows the server. A platform that gains an operation exposes it immediately, with no CLI update.
• --insecure-tls is scoped to one connection. This is the reason --remote exists. An MCP host that cannot be told to trust a self-signed certificate can point at the local CLI instead, and the CLI makes the one connection that needs the exception. The blunt alternative, disabling certificate verification for the host's entire process, is worth avoiding.

--toolset composes with --remote, selecting the server's /api/mcp/<toolset> endpoint.

Connecting without the CLI at all

Each orchestrator serves the same tools directly over Streamable HTTP at POST /api/mcp, built from its own copy of the API description. A tool call is dispatched in-process back through the API router, so it passes the same authentication, licensing and permission checks a direct API request would. The endpoint is stateless, and a request without a valid credential is rejected before the MCP handler runs.

Point any HTTP MCP client at it with a session token or a clika_ API key in the Authorization header. Where the deployment uses a self-signed certificate, the client, not the CLI, is the one that has to trust the certificate authority, which is exactly the case mcp --remote exists to rescue.

tools

clika-rt tools [flags]

Lists every documented operation as <tool-name> <METHOD> <path>. The tool name is what call takes, and what an MCP tools/call takes, so this is how you find the name for an operation you can see in the API.

Flag	Type	Default	Meaning
--tag	string	none	Filter by the operation's API tag, for example devices or jobs.

$ clika-rt tools --tag devices
get_devices               GET     /api/devices
post_devices              POST    /api/devices
get_devices_id            GET     /api/devices/{id}
put_devices_id            PUT     /api/devices/{id}
delete_devices_id         DELETE  /api/devices/{id}
post_devices_id_exec      POST    /api/devices/{id}/exec

clika-rt tools | wc -l
clika-rt tools --tag jobs

call

clika-rt call <tool-name> [key=value ...] [flags]

Invokes one operation by tool name, with flat key=value arguments. Path and query parameters come from the API description; the request body is body=<json> or body=@path/to/file.json.

Flag	Type	Default	Meaning
--raw	bool	false	Print the response body byte for byte, with no pretty-printing.

clika-rt call get_devices
clika-rt call get_devices_id id=1f0a2b3c-4d5e-6f70-8192-a3b4c5d6e7f8
clika-rt call post_job_definitions body=@./job-def.json
clika-rt call post_models body='{"huggingface_url":"Qwen/Qwen2.5-0.5B-Instruct"}'

call uses the same dispatch path as the MCP server, so call <tool> and an assistant's tools/call <tool> produce identical results. That makes it the right way to reproduce something an assistant did, or to check what a tool will return before handing it to one.

For everyday use prefer the resource subcommands. clika-rt devices list is call get_devices with tables, filters as flags and name resolution added.

What an assistant sees

A tools/list returns every tool with its input schema. A tools/call dispatches the matching HTTP request and returns the response body as text, pretty-printed when it is JSON. A non-2xx response comes back as an in-band error result rather than a protocol failure, so the model can read the message and correct itself.

Operations that require a multipart/form-data upload are flagged in their tool descriptions. An assistant cannot perform those; use artifacts upload or devices push from the CLI instead. See artifacts and devices.

Full command reference

Every command below is generated from the deployment's own API description, so one subcommand is exactly one platform operation. Each entry names the method, the endpoint and the MCP tool name, so the same operation is identifiable whichever surface you drive it from. Path parameters are positional arguments, query parameters are flags, and a request body is --body or --body-file. The hand-written commands, the ones that stream, propagate an exit code, or hand your terminal to ssh, carry no operation line.

The prose above covers the commands most people reach for. This section is the complete surface, for when you need the flag you have not used before.

clika-rt mcp

clika-rt mcp

Runs a Model Context Protocol server on stdin/stdout that exposes every documented platform operation as a tool, except the platform-admin API (/api/admin/**), which no toolset serves, the generated CLI subcommands keep it. Configure an AI harness (Claude Code, Cursor...) to launch this command as its MCP server; the harness then calls tools to read devices, run benchmarks, etc.

clika-rt mcp [flags]

Flag	Type	Default	Meaning
--remote	bool	false	proxy to the orchestrator's HTTP /mcp endpoint instead of the embedded bundle
--toolset	string	"full"	named toolset to serve (e.g. device-ops); 'full' serves every documented operation outside the platform-admin API

clika-rt tools

clika-rt tools

Lists every documented operation as <tool-name> <METHOD> <path>. The tool name is what call and an MCP tools/call take.

clika-rt tools [flags]

Flag	Type	Default	Meaning
--tag	string	none	filter by OpenAPI tag (e.g. devices, jobs)

clika-rt call

clika-rt call

Invokes the named tool (see the tools subcommand). Arguments are key=value pairs. Path/query parameters come from the spec; the request body is provided as body=<json> or body=@path/to/file.json.

clika-rt call <tool-name> [key=value ...] [flags]

Positional arguments: required <tool-name>; optional [key=value ...].

Flag	Type	Default	Meaning
--raw	bool	false	print raw response without pretty-printing

Related

• How-to guides: configuring Claude to use this server, step by step.
• Authentication and profiles: the credential the server presents, and scoping an API key.
• CLI overview: how the CLI, the API and MCP relate to one another.