How do I use CentralOps MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CentralOps MCP Server show quarantine events for integration 42" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

CentralOps MCP Server

by SEGARK-oficial

Overview Schema Related Servers Score Discussions

Python

Remote

CentralOps MCP Server

Drive the CentralOps security data pipeline from any MCP client — drift triage, mapping edits, routing forensics, backfills and quarantine reprocess without writing raw HTTP calls.

License: Apache-2.0 Python 3.11+ MCP Docs

A Model Context Protocol server that exposes a curated subset of the CentralOps HTTP API as 52 typed tools, so an AI agent (Claude Code, or any MCP client) can operate the pipeline like a SOC engineer: inspect what a vendor is actually sending, author and dry-run mapping rules, follow an event's delivery lineage, and reprocess quarantined events — with the destructive operation gated behind an explicit two-step acknowledgement.

The server runs as a stdio transport inside a container: the MCP client spawns docker run --rm -i ... per session. No extra service in your CentralOps stack, no port exposed.

Quick start

# 1. Build the image (from the repo root)
docker build -t centralops-mcp:dev .

# 2. Generate a CentralOps API token (PAT) at  <your-centralops-host>/settings/tokens

# 3. Register the server in your MCP client — e.g. .mcp.json for Claude Code:

{
  "mcpServers": {
    "centralops": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "CENTRALOPS_BASE_URL",
        "-e", "CENTRALOPS_API_TOKEN",
        "centralops-mcp:dev"
      ],
      "env": {
        "CENTRALOPS_BASE_URL": "https://centralops.example.com/api",
        "CENTRALOPS_API_TOKEN": "copsk_..."
      }
    }
  }
}

Restart the client and run /mcp (Claude Code) to confirm the tools are listed.

WARNING

The token is sensitive — do not commit.mcp.json with a real value. Prefer reading it from your shell (CENTRALOPS_API_TOKEN=$(pbpaste)) or a secret manager (1Password, macOS Keychain, …).

Related MCP server: chimeralang-mcp

Tools

52 tools, grouped by what they let the agent see or do. Everything is read-only except the five tools listed under Mutating and Destructive.

Vendor-side visibility

How each vendor is connected, healthy and behaving.

Tool	Purpose
`list_integrations`	Vendors connected — status, last_error, capabilities. Filterable (`platform`, `organization_id`, `name`) and paginated (`page`/`size`).
`get_integration`	One integration's configuration. Config fields need `secret.read`; real secrets are never returned.
`get_integration_health`	Live health check — v2 envelope with data-driven `metrics[]` (`id`, `label`, `value`, `severity`).
`get_integration_overview`	Serialized integration + live health + `licensed_products` (Sophos child tenants).
`list_supported_platforms`	Platform identifiers from the plugin-driven provider registry.
`get_sophos_licenses`	Licensed Sophos products for a child tenant (e.g. explain a 403 on detections).

Collection pipeline

What is being polled, from where, and at what cost.

Tool	Purpose
`list_collector_vendors`	(platform, stream) pairs the collector registry knows how to poll.
`list_collection_state`	Per-stream cursor, last_success_at, last_error, consecutive_failures (`include_inactive` to see disabled rows).
`get_collector_summary`	Global counters, failing streams, max staleness — the first read in a triage session.
`get_collector_cost_summary`	ADR-0011 volume metering: bytes/events in vs out per org, reduction ratio.
`get_pipeline_health`	Bulk pipeline health for all visible integrations (60s cache).
`get_integration_pipeline_health`	One integration: status, lag, `mapped_field_ratio`, drift/quarantine counts (24h).

Raw payloads & drift — "what is the vendor actually sending?"

Tool	Purpose
`get_mapping_samples`	Raw events from the sample reservoir for a (vendor, event_type). Global-scope tokens must pass `organization_id`.
`get_quarantine_event`	One quarantined event with its full `raw_payload`.
`list_quarantine`	Quarantined events — filter by vendor, error_kind, lifecycle `status` (pending/reprocessed/all), integration.
`list_drift_fields`	Unknown raw fields observed by the drift sampler (`status`: new/ignored/mapped).
`discover_mapping_fields`	Fields already discovered for a mapping — JMESPath autocomplete source.

Mappings catalog & history

Tool	Purpose
`list_mappings`	Catalog of mapping definitions (`only_active` mirrors the UI default).
`get_mapping`	Definition + full version history.
`diff_mapping_versions`	Structured diff between two versions.
`list_mapping_audit`	Who changed what, when — filterable by action/user/time.

Destinations & routing (ADR-0003/0008)

Where events go, and why one didn't. All of these require an admin token.

Tool	Purpose
`list_destinations`	Configured destinations with status.
`get_destinations_health` / `get_destination_health`	Delivery health, batch or per destination.
`list_destination_dlq`	Dead-letter queue — error kinds like `unrouted`, `destination_missing`, `cross_tenant_destination`.
`get_destination_metrics`	Delivery metrics time series.
`list_destination_audit`	Audit trail for a destination.
`get_event_lineage` / `list_destination_lineage`	"Where did event X actually get delivered?" — per-event delivery lineage.
`list_routes`	Routing rules (first-match order).
`get_routes_topology` / `get_routes_flow`	Route→destination topology and live flow graph.
`get_route_health` / `get_route_metrics`	Per-route matched/routed/dropped counters and series.

Detections, dashboard & history

Tool	Purpose
`list_detections` / `get_detection`	In-pipeline detections (status: open/ack/closed, OCSF severity).
`get_dashboard_summary`	The UI's opening dashboard: KPIs + top-N buckets, org/platform/period filters.
`list_scheduled_queries` / `get_scheduled_query_history`	Scheduled queries and their run history.
`list_search_history` / `get_search_result`	Saved search runs and their results.
`list_audit_log`	Platform audit log (admin token).
`get_query_capabilities`	Which query dialects/modes each source platform supports.

Backfill

Tool	Purpose
`list_backfill_jobs`	Jobs for an integration, filterable by status.
`get_backfill_job`	One job: `progress_pct`, events collected/dispatched, `stalled`/`stall_reason`.
`wait_for_backfill_job`	Server-side poll until terminal state — avoids LLM polling loops.
`backfill_diagnostics`	"Why does backfill never run?" — workers, queue consumers, backlog (global admin).

Mutating — safe

Tool	Purpose
`dry_run_mapping`	Validate rules against the sample reservoir; issues the `ack_token` needed by `commit_mapping`.
`request_backfill`	Enqueue a backfill window (≤ 90 days).
`cancel_backfill_job`	Cooperatively cancel a pending/running job.
`reprocess_quarantine`	Reprocess up to 50 quarantined events through the destination routing engine. Idempotent (409/410/422 per event).

Destructive — gated

Tool	Purpose
`commit_mapping`	Promote a new mapping version. Requires a fresh `ack_token` from `dry_run_mapping` for the same definition and rules.

commit_mapping is the only destructive tool. The ack_token expires in 5 minutes and is single-use; the backend re-validates and re-runs the dry-run on commit, so the token is defense-in-depth, not the security boundary.

Authentication

The server authenticates with a CentralOps Personal Access Token (PAT) or Service Account token — the same credential model used by external integrations — and sends Authorization: Bearer <token> on every request.

Log in to CentralOps as the user that should "own" the MCP traffic.
Go to Settings → API Tokens (/settings/tokens on your CentralOps host — not under /api).
Create a token, pick an expiration, and copy the copsk_… value once — the UI will not show it again.
Optional: restrict scopes. Without scopes the token inherits the full permission set of the user. For a read-mostly MCP, e.g.: mapping.read, quarantine.read, integration.read, audit.read.
Export the token in your shell or paste it into the MCP config above.

Tokens are individually revocable from the same page. The client identifies itself with User-Agent: centralops-mcp/<version> (persisted by the backend audit log, so MCP traffic is distinguishable from UI traffic) plus an informational X-Client header.

When a token is rejected you get a 401 with a regeneration hint; a valid token missing a scope gets a 403 with a permission hint. Tools that need an admin token say so in their descriptions.

Configuration

Env var	Default	Required	Notes
`CENTRALOPS_BASE_URL`	`http://localhost:3000/api`	recommended	Trailing `/api` is part of the URL.
`CENTRALOPS_API_TOKEN`	—	yes	PAT or Service Account token starting with `copsk_`.
`CENTRALOPS_TIMEOUT_S`	`30`	no	Per-request timeout.
`CENTRALOPS_VERIFY_TLS`	`1`	no	Set to `0` only for self-signed dev environments.
`CENTRALOPS_LOG_LEVEL`	`WARNING`	no	`DEBUG` traces requests on stderr.

Development

python3.12 -m venv .venv
.venv/bin/pip install -r requirements.txt pytest pytest-asyncio
.venv/bin/pytest

The contract test suite mocks the HTTP transport — no CentralOps instance is needed to develop or test.

Smoke test the image

The MCP handshake is initialize → notifications/initialized → tools/list. The trailing sleep keeps stdin open long enough for the second response:

{
  printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"smoke","version":"0"}}}'
  printf '%s\n' '{"jsonrpc":"2.0","method":"notifications/initialized"}'
  printf '%s\n' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
  sleep 2
} | docker run --rm -i \
      -e CENTRALOPS_BASE_URL="http://localhost:3000/api" \
      -e CENTRALOPS_API_TOKEN="copsk_..." \
      centralops-mcp:dev

You should see two JSON-RPC responses; the second lists all 52 tools with their schemas.

Contributing

Issues and pull requests are welcome. Before opening a PR:

Keep tool descriptions honest — they must describe the real backend behavior (response fields, permission requirements, org-scoping caveats). Every claim in a description should be verifiable in the CentralOps code.
Add a contract test for every new tool (see tests/contract/) asserting the exact method, path, forwarded params and dropped None params.
Read-only by default. Mutating tools need a clear safety story; destructive tools must be gated like commit_mapping.
Run .venv/bin/pytest — the suite must be green.

License

The CentralOps engine itself is a separate project licensed under AGPL-3.0.

This server cannot be installed

license - permissive license

quality - not tested

maintenance

How are these scores calculated?

Maintenance

–Maintainers

–Response time

–Release cycle

–Releases (12mo)

Commit activity

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SEGARK-oficial/centralops-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server