Alloy Navigator MCP server

Alloy Navigator MCP Server

MCP server for Alloy Navigator's REST API - IT asset management, ITSM, and network inventory data (incidents, work orders, assets, software catalog, consumables, and more) for AI assistants and the WYRE Conduit gateway.

Authentication

Alloy Navigator authenticates third-party applications with the OAuth2 clientcredentials grant. An application account is registered in the Alloy Navigator Settings App under Services > API > Applications, which issues a client ID and client secret**. This connector exchanges those for a bearer access token by POSTing to /api/token, then sends Authorization: Bearer on every subsequent request. Access tokens are valid for 8 hours per Alloy Navigator's own documentation; this connector caches a token per credential set and transparently re-authenticates once it's near expiry (see src/auth.ts).

Alloy Navigator has no fixed hosted API endpoint - every instance (on-premises, or a customer's own self-hosted-cloud tenant) is deployed at its own base URL, so this connector requires all three of a base URL, a client ID, and a client secret. In gateway mode all three arrive per-request via the X-Alloy-Base-Url, X-Alloy-Client-Id, and X-Alloy-Client-Secret headers; in local/stdio mode they're read once from ALLOYBASEURL, ALLOYCLIENTID, and ALLOYCLIENTSECRET.

Alloy Navigator's API module (and this connector's application-account grant type specifically) requires the API Module to be installed and enabled on the target instance - see Alloy Navigator's own Installation Guide ("Installing and Configuring the API Module") if a client_credentials request returns a connection or 404 error rather than an auth error.

Credential scope

Vendor-documented, not independently verified against a live account (see Verification below for why): Alloy Navigator's API User's Guide describes application accounts as accounts used by "third-party applications that run without a signed-in user present," distinct from a regular technician (username/password) account, but does not document a way to scope an application account's read access below whatever object classes and fields the account otherwise has permission to see in Alloy Navigator's own security/role configuration. In practice this means the actual read-only guarantee is enforced by this connector's tool surface (GET-only, no workflow-action execution), not by the credential itself - Alloy Navigator's own workflow-action model means even a technically "read" API call executes through the same account whose role could, in principle, also be granted write/workflow-action permissions elsewhere. Customers should create a dedicated, minimally-privileged application account for this connector, matching the same practice recommended by other vendors in this fleet (e.g. PRTG) whose API keys inherit the creating account's full permission set.

Verification

This connector was built directly against Alloy Navigator's official API User's Guide (docs.alloysoftware.com/alloynavigator/docs/api-userguide/), not against secondary documentation or a naming convention - every tool below maps to one real, documented GET operation, with its exact query parameters and response shape verified against the guide's own worked examples (see each tool's JSDoc in src/client.ts for the source example it was checked against). What it is not is independently verified against a live Alloy Navigator instance: Alloy Navigator does not publish a public self-serve trial or sandbox instance, and provisioning one requires a live sales/licensing engagement this build environment could not complete. This is a build-environment limitation, not a vendor-side approval gate for a customer with an existing license.

Configuration

Shortened. The full README is on GitHub.