Ivanti MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Optional. Bind host for HTTP transport. Defaults to 127.0.0.1. | |
| MCP_PORT | No | Optional. Port for HTTP transport. Defaults to 8001. | |
| MCP_JWKS_URI | No | Optional. JWKS URI for inbound JWT validation (required for HTTP unless MCP_JWT_SECRET is used). | |
| MCP_READ_ONLY | No | Optional. Set to 'true' to hide write/destructive tools. | |
| MCP_TRANSPORT | No | Optional. Set to 'http' for remote HTTP transport. Defaults to stdio. | |
| IVANTI_API_KEY | Yes | REST API key. Sent as Authorization: rest_api_key=... or Bearer if IVANTI_AUTH_SCHEME=bearer | |
| MCP_JWT_ISSUER | No | Optional. Expected JWT issuer for inbound validation. | |
| MCP_JWT_SECRET | No | Optional. HMAC secret for HS256 JWT validation (alternative to MCP_JWKS_URI). | |
| IVANTI_BASE_URL | Yes | Your Ivanti tenant origin (e.g., https://your-tenant.ivanti.com) | |
| IVANTI_CLOSE_VIA | No | Optional. Method to close an incident: 'patch_status' or 'quick_action'. | |
| MCP_JWT_AUDIENCE | No | Optional. Expected JWT audience for inbound validation. | |
| MCP_ALLOWED_HOSTS | No | Optional. Allowed Host/Origin values for HTTP protection. | |
| IVANTI_AUTH_SCHEME | No | Optional. Set to 'bearer' to send the API key as a Bearer token instead of rest_api_key. | |
| IVANTI_JOURNAL_OBJECT | No | Optional. Journal object name used for adding notes. Defaults to 'journal.notess'. | |
| IVANTI_CLOSE_ACTION_ID | No | Optional. Quick Action ID when IVANTI_CLOSE_VIA=quick_action. | |
| IVANTI_RESOLVED_STATUS | No | Optional. Status value used when resolving an incident. Defaults to 'Closed'. |
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_incidentA | Load a full Ivanti incident by RecId. Returns subject (Subject), description (Symptom), category, status, requester, and ownership fields. |
| add_noteA | Create a journal note on an incident. Writes Notes, Summary, and ParentLink_RecID on the journal business object. |
| resolve_incidentA | Mark an incident resolved. Reads Status first and no-ops if already closed. Writes Status (or a Quick Action) and an optional close note. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| health_resource |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: get_incident reads incident data, add_note writes to the journal, and resolve_incident changes status. There is no meaningful overlap between read and write operations.
All tool names use lowercase snake_case with a verb-first pattern. However, add_note does not explicitly reference incidents like the other two tools, so using add_incident_note would make the naming more consistent.
Three tools is at the lower end of the typical range but appropriate for a focused incident-handling server. Each tool is essential and earns its place without redundancy.
The set covers the common workflow of viewing an incident, adding a note, and resolving it. However, it lacks create, update, search/list, and other lifecycle operations, so it only partially covers the broader incident management domain.