> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/connect-a-cli-assistant/configure-claude-code.md).

# Configure Claude Code

Connect the Claude Code CLI to your Datasentinel MCP server, sign in, install the Datasentinel Skill, and verify the configuration.

This page shows how to wire the [Claude Code](https://claude.com/product/claude-code) CLI to your Datasentinel platform

* Add the **MCP server**
* **Sign in** once
* Install the **Skill** that tells the assistant how to use it
* Check that everything is connected.

The same pattern applies to other MCP-and-Skill-capable assistants; the commands below are specific to Claude Code.

{% hint style="info" %}
The steps below follow Anthropic's documentation, last checked on 6 October 2026. Anthropic changes Claude Code often.
{% endhint %}

## Before you start

* Claude Code is installed and you can run `claude` from a terminal.
* Your Datasentinel MCP server is reachable over HTTPS at `https://<public-host>/mcp`.\
  See [MCP Server Setup](/manual/ai-connector/server-setup/mcp-server-setup.md) if it is not yet running.

{% hint style="warning" %}
**Name MCP servers with a `datasentinel-` prefix.**

Every Datasentinel MCP server you register must be named starting with `datasentinel-`, for example `datasentinel-production` or `datasentinel-staging`.\
The Skill discovers Datasentinel servers by this prefix, so a server named otherwise will not be picked up. Use a distinct suffix per platform when you operate more than one (`datasentinel-prod`, `datasentinel-eu`, and so on).
{% endhint %}

## Set it up

{% stepper %}
{% step %}

#### Add the Datasentinel MCP server

For the full reference, see Claude Code's [Connect Claude Code to tools via MCP](https://code.claude.com/docs/en/mcp) guide.

Register the server with the streamable-HTTP transport:

```bash
claude mcp add --transport http datasentinel-production https://<public-host>/mcp
```

Choose where the configuration is stored with `--scope`:

| Scope             | Stored in                    | Applies to                          |
| ----------------- | ---------------------------- | ----------------------------------- |
| `local` (default) | `~/.claude.json`             | You, in the current project only    |
| `project`         | `.mcp.json` at the repo root | The whole team, via version control |
| `user`            | `~/.claude.json`             | You, across all your projects       |

For a server you want available everywhere, add `--scope user`:

```bash
claude mcp add --scope user --transport http datasentinel-production https://<public-host>/mcp
```

{% hint style="info" %}
Prefer `--scope user` or `--scope local` over `--scope project`: a project-scoped server is written to `.mcp.json` and committed to the repository.
{% endhint %}

{% hint style="info" %}
**Sign in on first use.** The Datasentinel MCP server is protected by OAuth 2.1.\
Nothing else goes in the configuration: no token, no header.<br>

The sign-in is the next step. See [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md).
{% endhint %}

**Self-signed or invalid certificate**

If your platform serves the `/mcp` endpoint with a self-signed or otherwise invalid TLS certificate, Claude Code rejects the connection by default.

{% hint style="info" %}
Using a valid TLS certificate is **highly recommended**. Provisioning a certificate trusted by your host (from a public authority, or from an internal CA installed in the system trust store) keeps validation on and avoids the workaround below entirely.
{% endhint %}

{% hint style="warning" %}
As a last resort you can disable certificate verification entirely:

```bash
NODE_TLS_REJECT_UNAUTHORIZED=0 claude
```

To apply it to every session, export the variable from your shell startup file (for example `~/.bashrc` or `~/.zshrc`):

```bash
export NODE_TLS_REJECT_UNAUTHORIZED=0
```

Alternatively, set it in Claude Code's settings file (`~/.claude/settings.json` for all projects, or `.claude/settings.json` for one project) under the `env` key, which Claude Code applies to every session:

```json
{
  "theme": "light",
  "tui": "fullscreen",
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}
```

This turns off TLS validation **process-wide** (the MCP server, the Anthropic API, and any web fetches).
{% endhint %}
{% endstep %}

{% step %}

#### Sign in to the platform

**With a browser**

Start an interactive `claude` session and open the MCP panel:

```bash
/mcp
```

Select the Datasentinel server, then choose **Authenticate**.\
Claude Code opens the Datasentinel login page in your browser: sign in with your **platform login and password**, the same ones as the Datasentinel web interface.\
The page names the assistant that is asking; after the sign-in the browser hands the session back to Claude Code, and the server shows as connected.

You sign in once. Claude Code renews the session by itself and asks again only after ten days without using the server, or when an administrator ends the session.\
Your password goes to the login page only; Claude Code never sees it and never asks for a token.

**Without a browser**

On a server without a browser (an SSH session, a build machine), run the sign-in in the mode that prints the link instead of opening a browser, then paste the address you are redirected to back into the terminal:

```bash
claude mcp login datasentinel-production --no-browser
```

The full procedure, including the SSH port-forward alternative, is in [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md#sign-in-from-a-server-without-a-browser).

**For a script or a scheduled run**

Where nobody can sign in, register the server with a user token as an authorization header instead.\
\
The token is the 24-hour [user token](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/implementation/platform-usage/api-reference/access-token) of the platform, read from an environment variable rather than written in the configuration:

```bash
claude mcp add --scope user --transport http datasentinel-production https://<public-host>/mcp \
  --header "Authorization: Bearer ${DS_TOKEN}"
```

A server registered with a header never opens the login page; when the token expires, the calls fail until a fresh one is set.\
See [Refresh the user token automatically](/manual/ai-connector/developers/refresh-user-token.md) to keep it current.
{% endstep %}

{% step %}

#### Install the Datasentinel Skill

For how Claude Code discovers and manages Skills, see its [Extend Claude with Skills](https://code.claude.com/docs/en/skills) reference.

The Datasentinel Skill is made of several files (a `SKILL.md` entrypoint plus supporting files) and ships as a single archive, `datasentinel-skill.zip`.\
Download it from <https://app.datasentinel.io/ds-api/download/datasentinel-skill.zip>.

Skills in Claude Code are file-based: there is no install command.\
Create the Skills directory if it does not exist yet, then unzip the archive into it so it produces a `datasentinel/` folder, and Claude Code discovers it on the next session.

{% tabs %}
{% tab title="Personal (all your projects)" %}

```bash
mkdir -p ~/.claude/skills/
unzip datasentinel-skill.zip -d ~/.claude/skills/
```

{% endtab %}

{% tab title="Project (shared via Git)" %}

```bash
mkdir -p .claude/skills/
unzip datasentinel-skill.zip -d .claude/skills/
```

{% endtab %}
{% endtabs %}

You should end up with `~/.claude/skills/datasentinel/SKILL.md` (or `.claude/skills/datasentinel/SKILL.md`) alongside the Skill's supporting files. Each Skill lives in its own directory whose `SKILL.md` is the entrypoint. Its frontmatter carries the `description` the assistant uses to decide when to apply the Skill:

```markdown
---
name: datasentinel
description: How to query Datasentinel metrics through the datasentinel-* MCP servers.
---

<instructions for using the Datasentinel MCP tools>
```

{% endstep %}

{% step %}

#### Check your configuration

List the configured servers and their connection status:

```bash
claude mcp list
```

A healthy entry shows `✔ Connected` with a tool count. A server you have not signed in to yet is listed as needing authentication: go back to the sign-in step. Other states you might see are `✘ Failed to connect` (check the URL and that the server is up), or `! Connected · tools fetch failed`.

Inspect one server in detail (transport, URL, status, tool count):

```bash
claude mcp get datasentinel-production
```

Inside an interactive `claude` session, you can also use the slash commands:

* `/mcp` opens a panel listing connected servers, their status and tool counts, and lets you authenticate or reconnect.
* `/skills` lists the loaded Skills, so you can confirm `datasentinel` appears.

To remove a server (optionally pin the scope if it exists at several levels):

```bash
claude mcp remove datasentinel-production
```

**Approve the Datasentinel tools**

The first time the assistant calls a Datasentinel tool, Claude Code asks for permission. Choose **Yes, and don't ask again** to save a rule for that tool, or add one rule for the whole server so no Datasentinel tool ever prompts. Rules name the server as registered, prefixed with `mcp__`; open `/permissions` to add it, or put it in `~/.claude/settings.json` for all your projects (`.claude/settings.json` for one project):

```json
{
  "permissions": {
    "allow": ["mcp__datasentinel-production"]
  }
}
```

A single tool is `mcp__datasentinel-production__get_platform_status`. The Datasentinel tools only read monitoring data, so allowing the whole server is safe. The same rule can be passed for one run with `--allowedTools "mcp__datasentinel-production"`. `--dangerously-skip-permissions` approves every tool of every kind, including shell commands and file edits; use it with care. The rule syntax is in Claude Code's [Configure permissions](https://code.claude.com/docs/en/permissions#mcp) reference.
{% endstep %}
{% endstepper %}

Once the server shows `✔ Connected` and the Skill appears under `/skills`, run through the checks below to confirm the end-to-end flow.

## How the Skill loads

The Datasentinel Skill loads on demand.\
Claude Code reads every Skill's name and `description` at startup, and pulls in the full instructions automatically when your request relates to Datasentinel: asking about PostgreSQL performance, instances, sessions, or the platform itself is enough.\
One Skill serves every platform, because it discovers all the `datasentinel-*` MCP servers you registered, so adding a second platform needs no Skill change.

If Claude answers generically instead (no Datasentinel tool calls in the response), load the Skill manually:

* Invoke it directly as a slash command: type `/datasentinel` followed by your request, for example `/datasentinel status`.
* Or name it in the prompt: `Use the datasentinel skill to check the platform status.`

If `/datasentinel` does not autocomplete at all, the Skill is not discovered: re-check the unzip location from the setup step and start a new session.

## Test the MCP server and Skill

Run these checks inside an interactive `claude` session.

First, confirm the Skill is loaded:

```bash
/skills
```

`datasentinel` should appear in the list. If it does not, re-check the unzip location from the previous step and start a new session.

Then exercise the MCP connection through the Skill's built-in commands. Run them in order:

| Command                   | What it does                                                                                             |
| ------------------------- | -------------------------------------------------------------------------------------------------------- |
| `/datasentinel help`      | Displays the Skill's help, listing the available commands.                                               |
| `/datasentinel platforms` | Lists every MCP server (platform) the Skill discovered by its `datasentinel-` prefix.                    |
| `/datasentinel status`    | Checks the platform status, confirming the MCP server answers and the sign-in is in place.               |
| `/datasentinel whoami`    | Shows who the session is connected as: platform, identity, privilege, real-time access, style, language. |

These four are the setup checks. The full command list, with what each one needs, is in the [Skill commands reference](/manual/ai-connector/use-the-assistant/skill-commands.md).

Start with `/datasentinel help` to confirm the Skill responds; it needs no sign-in. Then run `/datasentinel platforms` to verify your server is discovered: each `datasentinel-*` MCP server you registered should appear in the list.\
Run `/datasentinel status` to confirm the platform is reachable and the MCP tools return live data; if the server is not signed in yet, the Skill tells you how to do it.\
Finally, `/datasentinel whoami` confirms the account the session runs under and the communication style the assistant will use.

{% hint style="success" %}
If `/datasentinel status` reports a healthy platform, the MCP server and the Skill are wired together correctly. You can now ask the assistant questions about your instances in plain language.
{% endhint %}

{% hint style="info" %}
**Server not discovered? Ask the assistant to find the root cause.**

If `/datasentinel platforms` lists nothing, or your server is missing from it, ask Claude Code to debug the setup rather than hunting by hand. It can run `claude mcp list` and `claude mcp get`, read the configuration in `~/.claude.json` or `.mcp.json`, and probe the endpoint itself, so it usually pinpoints the cause in one pass.

Ask it something like:

```
The datasentinel-production MCP server is not discovered. Investigate and find the root cause: check my MCP configuration, the connection status of the server, and whether the /mcp endpoint answers.
```

Typical causes it surfaces: a server name that misses the `datasentinel-` prefix, a typo in the URL, a server registered in a scope this session does not load, a sign-in that was never completed, a rejected TLS certificate, or a platform that is down.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.datasentinel.io/manual/ai-connector/connect-a-cli-assistant/configure-claude-code.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
