Alloy Navigator MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_MODE | No | Authentication mode: env (default) reads ALLOY_BASE_URL, ALLOY_CLIENT_ID, and ALLOY_CLIENT_SECRET; gateway receives credentials per-request via X-Alloy-Base-Url, X-Alloy-Client-Id, and X-Alloy-Client-Secret headers. | env |
| LOG_LEVEL | No | Logging level: debug, info (default), warn, or error. | info |
| MCP_TRANSPORT | No | Transport mode: stdio (default) or http. | stdio |
| ALLOY_BASE_URL | No | Base URL of the Alloy Navigator server, e.g. https://alloy.example.com. | |
| ALLOY_CLIENT_ID | No | Application account client ID, issued under Settings App > Services > API > Applications. | |
| CONDUIT_S2S_SECRET | No | When set, the HTTP transport requires a valid X-Gateway-S2S header on every /mcp request. | |
| ALLOY_CLIENT_SECRET | No | Application account client secret, issued alongside the client ID. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| alloy_list_objectsA | List objects of a given Alloy Navigator object class (e.g. Incidents, Work Orders, Computers, Consumables, SoftwareCatalog, or 'Purchase Order Items' - Alloy Navigator does not publish one exhaustive class list; use the object class names configured in your instance, which typically match the module names shown in the Alloy Navigator client). Supports field selection, sorting, paging, free-text search, and per-field filters. Each returned object's OID chains into alloy_get_object and alloy_get_object_activities. |
| alloy_get_objectA | Get every field of a single Alloy Navigator object by its OID (e.g. a ticket number like T000002) or database record GUID. |
| alloy_get_object_activitiesA | Get the activity/history log entries recorded against a single Alloy Navigator object by its OID - e.g. status changes, assignment changes, and system-generated notes. |
| alloy_get_dictionaryA | Get the allowed reference/classification values for a field on an Alloy Navigator object class - e.g. the valid Status or Types values for Incidents or Computers. Useful for resolving what a status/type code means, or for building a valid filter value for alloy_list_objects. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clear, non-overlapping purpose: listing objects, fetching one object, retrieving its activity log, and looking up reference values. No tool could be confused with another.
All tool names follow the same alloy_ prefix with a verb_noun pattern: list_objects, get_object, get_object_activities, get_dictionary. The convention is uniform and predictable.
Four tools is a well-scoped set that covers the core object-read workflow without unnecessary bloat. Each tool serves a distinct need and fits within the ideal 3-15 range.
The set covers the main read-only lifecycle: list objects with filters, fetch full object details, get activity history, and resolve dictionary values. Minor gaps exist, such as no way to enumerate available object classes or perform create/update/delete operations, but these seem outside the server's clear query-focused purpose.