> 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-mistral-vibe-cli.md). # Configure Mistral Vibe CLI Connect the Mistral Vibe CLI to your Datasentinel MCP server on Linux, sign in, install the Datasentinel Skill, and verify the configuration. This page shows how to wire [Mistral Vibe CLI](https://docs.mistral.ai/vibe/code/cli/install-setup) to your Datasentinel platform on a Linux host: add the **MCP server**, **sign in** once, install the **Skill** that tells the assistant how to use it, and check that everything is connected. The same pattern applies to other MCP-and-Skill-capable assistants. The commands below are specific to Mistral Vibe CLI (the `vibe` command), Mistral's open-source terminal coding agent. {% hint style="info" %} The steps below follow Mistral's documentation, last checked on 6 October 2026. Mistral changes Vibe often. {% endhint %} ## Before you start * Mistral Vibe CLI is installed and you can run `vibe` from a terminal. If it is not yet installed, follow the steps below. Version 2.17 or later is needed for the sign-in commands used on this page. * The host has an OS keyring (Vibe stores the Datasentinel session in it). A desktop Linux has one; a bare server usually does not, see the sign-in step. * Your Datasentinel MCP server is reachable over HTTPS at `https:///mcp`. See [MCP Server Setup](/manual/ai-connector/server-setup/mcp-server-setup.md) if it is not yet running. ## Install Mistral Vibe CLI {% stepper %} {% step %} #### Install the CLI Download and run the official installer: ```bash curl -LsSf https://mistral.ai/vibe/install.sh | bash ``` {% endstep %} {% step %} #### Launch and authenticate Start the CLI: ```bash vibe ``` On first launch, follow the prompts to authenticate with your Mistral account. Vibe stores the resulting credentials under `~/.vibe/`, so you only sign in once. {% endstep %} {% endstepper %} {% 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 Vibe reads MCP servers from a `config.toml` file. The user-level file at `~/.vibe/config.toml` applies to every project; a `./.vibe/config.toml` in a project directory applies to that project only. For the full set of MCP server options, see Vibe's [MCP servers documentation](https://docs.mistral.ai/vibe/code/cli/mcp-servers) and the [MCP section of its README](https://github.com/mistralai/mistral-vibe#mcp-server-configuration). Register the server from the shell with the streamable-HTTP transport and your platform URL: ```bash vibe mcp add datasentinel-production --url https:///mcp ``` Without a token option, Vibe treats the server as an OAuth server, writes it to `~/.vibe/config.toml` and starts the sign-in at once (next step). Add `--no-login` to write the configuration only and sign in later from inside Vibe. The same server written by hand in `~/.vibe/config.toml`: ```toml [[mcp_servers]] name = "datasentinel-production" transport = "streamable-http" url = "https:///mcp" [mcp_servers.auth] type = "oauth" scopes = [] ``` {% 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. 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** Vibe validates the `/mcp` certificate against its bundled public roots and offers no switch to turn validation off (a configurable bypass is tracked upstream in [mistralai/mistral-vibe#30](https://github.com/mistralai/mistral-vibe/issues/30)). A certificate from an internal CA works once Vibe trusts that CA. Either point it at the CA file with the standard `SSL_CERT_FILE` variable, or, if the CA is installed in the host's trust store, opt in to that store in `~/.vibe/config.toml`: ```toml enable_system_trust_store = true ``` Both are additive: the public roots stay trusted. A self-signed certificate that belongs to no CA cannot be trusted this way, so give the endpoint a certificate from a CA, or put a reverse proxy with a trusted certificate in front of it. The sign-in below also opens the login page in your browser, so the browser must trust the certificate too. {% endstep %} {% step %} #### Sign in to the platform **With a browser** If `vibe mcp add` started the sign-in, it opens the Datasentinel login page in your browser and prints the link in the terminal as well. Otherwise start an interactive `vibe` session and run: ``` /mcp login datasentinel-production ``` Vibe shows a small panel: press Enter to open the login page in your browser, or choose *Copy URL to clipboard* or *Manually show the URL* to open it yourself. 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 Vibe, and `/mcp status` shows the server as `ok`. You sign in once. Vibe stores the session in the OS keyring and renews it by itself. It 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; Vibe never sees it and never asks for a token. `/mcp logout datasentinel-production` ends the session on this host; `vibe mcp remove` also deletes the stored session. **Without a browser** On a server without a browser (an SSH session, a build machine), two things get in the way: Vibe stores the session in an OS keyring, which a server usually lacks, and it waits for the browser to come back on a fixed local port, 47823 by default. **1. Give Vibe a keyring.** Without one, the sign-in stops at once with `No OS keyring backend is available`, and Vibe's message suggests the token option instead. Vibe relies on the standard Python `keyring` library, which accepts a file-based backend from the `keyrings.alt` package. Vibe is installed as a `uv` tool, so reinstall it with that package added, then check which backend it sees: ```bash uv tool install --force --with keyrings.alt mistral-vibe "$(uv tool dir)/mistral-vibe/bin/python" -c "import keyring; print(keyring.get_keyring())" ``` The second command must print `keyrings.alt.file.PlaintextKeyring`; before the change it prints `keyring.backends.fail.Keyring`. The session is then stored under `~/.local/share/python_keyring/`, encoded but not encrypted, the same protection as a cached token file. `uv tool upgrade` keeps the added package. The install script puts `uv` in `~/.local/bin/` if it is not on your `PATH`. **2. Forward the callback port.** Open the SSH session from your laptop with the port forwarded, start Vibe inside that session, run `/mcp login datasentinel-production` and pick *Manually show the URL* in the sign-in panel: ```bash # on the laptop: the tunnel only exists in a session opened this way ssh -L 47823:localhost:47823 @ ``` Open the shown link in the laptop's browser and sign in; the way back to `localhost:47823` travels through the tunnel to Vibe on the server. If you are already connected without the option, log out and reconnect with it before starting Vibe. Another port can be set with `redirect_port` under the server's `[mcp_servers.auth]` block. The general procedure is in [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md#sign-in-from-a-server-without-a-browser). If you would rather not add a keyring, use the token option below instead. **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 platform's 24-hour [user token](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/implementation/platform-usage/api-reference/access-token). Vibe reads it from an environment variable, so the token is never written in the configuration: ```bash export DS_TOKEN= vibe mcp add datasentinel-production --url https:///mcp --api-key-env DS_TOKEN ``` This writes a static-auth entry that sends `Authorization: Bearer ` on every call: ```toml [[mcp_servers]] name = "datasentinel-production" transport = "streamable-http" url = "https:///mcp" [mcp_servers.auth] type = "static" api_key_env = "DS_TOKEN" ``` A server registered this way never opens the login page, and `/mcp status` shows it as `static`; 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. Do not use `--header` for the token: Vibe stores header values in clear text in `config.toml`. {% endstep %} {% step %} #### Install the Datasentinel Skill 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 . Skills in Vibe 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 Vibe discovers it on the next session. {% tabs %} {% tab title="Personal (all your projects)" %} ```bash mkdir -p ~/.vibe/skills/ unzip datasentinel-skill.zip -d ~/.vibe/skills/ ``` {% endtab %} {% endtabs %} {% hint style="info" %} **Cross-agent location: `.agents/skills`.** For project Skills, Vibe also discovers a `.agents/skills` directory (the vendor-neutral location other agents share) when the working directory is trusted, so a project-local `SKILL.md` folder can serve them too. The `~/.vibe/skills` path above is Vibe's own personal-scope location. See Mistral's [Skills](https://docs.mistral.ai/vibe/code/cli/skills) reference. {% endhint %} {% endstep %} {% step %} #### Check your configuration Inside an interactive `vibe` session, use the `/mcp` command to list the configured servers and their connection status: ``` /mcp ``` A healthy entry shows the server connected with its tools available. `/mcp status` prints the authentication state of each server: `ok` once you are signed in, `needs_auth` when the sign-in is still to be done (go back to the previous step), `static` for a server registered with a token. If a server shows an error, check the URL in `config.toml` and that the server is up. **Approve the Datasentinel tools** The first time the assistant calls a Datasentinel tool, Vibe asks you to approve it. The prompt offers four choices: allow once, allow for the rest of the session, always allow, or deny. Choosing **Always allow** writes a permanent rule for that tool into `~/.vibe/config.toml`, so after one pass through the tools you use, the prompts stop. The rule is keyed by the tool's full name, the server name followed by an underscore and the tool name, and can also be written by hand: ```toml [tools.datasentinel-production_get_platform_status] permission = "always" ``` The Datasentinel tools only read monitoring data, so approving them permanently is safe. To approve every tool of every kind instead, including shell commands and file edits, start Vibe with `vibe --auto-approve`, or switch to the `auto-approve` agent with `Shift+Tab` during the session. Setting `default_agent = "auto-approve"` in `config.toml` makes that the default for all sessions; use it with care. {% endstep %} {% endstepper %} Once the server shows as connected and the Skill is in place, run through the checks below to confirm the end-to-end flow. ## How the Skill loads The Datasentinel Skill loads on demand. Vibe reads every Skill's name and `description` up front, and applies the full instructions automatically when your prompt 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 Vibe answers generically instead (no Datasentinel tool calls in the response), load the Skill manually: * Type `/datasentinel` in the prompt: a Skill whose frontmatter allows user invocation (`user-invocable: true`) autocompletes as a slash command. * Or name it in the prompt: `Use the datasentinel skill to check the platform status.` If the Skill is not picked up at all, re-check the unzip location from the setup step and start a new session. See Mistral's [Skills](https://docs.mistral.ai/vibe/code/cli/skills) reference for the details. ## Test the MCP server and Skill Run these checks inside an interactive `vibe` session. You exercise the Skill by asking in plain language and letting it drive the MCP tools (see [How the Skill loads](#how-the-skill-loads) above). The Datasentinel Skill recognises four built-in checks. Run them in order: | Ask Vibe for… | 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. | | `datasentinel whoami` | Shows who you are signed in as, your privilege and the session expiry. | 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. Then run `datasentinel platforms` to verify your server is discovered: each `datasentinel-*` MCP server you registered should appear in the list. Then run `datasentinel status` to confirm the platform is reachable and the MCP tools return live data. Finally, `datasentinel whoami` confirms the session belongs to your platform user, with the privilege you expect. {% 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 Vibe to debug the setup rather than hunting by hand. It can run `/mcp`, read the `[[mcp_servers]]` blocks in `~/.vibe/config.toml` or `./.vibe/config.toml`, 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 `config.toml` the session does not read, a server still in `needs_auth` state, an untrusted 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-mistral-vibe-cli.md?ask=&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.