Halo Change Request

Halo Change Request

Open a change request in Halo through a strict discover -> preview -> confirm -> submit flow. Halo is HaloPSA / HaloITSM (the same product and the same REST API — HaloPSA is the MSP edition, HaloITSM the internal-IT edition). A "change request" in Halo is not a fixed object type: it is simply a ticket type ("Request Type") whose numeric id and custom fields are configured per organization — and an org often defines several change types (for example a customer-facing change and an internal change). This skill figures out which change is being raised, discovers the matching type, confirms it with a human, remembers it per category, learns its fields, and gates the single write behind explicit approval.

MCP Server

• Server: halo-mcp (NetClaw-authored, mcp-servers/halo-mcp/)
• Command: python3 -u mcp-servers/halo-mcp/halo_mcp_server.py (stdio transport)
• Auth: OAuth2 client-credentials — HALO_CLIENT_ID / HALO_CLIENT_SECRET against HALO_BASE_URL (token from <base>/auth/token, resource API at <base>/api)
• Python: 3.10+ · Dependencies: fastmcp, httpx, python-dotenv
• Read/write posture: read-only except one gated write — halo_create_change_request is the ONLY tool in the entire server that can mutate Halo, and it previews (no write) unless submit=true.

This skill also uses the Memory MCP server (memory-mcp) to cache the confirmed change ticket type per Halo tenant.

Available Tools

Key Concepts

• Halo == HaloPSA == HaloITSM. Same API; only the packaging differs. Everything here works against either.
• "Change request" is a ticket type, not a built-in. Its id and its custom fields are per-org. You must discover it (never hard-code it) and confirm it with a human before trusting it.
• There is often more than one change type. Many orgs split changes — e.g. a customer change vs an internal change, or standard / normal / emergency. Treat the change type as a set: work out which change this is (ask if unclear), keep a per-category catalog in Memory, and confirm the specific type before filing.
• The Halo "Client" is the customer. Every tool that scopes to a customer org takes it as the customer param (a client name or numeric id), which the server resolves to a client_id. When someone says "the client," they mean this.
• Tickets are "Faults"; ticket types are "Request Types"; assets are "Devices" in Halo's API vocabulary — the tool names hide this, but error text may show it.
• One write, always gated. halo_create_change_request with submit=false performs NO HTTP write; it returns the exact array body that would be POSTed to /api/Tickets. The real POST happens only on a second call with submit=true.
• Memory holds the type, never the contents. Cache only the confirmed ticket-type id and its field metadata — never credentials, never the text of any change ticket.

Workflow

The full change-request flow, step by step. Do not skip steps (a) or (c).

(a) Determine the change category, then recall or discover its type

An organization usually has more than one change type — most commonly a customer change (raised against a client) and an internal change (internal IT / infrastructure), and sometimes standard / normal / emergency splits. So first decide which change this is, then resolve the matching type. Never assume there is only one.

1. Decide the category. Infer from context: a change scoped to a specific customer/client is a customer change; a change with no client (internal infra, your own systems) is an internal change. If it is at all ambiguous, ASK the operator — e.g. "Is this a customer change or an internal change?" Use a short lowercase label for the category (customer, internal, emergency, ...).

2. Recall the tenant's change-type catalog:

   memory_get_facts(entity="halo-<tenant>", key="change_ticket_types")

   The value is a list of {"id":..., "name":..., "category":...} — the change types already confirmed for this instance. <tenant> is from HALO_TENANT, or the host of HALO_BASE_URL (e.g. halo-acme for acme.halopsa.com).

3. If the needed category is already in the catalog, validate it still resolves with halo_get_ticket_type(ticket_type=<id>):

   • resolves cleanly -> use that id, go to (b).
   • no longer resolves (renamed/deleted) -> drop it from the catalog, re-discover (below), and memory_invalidate the stale fact when you rewrite the catalog.

4. If the category is missing (or was invalidated), discover:

   halo_list_ticket_types(can_create_only=true)

   This commonly returns several change-shaped types (e.g. "Change Request", "Internal Change", "Emergency Change"). Present the candidates and ask the operator which one is the <category> change — do NOT auto-pick when more than one looks like a change, and do NOT collapse them into a single "the change type".

5. On confirmation, merge it into the catalog (add the new category; keep the others — do not overwrite the whole list with a single entry):

   memory_record_fact(entity="halo-<tenant>", key="change_ticket_types",
                      value=<updated JSON list including {"id":<id>,"name":"<name>","category":"<category>"}>)
   memory_record_decision(context="Halo change type for <tenant> / <category>",
                          decision="Use ticket type <id> (<name>) for <category> changes",
                          rationale="Operator-confirmed from halo_list_ticket_types(can_create_only=true)")

Carry the selected <id> into (b) and (c). If a single request genuinely spans both a customer and an internal change, that is two change tickets — run the flow once per category, confirming each.