---
name: zentria-working
description: Use when a request concerns Zentria e-commerce monitoring. Provides descriptive access through the read-only Zentria MCP server.
version: 1.1.3
---

# Zentria working

## Introduction

Zentria is a read-only e-commerce monitoring platform. It provides the following data for monitored shops:

- technical scans and global score, including detailed scan sensor data;
- availability status and HTTP diagnostics for non-reachable scans;
- technical security and web-performance monitoring data;
- scan history and issued notifications;
- contacts associated with a subscription;
- module inventory, versions, and installed/active states;
- sensor catalogue and related technical data history;
- Temporal data business metrics: revenue, orders, carts, customers, and Top-5 rankings.

The web version of Zentria is available at [zentria.profileo.com](https://zentria.profileo.com/).

The key used to associate data with a shop is `subscription_ID`. Zentria data never changes the shop or its database.

## MCP Endpoints

| Tool | API path, description, and required parameters |
|---|---|
| `get_subscription_ID_from_domain` | `GET /api/v1/subscription/by-domain/{domain}` — finds a subscription from a domain name or URL. **Required:** `domain`. |
| `get_subscription_ID_from_vm_hosting_name` | `GET /api/v1/subscription/by-vm-hosting-name/{vm_hosting_name}` — finds subscriptions associated with a VM hosting name; a search can return multiple items. **Required:** `vm_hosting_name`. |
| `get_scan_full_latest` | `GET /api/v1/subscription/{subscription_ID}/scans/latest` — returns the latest complete scan, its status, scores, and sensors. **Required:** `subscription_ID`. |
| `get_scans_history_light` | `GET /api/v1/subscription/{subscription_ID}/scans/history/light` — returns scan summaries and category scores for a period. **Required:** `subscription_ID`, `date_start`, `date_end`. **Optional:** `limit`, `offset`. |
| `get_scan_full_by_ID_scan` | `GET /api/v1/subscription/{subscription_ID}/scans/{scan_ID}` — returns the complete detail of an identified historical scan. **Required:** `subscription_ID`, `scan_ID`. |
| `get_reachability_diagnostics` | `GET /api/v1/subscription/{subscription_ID}/scans/{scan_ID}/reachability-diagnostics` — returns the HTTP cause and collection data for a non-reachable scan. A reachable scan returns `409`. **Required:** `subscription_ID`, `scan_ID`. |
| `get_notifications_history` | `GET /api/v1/subscription/{subscription_ID}/notifications/history` — returns notifications issued during a period. **Required:** `subscription_ID`, `date_start`, `date_end`. **Optional:** `limit`, `offset`. |
| `get_intervenants_list` | `GET /api/v1/subscription/{subscription_ID}/intervenants` — returns contacts, companies, roles, and technical-resolution responsibility associated with a subscription. **Required:** `subscription_ID`. **Optional:** `limit` (maximum 50), `offset`. |
| `get_modules_list` | `GET /api/v1/subscription/{subscription_ID}/modules` — returns module inventory: name, version, details, update date, active state, and installed state. **Required:** `subscription_ID`. **Optional:** `limit`, `offset`. |
| `get_sensors_list` | `GET /api/v1/sensors` — returns the sensor catalogue with each sensor's `sensor_ID`, name, website data, and category. `search` is **optional and empty by default**: without it, the tool returns the complete paginated catalogue; provide it only to narrow the search. **Optional:** `search`, `limit`, `offset`. |
| `get_sensor_data_history` | `GET /api/v1/subscription/{subscription_ID}/sensors/{sensor_ID}/data` — returns a sensor's historical values, score, and associated scan. **Required:** `subscription_ID`, `sensor_ID`, `date_start`, `date_end`. **Optional:** `limit`, `offset`. |
| `get_temporal_data_list` | `GET /api/v1/temporal-datas` — returns the global Temporal data metric catalogue, its exact technical names, and definitions. **No parameters.** |
| `get_temporal_data_history` | `GET /api/v1/subscription/{subscription_ID}/temporal-data/history` — returns Temporal data metric history. With `subscription_IDs`, the MCP calls this path for each subscription and returns `comparisons`. **Required:** exactly one of `subscription_ID` or `subscription_IDs`, `date_start`, `date_end`, `granularity` (`day`, `week`, or `month`), `metric_name`. **Optional:** `limit`, `offset`. |

Dates use `YYYY-MM-DD` format, with a maximum period of 90 days per call. Paginated lists accept a maximum `limit` of 100, except intervenants, which are limited to 50.

## Initial Shop Identification

Shop-related data tools require a `subscription_ID`.

| Available identifier | Resolution tool | Result |
|---|---|---|
| Domain name or URL | `get_subscription_ID_from_domain(domain)` | `subscription_ID` of the matching shop |
| VM or hosting name | `get_subscription_ID_from_vm_hosting_name(vm_hosting_name)` | `items` list of `subscription_ID` / `vm_hosting_name` pairs |

A VM name can correspond to several subscriptions. A `scan_ID` comes from a scan returned by `get_scans_history_light` or `get_scan_full_latest`. A `sensor_ID` comes from the `get_sensors_list` catalogue.

## Discovery: Sensors and Temporal Data Metrics

Two catalogues provide the exact identifiers and names required by the history tools:

| Requested data | Discovery step | History lookup |
|---|---|---|
| Technical data, for example PHP, SSL, or performance | Call `get_sensors_list()` to browse the full catalogue and obtain `sensor_ID` values. Add `search="php"` only when the request allows the catalogue to be narrowed; this is an example, not a default value. | `get_sensor_data_history(subscription_ID, sensor_ID, date_start, date_end)` |
| Temporal data, for example revenue, orders, or carts | `get_temporal_data_list()` returns the exact `name` values and their definitions. | `get_temporal_data_history(subscription_ID, date_start, date_end, granularity, metric_name)` |

Scans and sensors describe technical state. Notifications correspond to alerts that were actually issued. Temporal data consists of business metrics independent of scans and sensors; a business change alone does not prove a technical incident.

To compare several shops with Temporal data, pass the subscriptions to compare in `subscription_IDs`, with a shared period and granularity. Non-additive metrics and structured Top-5 values are identified in the catalogue returned by `get_temporal_data_list`.

## Keeping This Skill Up to Date

The versioned reference is this `SKILL.md` file, currently version `1.1.3`. A server change can add a tool, change a schema, or clarify a discovery workflow.

- The actual tool list exposed by an MCP instance is available through the MCP `tools/list` request.
- The effective descriptions and schemas are returned by that same list; they are the execution reference if they differ from this document.
- The public distributed skill version can be downloaded from `GET /skill` on the MCP instance. The file contains no secrets.
- When updating the server, update the endpoint table, discovery sequences, and relevant examples at the same time.

## Installing the MCP Server

The server uses **Streamable HTTP** transport on `POST /mcp`. The production instance documented by the project is:

```text
https://zentria-mcp.profileo.com/mcp
```

Every MCP request is authenticated with the `Authorization: Bearer <ZENTR...N>` header. This token protects the client-to-MCP flow; it is distinct from `ZENTRIA_API_TOKEN`, which is reserved for the MCP-server-to-Zentria-REST-API flow.

Example configuration for an HTTP-compatible client:

```json
{
  "mcpServers": {
    "zentria": {
      "url": "https://zentria-mcp.profileo.com/mcp",
      "headers": {
        "Authorization": "Bearer <ZENTRIA_MCP_TOKEN>"
      }
    }
  }
}
```

Clients that only support stdio can use the `mcp-remote` bridge. Validated configurations for Claude Code, Claude Desktop, and Windows are documented in `docs/GUIDE-INSTALLATION-MCP.MD`.

## Usage Examples

### “Give me the current status of shop-example.com”

1. `get_subscription_ID_from_domain(domain="shop-example.com")` to get the subscription_ID from the domain name
2. `get_scan_full_latest(subscription_ID)` returns the current status and, when the shop is reachable, the complete current metric set: global and category scores, sensor results, and detected failures or warnings.
3. If `scan_status` is not `reachable`, `get_reachability_diagnostics(subscription_ID, scan_ID)` provides the HTTP details for the non-reachability instead.

### “Show me the LCP trend for vmExemple over one week”

1. `get_subscription_ID_from_vm_hosting_name(vm_hosting_name="vmExemple")` to get the subscription_ID from the vm hosting name
2. `get_sensors_list(search="lcp")` to identify the available LCP sensor and its `sensor_ID`.
3. `get_sensor_data_history(subscription_ID, sensor_ID, date_start, date_end)` for the requested seven-day period.

### “Compare the revenue of shop-example.com for the last two consecutive months”

1. `get_temporal_data_list()` to identify and verify the Temporal data revenue name, for example `day_revenue` if the catalogue returns it.
2. `get_subscription_ID_from_domain(domain="shop-example.com")` to get the subscription_ID from the domain name
3. `get_temporal_data_history(subscription_ID, date_start, date_end, granularity="month", metric_name="day_revenue")` for the most recent complete month.
4. Call `get_temporal_data_history` a second time for the immediately preceding month, with the same duration, `granularity`, and `metric_name`. The two calls use consecutive, non-overlapping date ranges; querying the same range twice would return the same result.

Each Temporal data call accepts a maximum date range of 90 days. Two consecutive comparison periods may together cover more than 90 days, provided that each individual call remains within that limit.