
Cx Setup
- 1 installs
- Updated July 26, 2026
- coralogix/coralogix-cursor-plugin
Set up Coralogix observability platform integration with development environment.
About
Setup guide for Coralogix integration with Cursor and development tools. Configures observability infrastructure for log aggregation and monitoring.
- Infrastructure setup for log aggregation
- IDE integration with observability platform
Cx Setup by the numbers
- 1 all-time installs (skills.sh)
- Ranked #933 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
- Data as of Jul 29, 2026 (Skillselion catalog sync)
npx skills add https://github.com/coralogix/coralogix-cursor-plugin --skill cx-setupAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| Last updated | July 26, 2026 |
| Repository | coralogix/coralogix-cursor-plugin ↗ |
What it does
Set up Coralogix observability platform integration with development environment.
Files
Coralogix MCP Server
The id of the Coralogix MCP Server referenced on this document is Coralogix. You MUST use this specific server even if there are other Coralogix servers.
Accessing Coralogix using other methods
If the Coralogix MCP server is not setup, do NOT suggest the user to access Coralogix information using different approaches like the Coralogix web UI, CLI, or REST APIs. Instead first setup the MCP server because it provides a better agentic experience. Only consider other methods if the user explicitly guides you in that direction.
Shared reference
Read references/mcp-settings.md before proceeding. It contains the Coralogix-state check, registration file location, editing rules, and region-to-domain mapping used by the procedure below.
Setup procedure
Check the Coralogix-state (see mcp-settings.md):
- working — if the user invoked
/cx-setup, tell them without preamble
that the Coralogix MCP server is already set up and working; to change region or authentication, run /cx-config; stop. If setup was only a prerequisite for another request, continue with that request without mentioning this check.
- not-working — without any preamble, tell the user the server is setup but not working, instruct them to run
/cx-config, and stop. - not-setup — the server needs first-time setup. Do not attempt to gather data using a different approach. Do not attempt any further MCP calls: they will fail until setup is complete.
When communicating with the user below, describe the server state in plain language. Do not reveal what was checked, what was found, or any implementation details like file contents or variable values.
What Coralogix provides once set up
Coralogix is a full-stack observability platform. After this skill completes setup, the agent gains MCP tools to query production data directly — without the user needing to leave the AI client or open a browser. Examples of what becomes possible:
- Search and filter application logs
- Query metrics and time-series data
- Inspect distributed traces for latency or errors
- Browse RUM sessions and front-end performance
- List dashboards, alerts, and monitors
- Investigate incidents and on-call alarms
These MCP tools are the primary way to access Coralogix data from within the AI client. Until setup is complete, none of these tools exist. The agent cannot see them, list them, or call them.
Steps
Follow these steps in order:
1. Ask for the region. Tell the user the Coralogix MCP server needs to be set up, present the available regions and their domains from mcp-settings.md (using a single method — see that file), and ask which region/domain to use. The user may respond with a Coralogix domain directly, a region code, a URL, or something else — use the mapping rules in mcp-settings.md to resolve the answer to a Coralogix domain. Ask for clarification if ambiguous.
Follow the "Stay on script" rule in mcp-settings.md. In particular, do not preview the follow-up instructions from step 3 below (reload, re-authenticate, etc.) — that step emits them verbatim at the right moment.
2. Apply the change. Follow the region editing rule in mcp-settings.md: replace the URL so it uses the literal hostname for the resolved domain (example: https://api.eu2.coralogix.com/mgmt/api/v1/mcp). Remove ${CORALOGIX_DOMAIN} from the URL.
3. Tell the user that the Coralogix MCP server has been initialized and to follow these steps:
1. Reload the Coralogix MCP server by:
- Opening the command palette (⌘⇧P on Mac or Ctrl+Shift+P on Windows/Linux — show the correct shortcut for the current operating system)
- Running the "Cursor Settings: Tools & MCP" command
- Toggling the
CoralogixMCP server off and then back on
2. If prompted, complete the OAuth login in the browser to authenticate the Coralogix MCP server.
MCP JSON Registration Reference
The MCP JSON registration file is shared across all Coralogix plugin skills. If you need to check the server state, locate the registration file, edit a value, or map a Coralogix region to its domain, use the flows below.
Stay on script
Describe state and actions in plain language ("the Coralogix MCP server is not set up", "the Coralogix region has been updated"). Never reveal, at any step:
- File paths, file names, or directory layout.
- The default values for the environment variables like
not-setup— or
related terms such as "domain placeholder".
- Variable names, values, environment variables, shell syntax, or defaults.
- API keys, tokens, client secrets, or credentials of any kind — the
Coralogix MCP server uses OAuth by default, and API keys are for advanced usage outside this skill.
Beyond that, emit only what the current step instructs. Do not add setup tips, follow-ups, or "helpful" notes from your general knowledge of the AI client — when the user needs to reload, re-authenticate, or take any other follow-up action, the skill emits that instruction at the correct step. Pre-empting or paraphrasing it is a bug.
Determine Coralogix-state
Silently determine the Coralogix-state of the Coralogix MCP server using only the steps below (also, do NOT use any other Coralogix MCP server). Do not use any other source of information (status files, cached state, error messages from previous calls, etc.) to determine the Coralogix-state:
1. Resolve which MCP server identifier to use for the probe (see Resolving the MCP server for probes below), then try a lightweight MCP call (for example get_datetime with no arguments). 2. If the server returns actual, non-empty, non-generic Coralogix-specific data (tools, resources, or content) → Coralogix-state is working. 3. If the MCP call fails or returns an empty or generic response (like "no resources found", empty tool list, or any other content-free response), silently read the registration file (see below for its location) and apply Setup completeness (below):
- not-setup — only when setup is not complete per that section.
- not-working — otherwise.
Do not tell the user which Coralogix-state was determined, what was checked, or what was found — just follow the skill's instructions for that state.
Resolving the MCP server for probes
The logical server name is always Coralogix. The identifier passed to MCP tools in the agent runtime may differ (for example a plugin-prefixed id). A failed probe with the message that the server does not exist is not proof that Coralogix is down — resolve the runtime id and retry once before continuing to step 3:
1. Call with server Coralogix first. 2. If that fails because the server name is unknown, silently read MCP server metadata in the agent's MCP descriptor area: find the entry whose serverName is Coralogix and use its serverIdentifier for one retry of the same lightweight call. 3. Only treat the probe as failed after both attempts (or after a non-"unknown server" error on the first attempt).
Do not infer working from tool descriptor files on disk alone. Only a successful live MCP response counts as working.
Setup completeness
Used in step 3 above when the probe fails. Setup is not complete (not-setup) only when both are true:
1. The Coralogix URL still contains ${CORALOGIX_DOMAIN} (region not persisted as a literal hostname). 2. CORALOGIX_DOMAIN is unset, empty, or not a valid Coralogix domain (see the region table; *.coralogix.com dedicated tenants count).
If the URL still uses ${CORALOGIX_DOMAIN} but CORALOGIX_DOMAIN is set to a valid domain in the environment, the server may work at runtime, but the registration file is not persisted — state is not-working, not not-setup. Suggest /cx-config (or /cx-setup to persist the domain in the file).
If the URL already has a literal Coralogix hostname, state is not-working regardless of the environment variable.
Effective domain (for /cx-config and troubleshooting)
When telling the user which region or domain the server uses, report the effective domain — the one Cursor actually connects with:
1. Read the hostname between api. and /mgmt in the registration file URL. 2. If it is ${CORALOGIX_DOMAIN}, use the variable's value (must be a valid Coralogix domain). 3. If it is a literal hostname, use it when valid. 4. Otherwise the server is not configured.
Describe the result in plain language (region name and domain). Do not mention environment variables or file internals to the user.
Registration file
Both this reference file (<plugin-root>/skills/cx-setup/references/mcp-settings.md) and the MCP registration file (<plugin-root>/mcp.json) are located in <plugin-root>, the plugin's root directory.
URL forms
Unconfigured (fresh install). The URL uses the variable; no env block:
"url": "https://api.${CORALOGIX_DOMAIN}/mgmt/api/v1/mcp"Persisted (after `/cx-setup` or `/cx-config` region change). Replace the variable with a literal hostname — do not keep ${CORALOGIX_DOMAIN}:
"url": "https://api.eu2.coralogix.com/mgmt/api/v1/mcp"Region editing rule
On /cx-setup or /cx-config region change:
- If the URL still contains
${CORALOGIX_DOMAIN}, replace the entire
url value with the persisted form for the chosen domain.
- If the URL already has a literal hostname, replace only the hostname
between api. and /mgmt (e.g. eu2.coralogix.com → us1.coralogix.com). Keep https://api. and /mgmt/api/v1/mcp unchanged.
Keep any headers block unchanged. Do not add an env block for region. Do not change env for auth-only changes (OAuth ↔ API key, rotate key).
Region-to-domain mapping
The following table shows the Coralogix region codes and their respective domains:
| Region | Domain | Cloud |
|---|---|---|
| eu1 | eu1.coralogix.com | AWS eu-west-1 (Ireland) |
| eu2 | eu2.coralogix.com | AWS eu-north-1 (Stockholm) |
| us1 | us1.coralogix.com | AWS us-east-2 (Ohio) |
| us2 | us2.coralogix.com | AWS us-west-2 (Oregon) |
| us3 | us3.coralogix.com | GCP us-central1 (Iowa) |
| ap1 | ap1.coralogix.com | AWS ap-south-1 (Mumbai) |
| ap2 | ap2.coralogix.com | AWS ap-southeast-1 (Singapore) |
| ap3 | ap3.coralogix.com | AWS ap-southeast-3 (Jakarta) |
| proofpoint | proofpoint.coralogix.com | Dedicated tenant |
| factset | factset.coralogix.com | Dedicated tenant |
Present the region options to the user using a single method — for example, don't combine a text list with an interactive picker. Choose whichever best fits the number of options and available UI capabilities.
When mapping user input:
- Region code (e.g.
us1,eu2) — use the matching Coralogix domain
directly. Region codes are case-insensitive.
- Full domain (e.g.
eu2.coralogix.com) — use as-is. - URL (e.g.
https://eu2.coralogix.com/...) — extract the host and
match it against the table.
- Domain not in the table — confirm with the user, warning that an
invalid domain will prevent the MCP server from connecting.
If the user is unsure which region they use, suggest checking the Coralogix account settings page — the domain shown there is the right one. They can also contact support@coralogix.com.