Systemiq can be exposed to an agent stack as an MCP server so agents can query modeled operational context directly instead of reading raw enterprise systems one by one.

This makes Systemiq the context layer in front of downstream agent workflows.

Authentication

Agent access should be authenticated at the connection boundary. In practice, MCP clients pass credentials in the server configuration and Systemiq validates access before serving context.

What agents typically do first

• Orient inside the model by listing systems, tools, elements, mappings, and available client-level outputs.
• Discover which indicators or record types are available before narrowing the query.
• Choose records for structured context or metrics for numerical analysis.
• Keep requests scoped to the operational question the agent is trying to answer.

Query patterns

• Query for narrow operational intent rather than broad raw enterprise data.
• Start with stack structure when needed: systems, tools, elements, client-level outputs, and tool-element mappings.
• Scope requests by system, tool, element, record type, or indicator.
• Use records for structured context retrieval and metrics for numerical and time-series analysis.
• For metrics queries, treat `created_at` as the canonical timestamp and `value` as the numeric measure to aggregate.
• For metrics queries, use `indicator` for the metric family and `key` for the metric variant such as `value__latest`.

Example MCP client configuration

{
  "mcpServers": {
    "systemiq": {
      "type": "http",
      "url": "https://api.systemiq.ai/mcp",
      "headers": {
        "Authorization": "Basic <TOKEN>"
      }
    }
  }
}

Typical query flow

• Use catalogs and mappings first when the agent needs to orient itself inside the model.
• Discover which indicators exist before issuing narrower queries.
• Fetch matching records when the agent needs structured context objects.
• Run metric queries when the agent needs aggregates or time-series analysis.
• Do not pass environment explicitly. Systemiq derives `staging` or `production` from the authenticated token scope and applies it automatically.

Metrics table semantics

• `metrics` is the analytical table exposed to `metrics_query`.
• `created_at` is the primary timestamp for grouping, windows, and bucketed time-series analysis.
• `value` is the numeric value to aggregate with `AVG`, `SUM`, rolling windows, or other SQL functions.
• `indicator` identifies the business metric family and `key` distinguishes metric variants such as `value__latest`.
• `system_id`, `tool_id`, and `element_id` may be `null` depending on where the metric was produced in the stack.
• `client_id` and `environment` exist in the table, but scoping is applied automatically by authenticated access rather than passed as a user parameter.
• For `metrics_query`, the MCP layer sends the derived environment to the records API as a dedicated request parameter instead of rewriting the SQL.

Example: discover available indicators

records_indicators_catalog({
  search: "dependency",
  limit: 10
})

Example: retrieve matching records

records_find({
  indicator: "critical_dependency",
  record_type: "tool_insight",
  page: 1,
  page_size: 10,
  order: "desc"
})

Example: query metrics as a time series

metrics_query({
  sql: `SELECT
  avg(value) AS avg_value,
  time_bucket_gapfill('1 day', created_at) AS datetime
FROM metrics
WHERE element_id = 3
  AND key = 'close'
GROUP BY client_id, datetime
ORDER BY datetime`
})

Example: compare recent metric windows

metrics_query({
  sql: `WITH anchor_time AS (
  SELECT '2026-03-10T00:00:00Z'::timestamp AS anchor
),
base_values AS (
  SELECT created_at, value
  FROM metrics
  WHERE indicator = 'critical_dependency'
    AND key = 'score'
)
SELECT
  AVG(CASE WHEN created_at > a.anchor - INTERVAL '7 days' AND created_at <= a.anchor THEN value END) AS mean_7d,
  AVG(CASE WHEN created_at > a.anchor - INTERVAL '6 weeks' AND created_at <= a.anchor THEN value END) AS mean_6w
FROM base_values, anchor_time a`
})