---
title: Troubleshooting
description: "What to do when an MCP client is refused with a 401, cannot verify a self-signed certificate, or does not show the platform's tools after a change."
---

## A 401, or "not logged in"

`clika-cli mcp install` checks the profile's API key with one request to the deployment before it writes anything. It stops when the profile has no saved key, when the profile belongs to a different deployment than `--base-url`, or when the deployment answers 401. At a terminal it offers to log in on the spot. Without one, it prints the exact command to run, for example `clika-cli --base-url https://platform.clika.io login --profile default`. Run it, then run `mcp install` again.

A client that connected before and is now refused is presenting a key the deployment refuses, because the key was revoked, its owner's account is suspended or was removed from the organization, or the organization was deleted; all four answer the same `401 invalid or expired token`. Create a new key and save it with `clika-cli login`. Entries written by `mcp install` read the key from the profile, so they need no change. A key written into a client's own config (`claude mcp add`, a hand-written `Authorization` header, the Desktop Extension) has to be replaced there.

When a client reports that the server failed to start or to connect right after `mcp install`, run the header command the entry uses, `clika-cli --profile default mcp headers`. It prints the `Authorization` header from the profile, or says that the profile holds no key and which `login` command fixes it.

## A self-signed certificate (on-premise)

A client that connects over HTTP has to trust the deployment's certificate. Trusting the deployment's certificate authority in the client is the preferred fix. Claude Code, for example, reads extra authorities from `NODE_EXTRA_CA_CERTS`.

Where that is not possible, let the CLIKA CLI make the connection. With `--insecure-tls`, `mcp install` writes an entry that runs the CLIKA CLI as a local bridge to the deployment, `clika-cli --profile onprem --insecure-tls mcp --remote`, for every client:

```bash
clika-cli mcp install claude-code --profile onprem --insecure-tls
clika-cli mcp install codex --profile onprem --insecure-tls
```

The CLIKA CLI then skips certificate verification for its own connection to the deployment and for nothing else, which is why `mcp --remote` is the scoped exception: the alternative is switching off verification for the whole client process. A profile does not record `--insecure-tls`, so pass it to `mcp install` as well (or set `CLIKA_INSECURE_TLS=1`). Without it the key check fails with a certificate error and the message says to add the flag.

The Desktop Extension has no option to skip verification. On such a deployment, register Claude Desktop with `clika-cli mcp install claude-desktop --insecure-tls` instead.

## The tools do not appear after a change ("restart it")

A client reads its config when it starts. When `mcp install` or `mcp uninstall` finds the client running, it prints one line naming it, for example:

```
Claude Desktop is running; restart it to load "clika-platform".
```

Restart it, then start a new conversation. When the client is not running, nothing is printed and the change applies the next time it starts.

## Other refusals

- `mcp install` refuses a name that an entry it did not write already uses, and changes nothing. Pass `--name` to register under another name.
- A warning that the CLIKA CLI runs from a temporary location means the entry would point at a binary that is about to disappear, for example one built by `go run` or started from the system's temporary directory. Install the CLIKA CLI ([Get started with the CLI](../cli/get-started.md)) and run `mcp install` from the installed binary.
- A toolset endpoint that answers with an error naming the servable toolsets is not carried by this deployment, because its API lacks one of the operations the toolset names. Use one of the names it lists, or `/api/mcp`.