# Connect to Lys

Inspect the installed CLI and connect to the intended identity service.

The CLI identifies its own build. The service's public health and OpenAPI describe the running API. Access to a person's or agent's records requires admission beyond those public reads.

## Check the executable

**Inspect the installed CLI**

```bash
lys --version
lys --help
lys identity --help
lys mcp --help
```


The version includes the source commit. The identity command groups deployment operations; reading its help performs none of them. Do not install another service just to sign in to an existing one.

## Find the service

Open the address supplied by the operator. A deployment serving its screens mounts the API beneath the API prefix shown here. Individual paths in [HTTP operations](/lys/reference/http/) are relative to that mount.

**Public health and schema**

```text
GET /api/health
GET /api/openapi.json
```


A health response proves that the directory service answers. It does not prove the permission engine, model provider or every runner can perform work.

## Use the intended identity

A person follows the configured sign-in flow. An agent uses its own enrolled key and identifier. Keep credentials in their private files and give tools paths to those files. The local signed MCP bridge accepts a numeric loopback HTTP address; it is not a general remote HTTPS client.

## If access is refused

Retain the refusal name and reason. A missing sign-in, mismatched key and missing permission need different corrections. Follow [Access and refusals](/lys/operations/access-and-refusals/).