RoboShadow MCP server

RoboShadow MCP Server

MCP server for RoboShadow's Rubicon Platform Data API - endpoint security (antivirus, Windows Defender, firewall), asset/hardware inventory, applications, users, vulnerabilities, and remediation status, for AI assistants and the WYRE Conduit gateway.

Scope: every documented operation is read-only (deliberate, not a filtered subset)

RoboShadow's Rubicon Platform Data API (https://cdn.development.roboshadow.com/publicapi/openapi.yaml, fetched directly) defines 40 GET paths across 15 tags (Antivirus, Applications, Defender, Devices, Disks, Firewall, Hardware, Identity, MFA, Remediation, Services, Updates, Users, Vulnerabilities, Vulnerability Scanner) and exactly one non-GET operation in the entire spec: POST /identity/bearertoken. That single POST is the vendor's own documented credential-refresh mechanism (OpenAPI tag: Authentication) - it exchanges a Refresh Token for a short-lived Bearer Token and mutates no organisation data. There is no create/update/delete/remediation-trigger endpoint anywhere in the published spec to exclude - unlike this session's other connectors, this one has no write surface to carve away from.

This connector implements all 40 GET operations, one tool each, and calls POST /identity/bearertoken internally (never as an exposed tool) purely to keep its own access token fresh. See Authentication below for why that call exists and why it isn't a tool.

Authentication

RoboShadow's Rubicon Platform Data API authenticates with a Bearer token (components.securitySchemes.BearerAuth, bearerFormat: JWT in the vendor's own spec). Generate credentials at your RoboShadow portal under Reports -> API Token, which shows three values together: an Organisation ID, a Bearer Token, and a Refresh Token.

The Bearer Token itself is short-lived - RoboShadow's own BearerTokenResponse schema documents expiresIn in seconds (~1 hour in the vendor's example). A token pasted into a long-running connector would go stale within the hour, so this connector stores the Refresh Token instead and exchanges it for a fresh Bearer Token internally (POST /identity/bearertoken) before every data call, caching the result in-process until shortly before it expires. The Organisation ID is not stored as a credential - pass it as the organisationId argument to any tool (discover it with roboshadowlistorganisations if you don't already have it), since a Refresh Token can resolve to more than one organisation on an MSP/reseller account.

Two separate claims here, at deliberately different confidence levels - the two-tier split established across this batch of connectors:

• Structurally verified (checked directly, stated with full confidence): this connector's own code makes zero mutating calls against RoboShadow's data API. Every function in client.ts that reads organisation data calls one of the 40 dedicated GET operations in the published spec; the only non-GET call anywhere in src/ is the bearer-token exchange itself, and it is never exposed as an MCP tool.
• Vendor-documented, not independently verified (hedged deliberately): RoboShadow's own OpenAPI spec defines no write/mutate endpoint for organisation data anywhere - there is no scoped, read-only variant of the Bearer/Refresh Token to request instead, because the full token grants exactly the same access the vendor's own spec grants: reads only. Whether some other, undocumented part of the RoboShadow platform (outside this Organisation-Endpoints spec) accepts write calls under the same token has not been tested by WYRE - only that this spec, and this connector, expose none.

In gateway mode the refresh token arrives per-request via the X-RoboShadow-Refresh-Token header; in local/stdio mode it's read once from ROBOSHADOWREFRESHTOKEN.

Configuration

Shortened. The full README is on GitHub.