> 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-an-ide/configure-cursor.md). # Configure Cursor Connect Cursor to your Datasentinel MCP server, sign in, install the Datasentinel Skill, and verify the setup. This page shows how to wire [Cursor](https://cursor.com/) to your Datasentinel platform: add the **MCP server**, **sign in** once, install the **Skill** that tells the assistant how to use it, and check that everything is connected. Cursor consumes MCP servers through its **Agent**, configured from the Customize page or a JSON file. It also supports the **Agent Skills** standard, so the Datasentinel Skill installs as a `SKILL.md` folder just like in the terminal assistants. {% hint style="info" %} The steps below follow Cursor's documentation, last checked on 6 October 2026. Cursor changes often. {% endhint %} ## Before you start * **Cursor** is installed and you can open it. If it is not yet installed, download it from [cursor.com](https://cursor.com/). * 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. {% 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 Cursor's [Model Context Protocol](https://cursor.com/docs/mcp) guide. Cursor reads MCP servers from an `mcp.json` file. The user-level file at `~/.cursor/mcp.json` applies to every project; a `.cursor/mcp.json` in a project directory applies to that project only. Add and manage servers from Cursor's **Customize** page (older versions expose the same list under **Settings > Tools & Integrations**), or edit the file by hand. Each server is a child of the `mcpServers` object. A remote server uses the `url` field with your platform URL: ```json { "mcpServers": { "datasentinel-production": { "url": "https:///mcp" } } } ``` Cursor connects to a remote `url` server over streamable HTTP. {% 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 `headers` entry, and no `auth` block either, since Cursor registers itself with the server on its own (the `auth` block is for servers that require pre-registered client credentials). The sign-in is the next step. See [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md). {% endhint %} After saving, enable the server from the same page if it is not on already. {% endstep %} {% step %} #### Sign in to the platform **With a browser** Once the server is enabled, its entry on the MCP page shows **Needs login**. Click it: Cursor 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 Cursor through its own local callback address, `http://localhost:8787/callback`, and the server shows its tools. You sign in once. Cursor renews the session by itself and asks again only after ten days without using the server, or when an administrator ends the session; the entry then shows **Needs login** again. Your password goes to the login page only; Cursor never sees it and never asks for a token. Cursor's OAuth support, including its fixed callback addresses, is described in its [MCP guide](https://cursor.com/docs/mcp). **Without a browser** Cursor is a desktop application, so the machine running it always has a browser, and the sign-in comes back to that machine. The case to know about is Cursor's terminal agent running on a remote host: its callback port is fixed at 8787, so forward it when you open the SSH session, then start the sign-in inside that session and open the printed link in the laptop's browser: ```bash # on the laptop: the tunnel only exists in a session opened this way ssh -L 8787:localhost:8787 @ ``` 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). **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). Header values accept `${env:VARIABLE}` references, so the token stays out of the file: ```json { "mcpServers": { "datasentinel-production": { "url": "https:///mcp", "headers": { "Authorization": "Bearer ${env:DS_TOKEN}" } } } } ``` A server registered this way never shows **Needs login**; 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 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 . Cursor supports the **Agent Skills** standard: a Skill is a folder containing a `SKILL.md`, discovered automatically. Unzip the archive into a Skills directory so it produces a `datasentinel/` folder: {% tabs %} {% tab title="Personal (all your projects)" %} ```bash mkdir -p ~/.cursor/skills/ unzip datasentinel-skill.zip -d ~/.cursor/skills/ ``` {% endtab %} {% tab title="Project (shared via Git)" %} ```bash mkdir -p .cursor/skills/ unzip datasentinel-skill.zip -d .cursor/skills/ ``` {% endtab %} {% endtabs %} You should end up with `~/.cursor/skills/datasentinel/SKILL.md` (or `.cursor/skills/datasentinel/SKILL.md`) alongside the Skill's supporting files. 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. --- ``` For more on the format, see Cursor's [Agent Skills](https://cursor.com/docs/skills) guide. {% endstep %} {% step %} #### Check your configuration Open the **Customize** page (or **Settings > Tools & Integrations** in older versions) to list the configured MCP servers and their status. A healthy server shows enabled with its tools discovered. **Needs login** means the sign-in of the previous step is still to be done. If it shows an error, check the `url` in `mcp.json` and that the server is up. **Approve the Datasentinel tools** In the Agent chat, the Datasentinel tools become available to the assistant. Cursor asks for approval before using an MCP tool by default; click the arrow next to the tool name to see its arguments. How often it asks is set by the run mode, in **Cursor Settings > Agents > Approvals & Execution**: **Auto-review** (the default in recent versions) runs allowlisted tools immediately and routes the rest through a safety classifier, **Allowlist** runs only allowlisted tools without asking, and **Run Everything** approves every tool call of every kind, including shell commands, so use it with care. To stop the prompts for the Datasentinel tools in the first two modes, add the server to the MCP allowlist, from the same settings page or in `permissions.json`. Patterns take the form `server:tool`, and `*` covers every tool of a server: ```json { "mcpAllowlist": ["datasentinel-production:*"] } ``` The Datasentinel tools only read monitoring data, so allowing the whole server is safe. See Cursor's [Run Modes](https://cursor.com/docs/agent/security/run-modes) guide and the [permissions reference](https://cursor.com/docs/reference/permissions). {% endstep %} {% endstepper %} ## Self-signed or invalid certificates If your platform serves the `/mcp` endpoint with a self-signed or otherwise invalid TLS certificate, Cursor rejects the connection by default. **Keep verification on (recommended)** Provision a certificate the host trusts: one from a public authority, or your internal CA installed in the operating system trust store. Cursor runs on Node, so you can also point its runtime at your CA bundle by setting [`NODE_EXTRA_CA_CERTS`](https://nodejs.org/api/cli.html#node_extra_ca_certsfile) to a PEM file before launching Cursor: ```bash export NODE_EXTRA_CA_CERTS=/path/to/internal-ca.pem cursor ``` Both options keep certificate validation on, which is why they are preferred. The sign-in opens the login page in your browser, so the browser must trust the certificate too. **Disable verification (last resort)** To turn TLS verification off, launch Cursor with [`NODE_TLS_REJECT_UNAUTHORIZED`](https://nodejs.org/api/cli.html#node_tls_reject_unauthorizedvalue) set to `0`: ```bash NODE_TLS_REJECT_UNAUTHORIZED=0 cursor ``` {% hint style="warning" %} This disables certificate validation **process-wide** for Cursor, not just for the Datasentinel MCP server, so every connection Cursor makes is exposed. Use it only for a quick local test, and switch back to a trusted certificate for anything lasting. Cursor has no MCP-specific setting to bypass certificate checks (see the closed [certificate-check bypass request](https://forum.cursor.com/t/add-certificate-check-bypass-to-mcp-sse/61370)), and recent versions may ignore this variable, so verify the behaviour in your environment. {% endhint %} For more background, see Cursor's community discussion on [connecting to an MCP server with a self-signed certificate](https://forum.cursor.com/t/can-cursor-connect-to-mcp-server-with-self-signed-certificate-using-streamable-http/107773). Once the server is 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. Cursor discovers Skills at startup, reads each one's name and `description`, 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 the Agent answers generically instead (no Datasentinel tool calls in the response), load the Skill manually: * Type `/` in the Agent chat and search for `datasentinel` to invoke the Skill with your request. * Or name it in the prompt: `Use the datasentinel skill to check the platform status.` If `datasentinel` is missing from the `/` list, re-check the unzip location from the setup step and restart Cursor. Cursor also discovers Skills from the vendor-neutral `.agents/skills` and `~/.agents/skills` locations, so a Skill already installed there for another assistant works too. See Cursor's [Agent Skills](https://cursor.com/docs/skills) guide for the details. ## Test the MCP server and Skill Ask Cursor's Agent, in plain language, to run the Datasentinel checks. 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 Cursor 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 Cursor 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 Cursor's Agent to debug the setup rather than hunting by hand. It can read `~/.cursor/mcp.json` or the project's `.cursor/mcp.json`, list the tools it actually sees, and probe the endpoint from the terminal, 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.json 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 left disabled in **Customize**, a server still marked **Needs login**, 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-an-ide/configure-cursor.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.