HaloPSA's native MCP source

HaloPSA version 2.236 and later has its own MCP endpoint. Adding it as a source gives Qubit the tools HaloPSA itself provides, on top of the HaloPSA lookups Qubit already has built in. Each technician signs in to HaloPSA as themselves, so what Qubit does in HaloPSA is done as that technician. An Administrator sets it up once; each technician then connects.

Before you start:

• You need the Administrator role.
• Your HaloPSA must be version 2.236 or later.
• Your HaloPSA address must already be set up in QuantumOps. The endpoint is built from it. See Your HaloPSA connection.
• QuantumOps must know its own public address, which it needs to build the redirect URI in the steps below. If the redirect URI does not appear, contact TechPulse.

Register the application in HaloPSA

1. Open MCP Sources in the sidebar. Find the card HaloPSA native MCP for this tenant. Its status reads Not configured.
2. In Redirect URI to register in Halo, choose Copy. If the box is empty, QuantumOps does not know its public address yet. Contact TechPulse and come back.
3. In HaloPSA, go to Configuration → Integrations → HaloPSA API → Applications and create a new application whose type is Authorisation Code (Native). Paste the redirect URI into the application's redirect settings and save it.
4. Copy the application's client ID.

This is a separate application from the one QuantumOps uses to read tickets, which Your HaloPSA connection describes.

Save the source in QuantumOps

Back on the same card:

Choose Save. The page confirms that it saved the source and reminds you that each technician presses Connect. The card status then reads Configured, with enabled or disabled and the time of the last change.

If QuantumOps reports that your organisation has no HaloPSA address, set up the connection first. If another source already uses the alias halo, rename or delete it, then save again.

Connect as a technician

Each technician connects once.

1. Open MCP Sources. Under My connections, find HaloPSA (native MCP) and choose Connect. HaloPSA's sign-in opens in a new tab.
2. Sign in to HaloPSA as yourself and approve the access.
3. Return to the page and choose Test. The row shows how many tools your account gets.

Until a technician connects, the row reads Needs sign-in. An Administrator connects the same way. The row also appears under Configured sources, marked as a tenant template that each person connects separately.

A tool that HaloPSA marks as destructive always waits for approval. Your rules in Tool Governance apply to the tools of this source like any other.

Switch it off, on or change it

• After the first save, the card shows Disable while the source is on and Enable while it is off.
• Changing the Client ID signs every technician out, because their sign-ins came from the old application. The page tells you how many were removed, and each technician chooses Connect again.
• Changing Scopes or the Client secret keeps everyone's sign-in.
• A HaloPSA on a private network is allowed. QuantumOps builds this source's address from your HaloPSA URL, so the private-address rule described in MCP sources does not apply to it.

What other users see

Users who are not Administrators see the card with the status Not configured until an Administrator sets it up. It tells them that an Administrator configures it with the client ID of your HaloPSA application, and that they then choose Connect on the row that appears.

If something does not work

Related pages

• MCP sources: scopes, sign-in states and the rest of the page.
• What Qubit can use: tools and sources: how Qubit picks between built-in lookups and source tools.
• Tool Governance: allow, approve or deny the tools of this source.
• Your HaloPSA connection: the separate application QuantumOps reads tickets with.