addigy-mcp

Addigy V2 MCP server — exposes the Addigy Cyber Platform API (v2) as MCP tools.

Naming note: app.mspbots.ai has two separate Addigy integrations: "Addigy" (subject_code = ADDIGY, legacy auth via Site + Client ID + Client Secret) and "Addigy V2" (subject_code = ADDIGYV2, auth via a single API Key). This server implements Addigy V2 only, matching the ClickUp task's scope.

Overview

This server implements the Model Context Protocol (Streamable HTTP/SSE transport) and covers the 5 interfaces that MSPbots' own Addigy V2 integration actually uses, matching the interface scope configured in MSPbots' sys_integration/sys_integration_api tables:

It follows the MSPbots Vendor MCP Service SOP: stateless, no stored credentials, per-request header authentication.

The underlying Addigy v2 API authenticates via a single static API Key (x-api-key header), created in the Addigy console under Account → Integrations — matching the single "API Key" field configured in MSPbots' Addigy V2 integration. This server forwards the caller-supplied key as-is; it never stores or persists it.

Related MCP server: Meraki MCP Server

Quick Start

Docker (recommended)

docker compose up --build

The server starts on http://localhost:8080.

Local (uv)

uv sync
python -m addigy_mcp

Health Check

curl http://localhost:8080/health
# {"status": "ok", "service": "addigy-mcp", "transport": "http"}

No credentials are required for the health endpoint.

授权参数说明 (Authentication)

Every request to /mcp must include the following HTTP header:

Missing the header returns 401 Unauthorized.

Environment Variables

MCP Endpoint

POST http://localhost:8080/mcp

Connect your MCP client with:

• Transport: http (Streamable HTTP / SSE)

• Headers: X-Addigy-Api-Key: <api_key> (required)

Tool List

5 tools, matching the exact interface count MSPbots' own Addigy V2 integration uses.

multitenancy/child_organizations apply to the three /oa/... endpoints and control whether results include descendant (child) organizations, per Addigy's "Child Organizations" API convention.

测试示例 (Test Example)

Query policies:

{
  "method": "tools/call",
  "params": { "name": "addigy_query_policies", "arguments": {} }
}

Equivalent curl against the running server (streamable HTTP MCP endpoint):

curl -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" \
  -H "X-Addigy-Api-Key: <api_key>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "addigy_query_policies", "arguments": {} }
  }'

A parameterized call:

{
  "method": "tools/call",
  "params": {
    "name": "addigy_get_alerts",
    "arguments": { "page": "1", "per_page": "50" }
  }
}

API Reference

• Documentation: https://api.addigy.com/api/v2/documentation/

• Auth: single x-api-key header (API keys created under Addigy Account → Integrations)

Known Gaps / Implementation Notes

• Scope is intentionally limited to the 5 interfaces MSPbots' Addigy V2 integration is configured to use, not the full Addigy API surface (which spans 300+ endpoints across devices, MDM commands, policies, benchmarks, scripts, webhooks, and many third-party integration passthroughs).

• page/per_page on addigy_get_alerts are typed as strings because the vendor's own OpenAPI spec defines them as type: string (despite being numeric page/size values) — passed through as-is.

• Not yet tested against a live Addigy account — only protocol-level verification (health check, 401 on missing header, tools/list returning all 5 tools) has been done so far.