--- title: Using with AI (MCP) sidebar_label: Overview description: "Connect Claude or ChatGPT to the CLIKA Platform and ask about your devices and benchmarks in plain words: which page to follow for your app, the API key it needs, what it can and cannot do, and the endpoint details for advanced users." --- Connect an AI assistant such as Claude or ChatGPT to the CLIKA Platform, and you can ask it about your devices and benchmarks in plain words, or have it start a benchmark and summarize the results for you. The connection uses MCP (Model Context Protocol), the standard way an AI assistant uses tools outside itself. You do not need to know how it works to use it. ## Pick your app Desktop apps, no terminal needed: - [Claude Desktop](claude-desktop.md): add an extension you download from the platform. - [ChatGPT Desktop](chatgpt-desktop.md): add the platform in ChatGPT Desktop's Settings. Developer tools: - [Claude Code](claude-code.md): one `clika-cli` command, or `claude mcp add`. - [Codex](codex.md): one `clika-cli` command, `codex mcp add`, or an entry in `config.toml`. - [Other clients](other-clients.md): any MCP client that connects to a URL. Each page takes you from nothing to a first answer, and ends with how to remove the connection again. ## What you can ask Once connected, ask the way you would ask a colleague: > Which of my Clika Platform devices are online? > 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. The assistant does what the [tutorial](../getting-started/first-benchmark/05-run-a-benchmark.md) walks through by hand. A quick LLM Performance run of a small model on a two-core device takes about fifteen minutes, five of them sending the engine to the device, so ask the assistant to check on the run once a minute, and start the first run a minute after the device enrolled. ## What it can and cannot do The assistant can read your devices and their health, run a command on a device, move files to and from it, browse your models and artifacts, start a benchmark, follow it to the end and read its results. It can only do what its API key allows, and every request it makes is checked exactly like one from the web application. A key made from the **Worker** template can look at devices and run benchmarks, but cannot change members or licenses. Some things stay yours to do, in the web application: - Create an API key, or invite or remove a member of the organization. - Issue, rotate or revoke a runtime license. - Register a new device (**Devices**, then **Register Device**), unless the key holds `devices:write`: see [Where the tools stop](#where-the-tools-stop). ## You need an API key Every app connects with an API key. Each app's page walks you through making one; in short: 1. Sign in to the CLIKA Platform and open **Settings**, then **Developer access**. 2. Press **Create key**. Give it a name that says what will use it (`claude-desktop`, `chatgpt-desktop`), choose the **Worker** template under **Start from a template**, and press **Create**. 3. Copy the key. It is shown only once, and it stops working 90 days after you created it. [Manage members and API keys](../how-to/manage-members-and-api-keys.md#mint-an-api-key) covers the templates and permissions in full. ## For advanced users ### The MCP endpoint and its toolsets Each deployment serves MCP over Streamable HTTP at `/api/mcp`, where `` is the address you open in the browser. A toolset is a named selection of the same tools for one kind of work, served at its own path below the endpoint. | Endpoint | What it serves | | --- | --- | | `/api/mcp` | Every documented operation outside the platform administration API (`/api/admin/**`), which no MCP surface serves. | | `/api/mcp/api-key` | The operations an API key can be granted. Sign-in flows, the capabilities only a browser session can hold (users, roles, SSO, license and billing changes) and multipart-only uploads are served on `/api/mcp` only. | | `/api/mcp/device-ops` | Day-to-day device work: list and inspect devices, read health, run a command, transfer files, browse artifacts. | | `/api/mcp/benchmark-ops` | The 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/toolsets` | The toolsets this deployment serves, with a description of each. | A deployment serves a toolset only when its API carries every operation the toolset names. Ask a deployment what it serves: ```bash curl -H "Authorization: Bearer $CLIKA_API_KEY" https://platform.clika.io/api/mcp/toolsets ``` A toolset decides which tools are listed. It is not a permission boundary: every call is checked against the key whichever endpoint it arrives on, and each caller's tool list holds the tools its key can call. To limit what an assistant may do, scope its [API key](../how-to/manage-members-and-api-keys.md#scopes-and-why-a-key-can-never-exceed-you). MCP requests authenticate like REST requests, with `Authorization: Bearer `. Do not give an assistant your browser session token: it expires, and it carries all of your permissions. ### Where the tools stop - Registering a device takes `devices:write`, which only an organization owner's or admin's key carries. With it, `device-ops` and the full endpoint have the two tools: `post_enrollment_tokens` mints a token (its body needs a `name`), and `get_install` with that token and the operating system returns the one-line install command to run on the machine. `benchmark-ops` has neither. - `get_jobs_id_benchmark_results_samples` carries a sample's index, latency and status; its question and answer text is in `get_jobs_id_benchmark_results_io`. `benchmark-ops` serves both. A run with only LLM Performance has no samples, so both answer empty lists for it. - A tool call is sent as JSON, so an operation that takes only a `multipart/form-data` upload cannot be called as a tool; its tool description says so. A file still reaches the platform through the chunked upload session (`POST /api/artifacts/uploads` with the size and SHA-256, then one base64-encoded chunk per call), through an external source the platform fetches itself (`POST /api/artifacts/external`), or through a JSON sibling tool that references an artifact already uploaded. - A refusal names its reason. A tool outside the key's scope answers that it `requires the capability, which this credential does not hold`; one that takes a signed-in session answers that it `takes a user session`; one outside the toolset you connected names the endpoint that serves it. `unknown tool` means no tool has that name. ### The CLIKA CLI The CLIKA CLI serves the same tools over standard input and output with [`clika-cli mcp`](../cli/mcp.md), the `api-key` toolset unless `--toolset` names another one. `clika-cli mcp install` writes a client's configuration for you and keeps the API key out of the client's files: the entry names a CLIKA CLI profile, and the CLIKA CLI hands the key to the client when it connects, so a new key needs a new `clika-cli login` and no change to any client. [Get started with the CLI](../cli/get-started.md) installs the CLIKA CLI, and its installer can register the clients in the same step. ## Related pages - [Troubleshooting](troubleshooting.md): a refused key, a self-signed certificate, a client that does not show the tools. - [MCP server and generic dispatch](../cli/mcp.md): the `mcp` command, its flags, and `mcp install`. - [Manage members and API keys](../how-to/manage-members-and-api-keys.md): scoping the key an assistant uses.